Валидация форм в React

[@SoloFeeD]

Зачем передавать в в функцию все поля с данными для проверки конкретного поля?

[@theWaR_13]

Честно говоря, я тоже не совсем понимаю, зачем автор компонента это сделал. Возможно, существуют какие-то кейсы, когда это необходимо.

[@shir]

Первое что приходит на ум — в зависимости от другого поля (например, чекбокса), проверять заполнено ли поле.

[@crocodile2u]

пример:
dropdown-box «Откуда узнали про наш проект?» Последняя опция — «свой вариант». Если ее выбираешь, появляется текстовое поле. Это текстовое поле нужно проверить на заполненность только если в dropdown выбрано «свой вариант».

[@VasilioRuzanni]

Еще кейс — «дата начала не может быть позже даты окончания [чего-либо]» и ее более сложные вариации.

[@SoloFeeD]

Та кейсов можно много придумать, так какая разница плодить в одном методе ифы, или сделать отдельно конкретный метод и передавать туда те поля, которые нужны для валидации?

[@miraage]

Просто люди не знают, зачем нужен паттерн Mediator.

[@yociyavi]

Пользуюсь https://validatejs.org/ Либа не зависит ни от фреймворка, ни от платформы.

[@n0ne]

А мне больше нравится redux-form… и её material-ная версия

[@indestructable]

Считаю, что валидация форм — это тупиковый путь, который годится только для простейших приложений. Валидировать нужно бизнес сущности, и обязательно на стороне сервера (а на стороне клиента — опционально).
В сложном приложении бывает несколько форм для одной сущности, разные правила в зависимости от ролей пользователя, инлайн редактирование в гридах — делать валидацию форм — это значит дублировать код.
Валидация сущностей — это бизнес логика, и подход к ней должен быть соответствующий.

[@theWaR_13]

На данный момент я занимаюсь разработкой достаточно большого приложения. И вот взять даже такую простую вещь, как форма логина. Без валидаций пользователь может отправить данные на сервер даже не заполнив поля ввода. А учитывая тот факт, что нагрузки на сервер могут быть достаточно серьезными, зачем лишний раз его перегружать его бесполезными запросами? Да, возможно где-то код и будет дублироваться, но принцип DRY стоит использовать разумно, а не фанатично пытаясь избежать любого повторения.
Кроме того, не все же делают какие-то большие приложения. Смысл данной статьи рассказать про один конкретный способ валидации форм, возможно, сэкономив кому то время.

[@indestructable]

Вы, наверное, не совсем правильно меня поняли. Я не призываю отказаться от клиентской валидации, но она должна быть дополнением к серверной, в идеале использовать один и тот же код.

[@QtRoS]

Функция проверки могла бы выглядеть вот так:

function isGoogleEmail(values, value) {
  return !value || value.indexOf('gmail.com') != -1
}

Лаконичность и краткость ценится всегда, независимо от фреймвока и языка, а писать 'if (x) return true else return false' — уровень университета.

[@neoxack]

И читабельность ухудшается раз так в 5