Комментарии 9
А как дела обстоят с полифилами для reportValidity (не уверен что есть в babel из коробки)?
Поддержка Validation API была еще в IE10.
Полифилов для reportValidity() нет, так как эта функция не только возвращает состояние валидации, но и показывает всплывающий контейнер с ошибкой.
Полифилов для reportValidity() нет, так как эта функция не только возвращает состояние валидации, но и показывает всплывающий контейнер с ошибкой.
Vuelidate выдавала сообщение о том, что библиотека более не разрабатывается. Возможно это не проблема вовсе, я просто перебирал варианты для своего проекта и выбрал Vee-validate, нще и по по причине готового тайпинга для Typescript.
У меня есть общие вопросы про валидацию на клиенте. Можно ли полностью полагаться на нее и не проверять данные на back end? Если да, то как защититься от пользователей, умеющих пользоваться browser development tools?
Если таки делать второй слой валидации на сервере, то как синхронизировать бизнес-правила между кодом back-end и front-end? Что делать, если две реализации при независимой разработке рассогласовались, и клиентская валидация требует такой формат ввода, который не проходит серверную?
никогда не доверяйте пользовательским данным
1. Нет, нельзя. Посылать запросы можно и без браузера.
2. Да, рассинхронизация бывает. Иногда даже приходится интуитивно угадывать валидации бека :)
Достаточно, чтобы бек присылал ошибки валидации в согласованном формате и клиент их отображал. В таком случае, если валидация на фронте пройдет, а на беке провалится — юзер увидит читабельную ошибку и поймет, что надо поправить.
А если поле прямо требует неправильный формат данных и форму невозможно отправить, то узнать об этом можно от e2e тестов, злых юзеров и по тишине в аналитике.
2. Да, рассинхронизация бывает. Иногда даже приходится интуитивно угадывать валидации бека :)
Достаточно, чтобы бек присылал ошибки валидации в согласованном формате и клиент их отображал. В таком случае, если валидация на фронте пройдет, а на беке провалится — юзер увидит читабельную ошибку и поймет, что надо поправить.
А если поле прямо требует неправильный формат данных и форму невозможно отправить, то узнать об этом можно от e2e тестов, злых юзеров и по тишине в аналитике.
Может быть, тогда рациональнее вообще отказаться от валидации на клиенте и не нарушать принцип DRY? Всё равно бэк-энд проверяет поступившие данные. Ловить отлуп web-сервера при submit'е формы, отображать ошибку и оставить пользователя на той же web-странице, чтобы исправил ввод и повторил отправку.
Валидация на бэке первична, а на фронте вторична.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Валидация форм во Vue.js