Комментарии 13
Как-то плохо работает ваш хак с подтверждением пароля:
Да и проверка почты лажает:
Да и с числами какая-то ерунда:
Как-то плохо работает ваш хак с подтверждением пароля
Для копии пароля в схеме не задан текст ошибки, показывается дефолтный от браузера.
Да и проверка почты лажает
Я не силен в регулярках, паттерн был \w@habr.com, поменял на *@habr.com, теперь нормально.
Да и с числами какая-то ерунда
А если я хочу ввести 1,223,58? Опять же, можешь отрегулировать под свой вкус.
Я вроде 100_000 вводил.. Cлабо отформатировать число так, чтобы от нулей в глазах не рябило?
Это как-то относится к тебе валидации?
И даже это число? Я вводил 333 рубля, почему с меня списали 3 тыщи?!?
Нет, ты ввел 3e3 а это 3000. Ввел бы 333, было бы 333. А ввел бы 2e1, было бы 20.
Для копии пароля в схеме не задан текст ошибки, показывается дефолтный от браузера.
Вы это пользователю как объясните?
Я не силен в регулярках, паттерн был \w@habr.com, поменял на *@habr.com, теперь нормально.
А если я хочу ввести 1,223,58? Опять же, можешь отрегулировать под свой вкус.
Покажите же нам хороший пример, а не отмахивайтесь от типичных требований к подобным контролам.
Это как-то относится к тебе валидации?
Очень просто - попытка отформатировать число приведёт вас к необходимости отказа не только от нативной валидации, но даже и от нативного поля ввода числа.
Нет, ты ввел 3e3 а это 3000. Ввел бы 333, было бы 333. А ввел бы 2e1, было бы 20.
Вы это всё пользователю объясняйте, не мне.
Вы это пользователю как объясните?
Я это объяснил читателям статьи: «Чтобы продемонстрировать работу с текстами ошибок, добавим простую схему...».
Покажите же нам хороший пример, а не отмахивайтесь от типичных требований к подобным контролам.
В первую очередь, это демонстрация возможностей а не полностью готовое решение. А кроме того, почему вы решили, что это «хороший пример»? А что если я на калькуляторе что-то посчитал, получил 1,25e7 и хочу это скопировать и вставить в форму? Почему вы считаете хорошим примером отобрать у меня эту возможность?
Очень просто - попытка отформатировать число приведёт вас к необходимости отказа не только от нативной валидации, но даже и от нативного поля ввода числа.
И приведет к такому accessibility. Спасибо, не надо.
Кажется что плюсы интернациализации теряются, когда нам надо поставить кастомные сообщения - feedback для пользователя. Так же немного сбивает с толку PaymentForm это хороший класс который оркестрирует ошибками формы, но зачем тогда другие валидаторы -сервисы. Вроде как понятно что они связывают input, но как-то интуитивно хочется иметь один источник.
Кажется что плюсы интернациализации теряются, когда нам надо поставить кастомные сообщения
В каком-то смысле да. Но все познается в сравнении. Если не задать текст ошибки, будет использоваться дефолтный, он не идеален, но лучше чем ничего + интернациализация из коробки. Но для сравнения, давайте возьмем какую-то альтернативу, например что-то типа zod/yup, (они очень похоже).
Я не буду воспроизводить пример выше полностью, потому что это долго, возьмем одно свойство:
const formSchema = object({
email: string().email({ message: "Невалидный емэйл" });
})Как добавить интернациализацию для такой валидации? Можно взять что-то вроде i18n, или прям завести словарик если языков нужно поддерживать два или три. То же справедливо и для решения предложенном в статье.
Преимущества встроенного API для валидации, не столько в сообщениях об ошибках, хотя и в этом оно выигрывает. Например, что будет если для схемы выше в поле емэйл мы введем "mymail@myhost.com", если согласно условию, можно вводить адреса только вида @habr.com, что нам скажет zod или yup в этом случае? Невалидный емэйл? Но он валиден, просто не на хабре а на myhost.
Constraint Validation API предлагает более гибкий способ менять текст ошибки. В статье к это демонстрируется, например – будет одна ошибка если введенный текст вообще не емэйл и другая если он не заканчивается на habr.com.
Так же немного сбивает с толку
PaymentForm
PaymentForm это «стейт», можно было его сделать как угодно – хуки, редакс, зустанд и т.д. Я реализовал на удобном для меня инструменте. FormValidator служит совсем другой цели, и он может работать с любой формой и любым количеством полей.
Если бы мы использовали zod/yup, то нам точно также нужно было бы использовать какое-то состояние (стейт). В примере ниже formSchema описывает схему валидации, но нам нужно откуда-то взять объект и скормить ей, чтобы проверить валиден он или нет:
const formSchema = object({
sum: number().required().positive().integer(),
email: string().email(),
password: string().min(5).max(12),
passwordCopy: string().min(5).max(12),
});
// псевдокод
function Form() {
const [form, setForm] => useState({
sum: 0,
email: '',
password: '',
passwordCopy: '',
})
function onChange(event) {
form[event.target.name] = event.target.value;
const errors = userSchema.validate(form);
if (errors) {
// делаем что-то если есть ошибки
} else {
// делаем что-то если ошибок нет
}
}
// ...
}
Валидация сложных форм с помощью Constraint Validation API