Я считаю, что нет, ибо валидировать неудобно. А потом неясно, в каком виде ошибки выдавать с учетом вложенности
А в чём проблема валидации? Валидация на этапе создания же
func (u User) Validate() error { if err := ValidateEmail(u.Email); err != nil { return fmt.Errorf("invalid email: %w", err) } if err := u.Address.Validate(); err != nil { return fmt.Errorf("invalid address: %w", err) } return nil }
Т.е. если надо что-то валидировать уже после того как там лежит мусор - это и проблема.
Очень "удобно". Особенно когда в JSON десятки полей (такое бывает)
а в чём проблема?)
А тебе в любом случае это надо разбирать и валидировать.
Если структура плоская, то без проблем можно её отвалидировать и выдать на фронт ответ в виде {errors:{name:required,email:not valid}} (ну, примерно). А как с вложенными данными быть - хз. Потому что по логике ошибки тоже надо вложенными делать
Наверное вложенности, и как формировать текст ошибки с бэка. Возможно, что нетривиально собирать путь по ключам структуры из пятого уровня вложенности. В той же a-la “dot-notation”
В том, что каждое поле руками так описывать - полный геморрой
это ответственность обработчика endpoint'а
я так не считаю, их же не тысячи?
Но писать-то ручками всё. =) И обработчики, и логику сборки “пути”, где валидация отвалилась. То есть, скорее плоское лучше вложенного и в go.
зачем пути? в обработчикe у нас плоская структура
Их не тысячи, но штук 30 вполне может быть. Какой смысл описывать каждое поле руками, когда тот же GoValidator умеет валидировать плоские структуры по структурным тегам вообще без проблем
ничего, прост
Там рефлексия только на этапе извлечения меты, насколько я помню
Обсуждают сегодня