{
  "index": 200,
  "slug": "editorial-2022-06-mechanism-form-errors",
  "title": "Ошибка формы должна относиться к тому вводу, который человек видит",
  "excerpt": "Как связать значение поля, попытку отправки и сообщение об ошибке, чтобы поздний ответ сервера не переписал исправленный ввод.",
  "contentHtml": "<p>Человек вводит неправильный email и нажимает «Отправить». Форма отправляет запрос. Пока сервер отвечает, человек исправляет адрес и нажимает кнопку снова. Затем рядом с новым адресом появляется сообщение «Адрес уже занят», хотя сервер проверял старое значение. Визуально форма показывает ошибку. По смыслу она лжёт.</p>\n<p>Цена ошибки выше, чем стоимость ещё одного текста под полем. Пользователь может исправить правильный адрес, повторить отправку несколько раз или решить, что сервис потерял данные. Поддержка получает неясный вопрос. Команда видит случайный дефект: он появляется только при определённом порядке ввода и ответов.</p>\n<p>Тезис статьи прост: сообщение об ошибке, поле, которое оно описывает, и попытка отправки должны принадлежать одному снимку данных. Нельзя применять ответ только потому, что он пришёл последним или называет то же поле. Надёжная форма хранит <code>attemptId</code>, версии значений и отдельный semantic payload. Старый ответ можно показать в журнале диагностики, но нельзя возвращать его в текущее поле.</p>\n<h2>Как возникает рассинхронизация</h2>\n<p>У формы есть как минимум два времени. Первое — время ввода: значение email меняется с каждым редактированием. Второе — время запроса: сервер получает снимок и отвечает позже. Эти часы не обязаны идти в одном порядке. Ответ первой попытки может прийти после ответа второй.</p>\n<p>Наивный обработчик часто выглядит так:</p>\n<pre><code>function onServerResult(result) {\n  if (result.errors.email) {\n    state.emailError = result.errors.email;\n  }\n}\n\n// Любой поздний ответ может переписать состояние текущего поля.\n</code></pre>\n<p>В этом коде нет связи между <code>result</code> и значением, которое сейчас лежит в поле. Имя <code>email</code> совпадает, но снимки могут различаться. Обработчик знает только содержание ответа, а не его право менять состояние.</p>\n<p>Вторая ошибка — складывать разные причины в одну строку <code>form.error</code>. Локальная проверка отвечает на вопрос «можно ли отправлять этот ввод». Серверная проверка отвечает на вопрос «принял ли сервер конкретный снимок». Ошибка сети отвечает на вопрос «доставлен ли результат». У этих сигналов разные владельцы и срок жизни.</p>\n<h2>Минимальный контракт состояния</h2>\n<p>При каждой правке поля увеличивайте его <code>version</code>. Перед отправкой сохраните неизменяемый снимок значений и версий. Одновременно выдайте попытке новый <code>attemptId</code>. Ответ имеет право изменить форму только тогда, когда совпали оба условия: попытка ещё активна, а версии ответа совпадают с текущими версиями проверенных полей.</p>\n<pre><code>const form = {\n  values: { email: 'person@example.test' },\n  versions: { email: 1 },\n  activeAttempt: null,\n  errors: { local: null, server: null },\n};\n\nfunction changeEmail(next) {\n  form.values.email = next;\n  form.versions.email += 1;\n  form.errors.local = validateEmail(next);\n  form.errors.server = null;\n}\n\nfunction beginSubmit() {\n  if (form.errors.local || form.activeAttempt) return null;\n  const attempt = {\n    attemptId: 1,\n    values: { ...form.values },\n    versions: { ...form.versions },\n  };\n  form.activeAttempt = attempt;\n  return attempt;\n}\n\nfunction receiveServerResult(result) {\n  const active = form.activeAttempt;\n  if (!active || result.attemptId !== active.attemptId) {\n    return { kind: 'unknown-attempt-ignored' };\n  }\n  if (result.versions.email !== form.versions.email) {\n    form.activeAttempt = null;\n    return { kind: 'stale-response-ignored' };\n  }\n  form.activeAttempt = null;\n  form.errors.server = result.errors?.email ?? null;\n  return { kind: 'applied' };\n}</code></pre>\n<p>Это учебный пример. Он не выполняет HTTP-запрос, не создаёт DOM, не измеряет задержку и не доказывает порядок сетевых пакетов. Значение <code>attemptId: 1</code> здесь не является серверным идентификатором и не заменяет ключ идемпотентности API. Пример проверяет только право ответа изменить локальное состояние.</p>\n<p>При новой правке серверная ошибка очищается сразу. Это не означает, что сервер уже принял новое значение. Это означает, что старое сообщение больше не относится к текущему вводу. После этого пользователь может отправить новый снимок. Если старый ответ придёт позднее, сравнение версий остановит его.</p>\n<h2>Сообщение об ошибке состоит из нескольких связей</h2>\n<p>Текст сам по себе не даёт полю семантической связи. Компонент должен знать, какое поле не прошло проверку, какой элемент содержит описание и какое действие ожидается от пользователя. Удобно собирать эти данные одним переходом состояния:</p>\n<pre><code>const fieldError = {\n  field: 'email',\n  attemptId: 2,\n  version: 3,\n  messageId: 'email-server-error',\n  message: 'Этот адрес уже используется. Укажите другой адрес.',\n  invalid: true,\n};</code></pre>\n<p>Из этого объекта можно построить HTML. Например:</p>\n<pre><code>&lt;label for=&quot;email&quot;&gt;Email&lt;/label&gt;\n&lt;input id=&quot;email&quot; name=&quot;email&quot; type=&quot;email&quot;\n  aria-invalid=&quot;true&quot;\n  aria-errormessage=&quot;email-server-error&quot;&gt;\n&lt;p id=&quot;email-server-error&quot;&gt;\n  Этот адрес уже используется. Укажите другой адрес.\n&lt;/p&gt;</code></pre>\n<p>Разметка — не замена state-контракту. Если после новой правки атрибут остался, а текст относится к старому ответу, интерфейс всё ещё сообщает неверную причину. И наоборот: корректный объект в unit-тесте не доказывает, что реальный DOM связывает элементы именно так или что конкретная вспомогательная технология озвучит их ожидаемым образом.</p>\n<h2>Симптомы и действия</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика несвязанной ошибки формы</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Старое сообщение появляется после правки</td><td>Ответ сопоставляют только по имени поля</td><td>Сравнить версии снимка и текущего значения</td><td>Пометить ответ stale и не менять ошибку</td></tr><tr><td>Вторая отправка создаётся поверх первой</td><td>Состояние хранит только boolean loading</td><td>Проверить активный attempt до создания нового</td><td>Заблокировать повтор или явно определить очередь</td></tr><tr><td>Ошибка есть, но поле не названо</td><td>Серверный текст потерял field key</td><td>Найти источник сообщения и его идентификатор</td><td>Хранить field-specific record отдельно от общего статуса</td></tr><tr><td>Красный текст остался после исправления</td><td>Очистка зависит от submit, а не от edit</td><td>Изменить поле после ошибки и посмотреть state</td><td>Сбрасывать связанную server error при новой версии</td></tr><tr><td>Один ответ применился дважды</td><td>Обработчик не закрывает active attempt</td><td>Повторно передать тот же result</td><td>Игнорировать ответ без активной попытки</td></tr><tr><td>Форма очищается после отказа</td><td>UI заменяет values ответом или пересоздаёт модель</td><td>Сравнить values до submit и после error</td><td>Хранить снимок и возвращать пользователю введённые данные</td></tr></tbody></table></div>\n<h2>Иллюстрация механизма</h2>\n<figure><img src=\"/assets/editorial/2022/form-errors-semantic-association-2022.svg\" alt=\"Связь значения поля, попытки отправки и semantic payload: старый ответ не меняет новый ввод, а совпавший ответ создаёт ошибку поля.\" loading=\"lazy\" /><figcaption>Схема показывает локальный контракт данных. Она не описывает реальную задержку сети и не является результатом проверки screen reader.</figcaption></figure>\n<p>На схеме важна граница stale response. Ответ не уничтожается и не считается ошибкой транспорта. Он просто теряет право менять пользовательский state. Это отрицательный путь, который должен быть виден в тесте. Без него happy path легко создаёт ложное ощущение готовности.</p>\n<h2>Порядок внедрения и проверки</h2>\n<ol><li><strong>Зафиксируйте симптом.</strong> Воспроизведите один порядок: submit, edit, затем поздний ответ. Запишите значение поля, текст ошибки и состояние кнопки.</li><li><strong>Назовите владельцев.</strong> Отдельно определите, где живут values, versions, active attempt, локальная ошибка и серверная ошибка. Не начинайте с общего объекта «всё состояние формы».</li><li><strong>Сохраните снимок.</strong> В момент submit запишите values, версии и новый attemptId. Не вычисляйте их заново при получении ответа.</li><li><strong>Закройте повтор.</strong> Пока attempt активен, второй submit должен получить явный результат вроде <code>retry-blocked-active-attempt</code> или попасть в заранее определённую очередь.</li><li><strong>Проверьте право ответа.</strong> Сначала сравните attemptId. Затем сравните версии полей. Только после этого применяйте server error или success.</li><li><strong>Очистите старое сообщение.</strong> Новая версия поля должна убрать связанную server error. Не удаляйте введённое значение только потому, что сервер вернул отказ.</li><li><strong>Соберите semantic payload.</strong> Свяжите поле, состояние invalid, идентификатор текста и понятное действие. Проверьте реальную разметку, а не только JavaScript-объект.</li><li><strong>Проверьте отрицательный путь.</strong> Передайте ответ старой попытки после правки. Убедитесь, что значение, сообщение и semantic association не изменились.</li></ol>\n<h2>Где модель заканчивается</h2>\n<p>Контракт с версиями подходит для независимых полей и обычной повторной отправки. Он не решает автоматически зависимые поля, загрузку файлов, debounce, optimistic update, несколько вкладок и автоматические retry. Для каждого такого механизма нужно описать, какой снимок считается актуальным и кто может закрыть попытку.</p>\n<p>Локальный rollback также имеет узкую границу. Он может вернуть поле к последнему принятому локальному снимку. Он не отменяет запись на сервере и не делает компенсирующий запрос. Для платежа, заказа или изменения прав нужна отдельная серверная операция, правила конфликта и аудит. Нельзя назвать возврат значения в input отменой доменного действия.</p>\n<p>Доступность требует отдельной проверки. W3C требует идентифицировать поле с ошибкой и описать её текстом, но наличие объекта <code>fieldError</code> не заменяет проверку DOM, клавиатуры и выбранных вспомогательных технологий. Не обещайте результат, который не измеряли.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Контракт готов, если автоматическая проверка проходит четыре отрицательные ветки: локально невалидное значение не создаёт попытку; повтор поверх активной попытки не создаёт вторую; ответ со старой версией не меняет текущую ошибку; повторная доставка уже применённого ответа не меняет состояние. Отдельная проверка реального UI должна подтверждать сохранение введённых данных, связь поля с текстом ошибки и восстановление фокуса по правилам продукта.</p>\n<p>Если проходит только успешная отправка, работа не закончена. Успех не проверяет причинную связь. Готовность означает, что каждый показанный текст можно связать с конкретным полем, конкретной попыткой и текущим значением, а старый результат не способен переписать новый ввод.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://html.spec.whatwg.org/multipage/forms.html\" target=\"_blank\" rel=\"noopener noreferrer\">WHATWG HTML Living Standard: Forms</a> — нормативное описание form controls и constraint validation; оно не задаёт проектные поля <code>attemptId</code> и <code>version</code>.</li><li><a href=\"https://www.w3.org/TR/wai-aria-1.3/\" target=\"_blank\" rel=\"noopener noreferrer\">WAI-ARIA 1.3</a> — определяет <code>aria-invalid</code> и <code>aria-errormessage</code>; статья не выдаёт учебный payload за доказательство доступности готового интерфейса.</li><li><a href=\"https://www.w3.org/TR/WCAG22/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C Web Content Accessibility Guidelines 2.2, критерии 3.3</a> — требования к идентификации ошибок, подсказкам исправления и предотвращению повторного ввода.</li></ul>"
}