Режимы валидации

В контексте связки React Hook Form и схемной валидации через Yup ключевую роль играет YupResolver, который определяет момент и стратегию запуска проверки данных. Понимание режимов валидации критично для управления производительностью формы, пользовательским опытом и предсказуемостью поведения интерфейса.

Режим валидации определяет событие, при котором запускается проверка значений формы относительно схемы. В связке с resolver логика выглядит следующим образом: React Hook Form собирает данные состояния формы, после чего YupResolver преобразует их в синхронную или асинхронную проверку через Yup-схему. Однако сам факт вызова resolver зависит не от Yup, а от настроек стратегии валидации.

Вся система опирается на три фундаментальных триггера:

  • изменение значения поля
  • потеря фокуса
  • отправка формы

Каждый режим представляет собой комбинацию этих событий с различной частотой вызова resolver.

Режим onSubmit

Наиболее строгий и экономичный с точки зрения количества валидаций режим. Проверка выполняется только при попытке отправки формы.

Особенности поведения:

  • resolver не вызывается при каждом изменении полей
  • отсутствует мгновенная обратная связь пользователю
  • состояние ошибок формируется только после submit

Такой режим характерен для форм, где:

  • важно минимизировать количество вычислений
  • пользователь заполняет большое количество полей до проверки
  • требуется «финальная» валидация перед отправкой данных на сервер

С точки зрения архитектуры это самый простой режим: состояние формы стабильно до момента триггера submit, после чего происходит единичный прогон всей схемы Yup.

Режим onBlur

Валидация запускается при потере фокуса полем.

Поведение:

  • каждое поле валидируется при событии blur
  • изменения внутри поля не вызывают проверку до ухода фокуса
  • resolver вызывается частично, в зависимости от затронутых полей

Особенность этого режима заключается в балансе между производительностью и интерактивностью. Пользователь получает обратную связь после завершения ввода конкретного поля, но не во время набора.

Типичный сценарий использования:

  • формы с умеренной сложностью
  • поля с форматированием (email, телефон, пароль)
  • ситуации, где мгновенная валидация мешает вводу

Режим onChange

В этом режиме проверка выполняется при каждом изменении значения поля.

Поведение:

  • resolver вызывается часто, потенциально на каждый ввод символа
  • ошибки отображаются почти в реальном времени
  • состояние формы постоянно синхронизируется с Yup-схемой

Этот режим наиболее «интерактивный», но и наиболее требовательный к производительности, особенно при сложных схемах валидации.

Важные особенности:

  • увеличение количества вызовов resolver при больших формах
  • возможные задержки при сложной логике Yup-схем (например, when, lazy, nested objects)
  • необходимость оптимизации схемы для предотвращения лагов интерфейса

Режим onTouched

Проверка запускается после первого взаимодействия с полем и последующего изменения значения.

Логика работы:

  1. пользователь фокусируется на поле
  2. поле помечается как touched
  3. после изменения значения начинается валидация при последующих событиях

Характерные свойства:

  • отсутствие «шумной» валидации до первого взаимодействия
  • более мягкая UX-модель по сравнению с onChange
  • частичное снижение количества вызовов resolver

Этот режим часто используется как компромисс между строгой проверкой и комфортом ввода.

Режим all

Комбинированный режим, при котором валидация запускается одновременно на нескольких событиях: change, blur и submit.

Поведение:

  • максимальная частота вызова resolver
  • полная синхронизация состояния формы с Yup-схемой
  • мгновенная реакция на любое изменение

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

Влияние resolver на частоту валидации

Сам по себе YupResolver не определяет частоту вызова, однако его роль становится критичной в момент выполнения проверки.

При каждом триггере:

  1. React Hook Form передаёт текущее состояние формы
  2. YupResolver преобразует схему в функцию проверки
  3. Yup выполняет валидацию всех или части полей
  4. Возвращается объект ошибок и нормализованные значения

Таким образом, режим валидации напрямую влияет на количество запусков этой цепочки.

Частичная и полная валидация

В зависимости от режима, resolver может вызываться:

Полная валидация

  • проверка всей схемы целиком
  • характерна для onSubmit и all
  • высокая нагрузка при больших структурах данных

Частичная валидация

  • проверка конкретного поля или группы полей
  • характерна для onChange и onBlur
  • оптимизированный сценарий работы

Важно учитывать, что Yup изначально ориентирован на полную схему, и частичная валидация реализуется через внутренние механизмы фильтрации полей.

Асинхронные эффекты в режимах валидации

Некоторые схемы Yup включают асинхронные проверки (например, проверка уникальности имени пользователя через API). В таких случаях режим валидации влияет на частоту сетевых запросов.

Особенности:

  • onChange может инициировать множество запросов подряд
  • onBlur снижает количество вызовов API
  • onSubmit агрегирует проверку в один запросный цикл

При использовании YupResolver асинхронные ошибки обрабатываются через Promise, что делает режим валидации критичным фактором стабильности интерфейса.

Производительность при различных режимах

Производительность напрямую зависит от:

  • сложности Yup-схемы
  • глубины вложенности объектов
  • количества полей
  • частоты вызова resolver

Сравнительная характеристика:

  • onSubmit: минимальная нагрузка, редкие вызовы
  • onBlur: умеренная нагрузка, локальные проверки
  • onChange: высокая нагрузка, постоянные пересчёты
  • onTouched: сбалансированная нагрузка после первого взаимодействия
  • all: максимальная нагрузка, постоянная синхронизация

Комбинация режимов с оптимизацией схем

При сложных формах режим валидации часто дополняется оптимизацией Yup-схемы:

  • разделение схем на подструктуры
  • использование lazy-валидации
  • кэширование вычислений
  • минимизация вложенных условий when

В результате даже режим onChange может стать приемлемым при корректной архитектуре схемы.

Поведение ошибок в разных режимах

Структура ошибок, возвращаемая resolver, зависит от момента выполнения валидации:

  • onSubmit: ошибки появляются пакетно
  • onChange: ошибки обновляются непрерывно
  • onBlur: ошибки обновляются постфактум
  • onTouched: ошибки появляются после первого взаимодействия

Это влияет на UX-логику отображения сообщений, подсветку полей и блокировку отправки формы.