Повторная отправка после исправления

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

При использовании схемы Yup и резолвера в библиотеках вроде React Hook Form, логика повторной отправки строится вокруг нескольких этапов: обновление значений, повторная валидация, очистка ошибок, и только затем запуск onSubmit.

Пересборка состояния валидации перед отправкой

При каждом вызове handleSubmit резолвер YupResolver запускает повторную проверку схемы. Это означает, что предыдущие ошибки не сохраняются автоматически — они пересчитываются на основе текущих значений формы.

Ключевой момент заключается в том, что исправление одного поля может влиять на валидность всей формы:

  • изменение значения поля → обновление внутреннего состояния формы
  • повторный запуск yup.validate() через resolver
  • генерация нового объекта ошибок
  • синхронизация с состоянием formState.errors

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

Поведение handleSubmit при повторной попытке

Повторная отправка после исправления ошибок всегда проходит через один и тот же pipeline:

  1. пользователь вызывает submit
  2. запускается резолвер Yup
  3. схема проверяет актуальные значения
  4. если ошибок нет — вызывается onSubmit
  5. если ошибки есть — вызывается onError

Важно понимать, что повторная отправка не «дополняет» предыдущую попытку, а полностью заменяет её. Это означает отсутствие накопления ошибок или состояний между попытками.

Влияние режима валидации на повторную отправку

Режимы mode и reValidateMode существенно влияют на поведение исправлений перед повторной отправкой.

mode: onSubmit

При этом режиме:

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

Это означает, что пользователь может исправить данные, но ошибки исчезнут только при следующем submit.

mode: onChange или onBlur

В этом случае:

  • каждое изменение поля запускает валидацию через YupResolver
  • ошибки обновляются мгновенно
  • повторная отправка чаще всего происходит уже с валидной формой

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

Очистка ошибок после исправления значений

При использовании YupResolver очистка ошибок происходит автоматически, но только при условии повторной валидации.

Типичный сценарий:

  • поле email содержит ошибку
  • пользователь исправляет значение
  • trigger или handleSubmit вызывает повторную проверку
  • Yup возвращает успешный результат
  • errors.email удаляется из состояния

Если же валидация не была запущена повторно, ошибка остаётся в состоянии, даже если значение уже корректное.

Роль trigger() в повторной отправке

Метод trigger() используется для принудительной повторной валидации без отправки формы. Он особенно важен в сценариях, где требуется подготовить форму к повторному submit после частичных исправлений.

Типичный сценарий:

await trigger();
handleSubmit(onSubmit)();

Использование trigger() обеспечивает:

  • актуализацию ошибок до отправки
  • предотвращение повторного вызова onError
  • синхронизацию UI с текущими значениями

Конфликты между локальным состоянием и YupResolver

При повторной отправке часто возникает проблема расхождения между:

  • локальным состоянием UI (например, useState)
  • состоянием формы в React Hook Form
  • результатами Yup-валидации

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

Асинхронная валидация и повторные попытки отправки

Если схема Yup включает асинхронные проверки (например, проверку уникальности email через API), повторная отправка становится чувствительной к состоянию запроса.

Сценарий:

  • первая отправка → ошибка “email занят”
  • пользователь исправляет email
  • повторная отправка → новый запрос к API
  • результат зависит от актуального состояния сервера

Важно учитывать, что каждый submit запускает новую цепочку асинхронных проверок, даже если предыдущая уже завершилась.

Защита от двойной отправки при исправлении ошибок

При повторной отправке после исправлений часто возникает проблема множественных запросов. Она не связана напрямую с YupResolver, но проявляется на уровне UI.

Используются следующие механизмы:

Блокировка состояния отправки

const { isSubmitting } = formState;

При isSubmitting === true повторные клики submit игнорируются.

Отключение кнопки

<button disabled={isSubmitting}>

Это предотвращает повторный запуск submit до завершения текущего цикла.

Очистка состояния после успешной отправки

После успешного onSubmit часто выполняется:

reset();

Это гарантирует, что повторная отправка начинается с чистого состояния формы, а не с частично изменённого.

Поведение ошибок сервера при повторной отправке

YupResolver отвечает только за клиентскую валидацию. Однако при повторной отправке часто добавляются серверные ошибки через setError.

Сценарий:

  • Yup пропускает данные
  • сервер возвращает ошибку
  • вызывается setError('email', { message: 'уже используется' })
  • пользователь исправляет поле
  • повторная отправка запускает новую проверку
  • серверная ошибка исчезает только при успешном ответе

Важно, что серверные ошибки не очищаются автоматически YupResolver, они требуют явного обновления состояния формы.

Обновление схемы Yup и влияние на повторную отправку

В некоторых приложениях схема Yup может динамически изменяться:

  • изменение бизнес-правил
  • переключение режимов формы
  • зависимые поля

При изменении схемы:

  • все последующие handleSubmit используют новую версию validation schema
  • старые ошибки могут стать неактуальными
  • повторная отправка фактически выполняет новую логику проверки

Это особенно важно при условной валидации через when().

Кэширование и повторная валидация

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

Это означает:

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

Состояние формы между попытками отправки

При повторной отправке важно учитывать следующие состояния:

  • isDirty — форма была изменена после последнего submit
  • isValid — текущее состояние валидности
  • dirtyFields — список изменённых полей

После исправления ошибок:

  • isDirty обычно остаётся true
  • isValid может изменяться динамически
  • dirtyFields определяет, какие поля пересчитывались

Эти значения напрямую влияют на UX повторной отправки и позволяют оптимизировать поведение кнопок и подсказок.

Повторная отправка в связке с reset и defaultValues

После успешной отправки часто выполняется reset, что возвращает форму к начальному состоянию.

Однако при частичном сбросе:

reset(values);

повторная отправка может происходить уже с обновлёнными defaultValues, что влияет на результат YupResolver.

Важно учитывать, что схема Yup не зависит от defaultValues напрямую, но влияет на итоговую структуру данных, передаваемых в submit.

Итоговое поведение цепочки исправление → повторная отправка

Полный цикл выглядит следующим образом:

  • ошибка выявляется через YupResolver
  • пользователь исправляет значение
  • запускается повторная валидация
  • ошибки пересчитываются
  • форма становится валидной
  • submit запускает новый цикл проверки
  • при успехе вызывается onSubmit
  • при ошибке вызывается onError

Эта цепочка всегда детерминирована текущими значениями формы и не зависит от предыдущих попыток отправки.

Оглавление