Комментарии 9
Слышал, про LIVR, использовал пока что только на backend. По описанию очень похоже на ваше решение. Как к этой библиотеке относитесь?
спасибо за материал, но у меня возник вопрос:
когда вы вводите пароль в очередной форме регистрации, вас не раздражают случаи, когда валидаторы срабатывают по одному?
ввел password, узнал, что нужно добавить большую строчку букву
ввел Password, теперь нужно добавить спец символ
и так далее, пока все возможные функции валидации не вернут null?
"ввёл пароль, что-то узнал" - такого кейса как раз не возникает, так как мы саппортим пользователя по мере ввода данных. Т.е. на каждый onchange у нас срабатывает вся валидация, которая закреплена за полем. И таким образом мы не ждём, пока человек введёт весь пароль в миллион символов и узнает, что есть 10 правил, которые он нарушил, а помогаем ему "налету".
Но для того, чтобы было совсем хорошо, нам надо либо впилить тоненькую подсказку серым текстом под полем (о чём в статье упоминал всколзь), либо лучше использовать тултипы для такого функционала (например иконка знака вопроса и вспылвающая подсказка, где пользователь (если хочет) может увидеть все правила ввода сразу).
А вы для всех полей запускаете все этапы валидации при каждом изменении? Например, при вводе email инпут будет орать на вводящего, пока не будет введено все до хоста?
>А вы для всех полей запускаете все этапы валидации при каждом изменении?
- Нет, только для поля с которым взаимодействует пользователь )
Взаимодействуем с полем - для него и тригерим запуск валидации. Триггерим запуск валидаторов для конкретного поля на события блюра и изменения (для этого есть handleBlur handleChange, которые генерит кастомный хук (см тайпинги DefaultField))
Общий прогон всех валидаторов на всю форму целесообразно делать по событию сабмита (handleFormSubmit внутри useForm).
Триггеры:
Для поля
при "касании" (blur)
по мере ввода данных (change)
по кастомному триггеру
Для формы
при отправке формы (submit)
по кастомному триггеру
Ну например я ввожу email 'my@host.io'. И при введенном 'my' инпут в невалидном состоянии отображается?
отображение здесь отделено от модели. Т.е. ты можешь привязать какой угодно view на модель, которую тебе вернёт хук.
А дальше ответ на вопрос от 2 факторов зависит:
1) юзаешь ли ты хук useTextFormField или пишешь свой
2) как ты напишешь правила проверки email.
если например ты юзаешь useTextFormField и положишь туда 2 валидатора:
- required (значит просто не пустое поле должно быть)
- email (значит, что строка мейла должна быть по паттерну какому-то)
Если предположить, что email валидатор будет возвращать ошибку на любое значение переданной строки, которое не соответствует паттерну проверки email (например заданному через регулярку). - То да - при вводе "my" в поле, у тебя будет в поле hasError проставлятся true, а в поле error будет лежать текст ошибки.
Потом эту шткуку прикручиваешь к view в рендере. Эта ошибка (по хорошему) сразу должна подсказывать пользователю какие данные от него ждут и в каком виде.
PS:
Если тебе нужно изменить логику как-то - можно спокойно написать свой кастомный хук, который переопределит handleChange и там уже например не вызывать валидацию если не нужно)
чекни код handleChange внутри useTextFormField - его можно скорректировать как тебе нужно)
Хотел обратить ваше внимание что у вас при изменение любого из полей обновляется ВСЯ форма и если вы объявите форму где то в районе страницы это приведёт к большим проблемам с оптимизацией. Я бы рекомендовал реализовать работу формы через контекст и использованием инстанса формы для получения текущего состояния формы (трогали ли поле, упала ли валидация, если упала то какая из и взять её ошибку и в этом стиле) и компонент обёртки <Field> который бы расширял компонент чилдрена всякими onBlur и прочими эфектами в зависимости от типа тригера сам.
спасибо за статью!
Возможно и мне хватит времени на реализацию библиотеки)
Валидация форм без зависимостей