{
  "index": 201,
  "slug": "editorial-2022-06-practice-form-errors",
  "title": "Старая ошибка формы после новой правки: как связать ответ с тем вводом, который сервер проверял",
  "excerpt": "Если пользователь исправил поле, поздний ответ прежней отправки не должен менять текущую форму. Разбираем локальную проверку, версии полей, attemptId и честный retry.",
  "contentHtml": "<p>Пользователь вводит <code>old@example.test</code> и нажимает «Сохранить». Сервер отвечает: «Адрес уже занят». Пока ответ идёт, пользователь меняет поле на <code>new@example.test</code>. Затем интерфейс показывает ту же ошибку рядом с новым адресом. Поле выглядит заполненным, но сообщение относится к другому значению.</p>\n<p>Цена ошибки измерима на уровне действия. Человек может повторно исправлять корректный адрес, закрыть форму или отправить её ещё раз, не понимая, какой запрос сейчас активен. В регистрациях, платежах и заказах такое поведение подрывает доверие и может привести к повторному действию с побочным эффектом.</p>\n<p><strong>Тезис:</strong> ошибка принадлежит не имени поля, а снимку ввода и конкретной попытке отправки. Поэтому ответ можно применить только тогда, когда он относится к текущей версии поля. Для этого нужно разделить локальную проверку, состояние отправки и результат сервера; при каждой правке увеличивать версию поля; каждой отправке выдавать <code>attemptId</code>; устаревший ответ явно игнорировать.</p>\n<h2>Как возникает рассинхронизация</h2>\n<p>У формы есть два времени. Первое — время ввода. Значение меняется при каждом действии пользователя. Второе — время ответа. Запрос может закончиться после нескольких новых правок. Если обработчик знает только имя поля, он записывает результат в актуальное состояние, хотя сервер проверял прежний снимок.</p>\n<p>Правило «применяем последний пришедший ответ» не защищает форму: последним может прийти самый старый запрос. Правило «последняя правка побеждает» тоже неполно: оно способно скрыть ошибку, которая действительно относится к текущему значению. Нужна проверка принадлежности: совпадают ли версия поля и идентификатор попытки с теми, что сохранены в состоянии.</p>\n<p>Локальная ошибка имеет другой источник. Пустое обязательное поле или строку без доменной части email можно проверить до отправки. В этом случае запрос не создаётся. Серверная ошибка появляется только после ответа на конкретный снимок. Ошибка транспорта описывает доставку ответа, а не значение одного поля. Если положить всё в <code>form.error</code>, код потеряет правило очистки и следующий шаг.</p>\n<h2>Контракт состояния</h2>\n<table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Старый текст появился после правки</td><td>Ответ сопоставлен только по имени поля</td><td>Сравнить версии из запроса и текущего поля</td><td>Пометить ответ как stale и не создавать server error</td></tr><tr><td>Две отправки идут одновременно</td><td>Retry не проверяет active attempt</td><td>Проверить переходы submitting и retry</td><td>Заблокировать повтор до завершения попытки</td></tr><tr><td>Локальная ошибка ушла на сервер</td><td>Constraint validation смешана с submit</td><td>Убедиться, что невалидный снимок не получил attemptId</td><td>Показать причину у поля и остановить отправку</td></tr><tr><td>Ошибка осталась после изменения значения</td><td>Server error очищается только после ответа</td><td>Изменить поле и проверить state до нового ответа</td><td>Снять ошибку прежней версии</td></tr><tr><td>Повторный ответ меняет успех</td><td>Нет границы принятой попытки</td><td>Передать duplicate после success</td><td>Игнорировать ответ без active attempt</td></tr></tbody></table>\n<p>Минимальная запись поля может выглядеть так: <code>{ value, version, localError, serverError }</code>. В состоянии формы отдельно нужны <code>activeAttempt</code> и последний принятый снимок. При правке меняются <code>value</code> и <code>version</code>, а ошибка сервера для прежней версии исчезает. При отправке код копирует значения и версии в attempt. Он не должен читать актуальное поле в момент ответа: это уже может быть другой ввод.</p>\n<h2>Пример: ответ проверяется до изменения state</h2>\n<pre><code>function editEmail(form, value) {\n  const field = form.fields.email;\n  return { ...form, fields: { ...form.fields, email: {\n    value, version: field.version + 1,\n    localError: validateEmail(value), serverError: null\n  }}};\n}\n\nfunction beginSubmit(form) {\n  const email = form.fields.email;\n  if (email.localError) return { kind: 'blocked-local-error' };\n  const attempt = { id: form.nextAttemptId,\n    values: { email: email.value }, versions: { email: email.version } };\n  return { ...form, activeAttempt: attempt, nextAttemptId: attempt.id + 1 };\n}\n\nfunction receiveResult(form, result) {\n  const attempt = form.activeAttempt;\n  if (!attempt || attempt.id !== result.attemptId) return ignore(form);\n  const current = form.fields.email;\n  if (attempt.versions.email !== current.version) {\n    return { ...form, activeAttempt: null, log: [...form.log, 'stale-response-ignored'] };\n  }\n  if (!result.ok) return { ...form, activeAttempt: null,\n    fields: { ...form.fields, email: { ...current, serverError: result.message } } };\n  return { ...form, activeAttempt: null, accepted: attempt.values };\n}</code></pre>\n<p>Это учебный пример для in-memory reducer. Он не отправляет HTTP-запрос, не отменяет <code>fetch</code>, не создаёт DOM и не доказывает порядок сетевых пакетов. Строка <code>Адрес уже занят</code> в тесте должна быть входом <code>result.message</code>, а не утверждением о production-ответе. В реальном приложении сетевой адаптер обязан передать в reducer тот же <code>attemptId</code> и снимок версий.</p>\n<h2>Почему stale-ответ нужно завершать</h2>\n<p>Устаревший ответ нельзя применять к полю. Но его нельзя и просто забыть, оставив форму в вечном <code>pending</code>. Если пользователь уже ввёл новое значение, активная попытка прежнего снимка больше не должна блокировать текущий retry. Переход <code>stale-response-ignored</code> снимает <code>activeAttempt</code>, пишет диагностический сигнал и не создаёт ошибку.</p>\n<p>После этого пользователь может отправить текущий валидный снимок. Новый retry получает новый <code>attemptId</code> и новые версии. Это не означает, что браузер отменил старый запрос. Отмена зависит от API и стоимости работы сервера. Даже отменённый запрос не заменяет проверку ответа: гонки и повторная доставка должны иметь безопасный результат.</p>\n<figure><img src='/assets/editorial/2022/form-errors-state-machine-2022.svg' alt='Автомат формы: отправка хранит attemptId и версии, правка делает ответ устаревшим, совпавший ответ ведёт к ошибке или успеху' /><figcaption>Схема показывает контракт данных, а не измеренную задержку и не поведение конкретного HTTP-клиента.</figcaption></figure>\n<h2>Порядок исправления</h2>\n<ol><li><strong>Зафиксируйте симптом.</strong> Воспроизведите отправку, правку до ответа и появление старой ошибки. Запишите значение поля до отправки и после правки.</li><li><strong>Найдите владельца.</strong> Отметьте обработчик ответа и место записи ошибки. Если запись использует только имя поля, граница недостаточна.</li><li><strong>Разделите проверки.</strong> Локальную невалидность обработайте до создания попытки. Ошибку сервера храните вместе с идентификатором попытки и версиями снимка.</li><li><strong>Добавьте версии.</strong> Увеличивайте версию при каждой правке. Копируйте версии в attempt, а не вычисляйте их после ответа.</li><li><strong>Закройте повтор.</strong> Пока есть active attempt, не запускайте второй submit. После stale, server error или success переход должен быть явным.</li><li><strong>Проверьте отрицательный путь.</strong> Передайте старый ответ после новой правки. Он не должен менять значение, ошибку или принятый снимок.</li><li><strong>Проверьте браузер.</strong> Отдельно подтвердите реальный DOM, фокус, сообщение и связь поля с ошибкой. Fixture этого не проверяет.</li></ol>\n<h2>Связь с разметкой ошибки</h2>\n<p>Состояние данных не заменяет доступную разметку. Если интерфейс использует <code>aria-invalid</code> и <code>aria-errormessage</code>, атрибуты должны появляться только для ошибки текущей версии. При новой правке связь с прежним сообщением нужно убрать. Идентификатор попытки сам по себе не делает сообщение доступным и не подтверждает, что вспомогательная технология его объявила.</p>\n<p>Для нативных контролов сначала используйте возможности HTML: правильный тип, <code>required</code>, <code>pattern</code> и constraint validation. Скрипт может дополнить этот слой серверным результатом, но не должен подменять его общей строкой без указания поля. Сообщение должно объяснять причину и действие, если сервер действительно сообщает о проблеме текущего снимка.</p>\n<h2>Ограничения</h2>\n<p>Схема рассчитана на одну форму и одного владельца состояния. Она не решает конфликт между двумя вкладками, offline, rate limit, CSRF, составные поля, загрузку файлов и оптимистическое сохранение. Для нескольких полей версия должна быть частью снимка каждого поля или общей версии формы; выбор зависит от того, какие поля сервер проверяет вместе.</p>\n<p><code>attemptId</code> интерфейса не является idempotency key. Он защищает применение ответа внутри формы. Идемпотентность на сервере требует отдельного контракта. Нельзя считать, что новый UI-идентификатор предотвращает повторную оплату или создание ресурса.</p>\n<p>Пример не содержит production-метрик. Его проверяемый результат уже: устаревший ответ не меняет текущий ввод; совпавший ответ меняет только соответствующий снимок; duplicate после success не меняет accepted state; локально невалидный ввод не создаёт попытку.</p>\n<h2>Критерий готовности</h2>\n<p>Исправление готово, если команда воспроизводит четыре сценария с однозначными переходами: локальная ошибка блокирует submit без attemptId; правка во время отправки делает прежний ответ stale; совпавший server error появляется только у проверенного значения; успешный retry создаёт новый accepted snapshot, а старый duplicate ничего не меняет. Браузерная проверка дополнительно подтверждает, что сообщение видно, связано с нужным контролом и очищается после новой правки.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href='https://html.spec.whatwg.org/multipage/forms.html' target='_blank' rel='noopener noreferrer'>WHATWG HTML Standard: Forms</a> — constraint validation, submit и поведение элементов формы.</li><li><a href='https://www.w3.org/TR/wai-aria/' target='_blank' rel='noopener noreferrer'>W3C WAI-ARIA 1.2</a> — значения <code>aria-invalid</code> и связь ошибки через <code>aria-errormessage</code>.</li></ul>"
}