на Го, реализуешь роутинг и шаблонизацию на встроенных либах и доходишь до валидации форм. Сидишь такой и думаешь «что, этого нет в стдлибе? Что, ставить пакеты? Что, пилить самому?» 😄
что значит "валидация форм"
значит валидация полей из форм
https://github.com/go-playground/validator очень удобно
а зачем отдельная либа под это нужна
Набор требований к набору полей. Это для апишки тоже актуально.
Намекаешь, что в го такой подход не принят?))
это чуть ли не единственное решение адекватное ) юзал его года 4 назад, тогда только-только 8 версия вышла ) или уже была выпущена, не помню точно
нет, просто в чем проблема написать валидатор ручками?
тем что с ростом количества полей и структур ты либо напишешь свою такую либу, либо заколебешься это делать
Ну а вы как валидируете большой вложенный json на апишку, когда есть требования к типам, обязательности, рейнджу, куче всего остального? С учетом того, что охота отдавать путь до проблемного значения, а не просто «ой, что-то не шмогла анмаршалить»
func (p Params) Validate() error { if p.Foo == ""{ return fmt.Errorf("p.Foo is empty") } if err := p.Bar.Validate(); err != nil{ return fmt.Errorf("p.Bar: %w", err) } // etc return nil }
Я немного не о том. Сложный json не сможет даже анмаршалиться, если клиент передал что-то не то
и как вам в таком случае https://github.com/go-playground/validator поможет?
Не знаю, не я его скидывал)
Вы-то какое решение посоветуете?
сделать констрейт на типы и значения условного "type":"photo"
вообще хз, я не сталкивался с задачей анализировать невалидный json
В аннотации к структуре ‘json:...’ или где?
Так json-то валидный)) он не валиден с точки зрения контракта
ну, валидатор выше умеет в oneof например
Спасибо, пока это ближе всего
а зачем отдельные либы вообще нужны? напихаем всё-всё-всё в java.util, пускай ебутся.
я такое не говорил
Ну и это посмотри github.com/go-ozzo/ozzo-validation
Видел, спасибо!
Обсуждают сегодня