Как стать автором
Обновить

Комментарии 13

Как-то плохо работает ваш хак с подтверждением пароля:

Указанном где?
Указанном где?

Да и проверка почты лажает:

Но ведь это почта на Хабре..
Но ведь это почта на Хабре..

Да и с числами какая-то ерунда:

Как и просили - ввёл с точкой в конце.
Как и просили - ввёл с точкой в конце.
А это значит число, да?
А это значит число, да?
И даже это число? Я вводил 333 рубля, почему с меня списали 3 тыщи?!?
И даже это число? Я вводил 333 рубля, почему с меня списали 3 тыщи?!?
Я вроде 100_000 вводил.. Cлабо отформатировать число так, чтобы от нулей в глазах не рябило?
Я вроде 100_000 вводил.. Cлабо отформатировать число так, чтобы от нулей в глазах не рябило?

Как-то плохо работает ваш хак с подтверждением пароля

Для копии пароля в схеме не задан текст ошибки, показывается дефолтный от браузера.

Да и проверка почты лажает

Я не силен в регулярках, паттерн был \w@habr.com, поменял на *@habr.com, теперь нормально.

Да и с числами какая-то ерунда

А если я хочу ввести 1,223,58? Опять же, можешь отрегулировать под свой вкус.

Я вроде 100_000 вводил.. Cлабо отформатировать число так, чтобы от нулей в глазах не рябило?

Это как-то относится к тебе валидации?

И даже это число? Я вводил 333 рубля, почему с меня списали 3 тыщи?!?

Нет, ты ввел 3e3 а это 3000. Ввел бы 333, было бы 333. А ввел бы 2e1, было бы 20.

Для копии пароля в схеме не задан текст ошибки, показывается дефолтный от браузера.

Вы это пользователю как объясните?

Я не силен в регулярках, паттерн был \w@habr.com, поменял на *@habr.com, теперь нормально.

Да чем вам моя почта-то не угодила?
Да чем вам моя почта-то не угодила?
А так значит можно? RFC поправите?
А так значит можно? RFC поправите?

А если я хочу ввести 1,223,58? Опять же, можешь отрегулировать под свой вкус.

Покажите же нам хороший пример, а не отмахивайтесь от типичных требований к подобным контролам.

Это как-то относится к тебе валидации?

Очень просто - попытка отформатировать число приведёт вас к необходимости отказа не только от нативной валидации, но даже и от нативного поля ввода числа.

Нет, ты ввел 3e3 а это 3000. Ввел бы 333, было бы 333. А ввел бы 2e1, было бы 20.

Вы это всё пользователю объясняйте, не мне.

Вы это пользователю как объясните?

Я это объяснил читателям статьи: «Чтобы продемонстрировать работу с текстами ошибок, добавим простую схему...».

Покажите же нам хороший пример, а не отмахивайтесь от типичных требований к подобным контролам.

В первую очередь, это демонстрация возможностей а не полностью готовое решение. А кроме того, почему вы решили, что это «хороший пример»? А что если я на калькуляторе что-то посчитал, получил 1,25e7 и хочу это скопировать и вставить в форму? Почему вы считаете хорошим примером отобрать у меня эту возможность?

Ну вот я посчитал на калькуляторе:

Предлагаете всем пользоваться вашим калькулятором?

Да. Очевидно, мой сделан для людей, а ваш для роботов. Сможете сходу произнести полученное число?

Очень просто - попытка отформатировать число приведёт вас к необходимости отказа не только от нативной валидации, но даже и от нативного поля ввода числа.

И приведет к такому accessibility. Спасибо, не надо.

Что сказать-то хотели?

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

Да особых сложностей и не будет, зато всем остальным инпут не будет рисовать микроскопические кривые кнопки, не вписывающиеся в дизайн. Не помню, почему было сделано именно через type="tel", а не type="text" inputmode="decimal". Скорее всего второй тогда плохо поддерживался. Исправил.

Кажется что плюсы интернациализации теряются, когда нам надо поставить кастомные сообщения - 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 {
      // делаем что-то если ошибок нет
    }
  } 

  // ...
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации