{
  "index": 315,
  "slug": "editorial-2019-04-practice-forms-validation",
  "title": "Валидация формы без ложного успеха: поле, API и устаревший ответ",
  "excerpt": "Браузер проверяет формат, сервер принимает бизнес-решение, а асинхронный ответ должен относиться к текущему значению. Разбираем контракт ошибки, доступную разметку и воспроизводимую защиту от гонки запросов.",
  "contentHtml": "<p>Форма показывает зелёную почту, пользователь нажимает «Сохранить», а API отвечает 422. В другом варианте человек быстро меняет логин: проверка нового значения возвращает «свободен», затем поздний ответ для старого рисует ошибку под новым. Цена ошибки — повторные попытки и неверное решение пользователя. Для регистрации или платежа это может закончиться отказом в корректной операции.</p>\n<p>Граница проходит между тремя задачами. Браузер быстро проверяет ограничения самого поля. Клиент связывает результат с текущим состоянием интерфейса. Сервер повторяет критичные проверки и решает, можно ли сохранить данные. Если ответ сервера не связан с именем поля и версией значения, одна новая регулярка расхождение не исправит.</p>\n<h2>Что именно проверяет каждый слой</h2>\n<p>HTML отсекает локальные нарушения: пустое обязательное поле, неподходящий тип, длину и шаблон. У элемента формы есть объект <code>validity</code>. Методы <code>checkValidity()</code> и <code>reportValidity()</code> проверяют ограничения формы; второй дополнительно просит браузер показать пользователю найденные проблемы. Это ранний фильтр, а не проверка состояния базы.</p>\n<p>Например, <code>type=\"email\"</code> проверяет синтаксис, который браузер считает адресом электронной почты. Атрибут <code>required</code> запрещает пустое значение, а <code>minlength</code>, <code>maxlength</code> и <code>pattern</code> задают локальные ограничения. Ни один из них не знает, занят ли логин, имеет ли пользователь право на действие или изменилось ли значение записи на сервере.</p>\n<p>Клиентский код владеет отображением и переходами состояния. После ввода он должен убрать ошибку, относящуюся к прежнему значению, а после ответа — проверить, что ответ всё ещё принадлежит этому полю и этой версии. Сервер владеет нормализацией, правами, ограничениями данных и окончательным результатом сохранения. Запрос можно отправить напрямую, поэтому браузерные ограничения не заменяют серверную проверку.</p>\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>Поле зелёное, API отвечает 422</td><td>Клиент проверил формат, сервер — бизнес-условие</td><td>Сравнить локальные ограничения с кодом и телом ответа</td><td>Показать серверную ошибку у поля и оставить сервер источником истины</td></tr><tr><td>Ошибка относится к соседнему полю</td><td>Код ищет слово в тексте или принимает неизвестный ключ</td><td>Проверить карту <code>field → error</code></td><td>Известный ключ связать с input, неизвестный отправить в общий блок формы</td></tr><tr><td>Старый ответ стирает новый ввод</td><td>Обработчик применяет любой завершившийся запрос</td><td>Замедлить первый ответ и изменить значение до его завершения</td><td>Сравнить номер запроса или версию перед изменением состояния</td></tr><tr><td>Ошибка видна только рамкой</td><td>Нет видимого текста и связи с контролом</td><td>Пройти форму клавиатурой и проверить accessibility tree</td><td>Добавить <code>label</code>, текст ошибки и ID-связь</td></tr></tbody></table></div>\n<h2>Контракт ответа должен указывать поле</h2>\n<p>Формат ошибки ниже — договор конкретного приложения, а не встроенный формат браузера. Важны стабильные имена полей и машинные коды; сообщение предназначено для показа человеку и не должно использоваться как идентификатор маршрутизации.</p>\n<pre><code>{\n  \"code\": \"VALIDATION_FAILED\",\n  \"fields\": {\n    \"email\": [\n      { \"code\": \"email_taken\", \"message\": \"Этот адрес уже используется\" }\n    ]\n  },\n  \"form\": []\n}</code></pre>\n<p>Адаптер принимает только известные имена. Если сервер прислал неизвестный ключ, безопаснее показать нейтральную ошибку формы и сохранить технический код для диагностики, чем приклеить сообщение к первому input. По тексту «занят» нельзя надёжно определить, какое поле нужно исправить.</p>\n<pre><code>function mapServerErrors(payload, knownFields) {\n  var result = { fields: {}, form: [] };\n  var fields = payload &amp;&amp; payload.fields ? payload.fields : {};\n\n  Object.keys(fields).forEach(function (name) {\n    var item = fields[name] &amp;&amp; fields[name][0];\n\n    if (knownFields.indexOf(name) === -1 || !item || !item.message) {\n      result.form.push('Сервер вернул ошибку без известного поля');\n      return;\n    }\n\n    result.fields[name] = item.message;\n  });\n\n  return result;\n}\n\nvar errors = mapServerErrors(apiPayload, ['email', 'password']);</code></pre>\n<p>Пример выбирает первое сообщение и не решает локализацию, вложенные массивы или несколько ошибок на одном поле. Эти решения нужно закрепить отдельно. Сообщение вставляют как текст, а не как HTML: ответ API не получает права изменить разметку страницы.</p>\n<h2>Ошибка должна принадлежать текущему input</h2>\n<p>У поля есть видимый <code>label</code>, постоянная подсказка и контейнер ошибки. <code>aria-describedby</code> связывает input с описательным текстом по ID. <code>aria-invalid=\"true\"</code> сообщает, что текущее значение не прошло проверку. <code>aria-errormessage</code> можно использовать для ссылки на текст ошибки, но он должен сопровождать ошибочное состояние. В валидном состоянии удалите эту ссылку или скройте сам текст так, чтобы он не воспринимался как актуальная ошибка.</p>\n<pre><code>&lt;label for=\"email\"&gt;Почта&lt;/label&gt;\n&lt;input id=\"email\" name=\"email\" type=\"email\"\n  required autocomplete=\"email\"\n  aria-describedby=\"email-hint email-error\"\n  aria-errormessage=\"email-error\"\n  aria-invalid=\"true\"&gt;\n&lt;p id=\"email-hint\"&gt;Укажем адрес для входа.&lt;/p&gt;\n&lt;p id=\"email-error\"&gt;Этот адрес уже используется&lt;/p&gt;</code></pre>\n<p>При новом вводе сначала запишите новое значение, очистите прежнюю серверную ошибку и снимите <code>aria-invalid</code>, если поле больше не признано ошибочным. Затем запускайте следующую проверку. Красная рамка не заменяет текст, а постоянный <code>role=\"alert\"</code> на всей форме может превратить каждое изменение в шум. Фокус после submit можно перевести на первое проблемное поле; короткий динамический статус следует объявлять отдельно и умеренно.</p>\n<h2>Поздний ответ проверяет не то значение</h2>\n<p>Рассмотрим автономный сценарий без настоящей сети. Пользователь вводит <code>ivan</code>, для него задана задержка 30 мс. Затем ввод меняется на <code>ivanka</code>, второй запрос задерживается на 5 мс. Второй ответ придёт первым и должен примениться. Первый ответ означает «логин занят», но к моменту его прихода уже относится к старому значению.</p>\n<pre><code>function delayResult(value, delayMs) {\n  return new Promise(function (resolve) {\n    setTimeout(function () {\n      resolve({ value: value, available: value !== 'ivan' });\n    }, delayMs);\n  });\n}\n\nvar state = { value: '', requestId: 0, phase: 'idle', error: '' };\n\nfunction checkLogin(value, delayMs) {\n  var requestId = state.requestId + 1;\n  state = { value: value, requestId: requestId, phase: 'checking', error: '' };\n\n  return delayResult(value, delayMs).then(function (answer) {\n    if (requestId !== state.requestId || value !== state.value) {\n      return { applied: false, reason: 'stale-response' };\n    }\n\n    state = {\n      value: value,\n      requestId: requestId,\n      phase: answer.available ? 'valid' : 'invalid',\n      error: answer.available ? '' : 'Этот логин уже занят'\n    };\n\n    return { applied: true, state: state };\n  });\n}\n\nvar first = checkLogin('ivan', 30);\nvar second = checkLogin('ivanka', 5);\n\nPromise.all([first, second]).then(function (results) {\n  console.assert(results[0].applied === false);\n  console.assert(results[1].applied === true);\n  console.assert(state.value === 'ivanka' &amp;&amp; state.phase === 'valid');\n});</code></pre>\n<p>Итоговый объект содержит <code>ivanka</code>, фазу <code>valid</code> и пустую ошибку. Первый promise возвращает <code>stale-response</code> и не вызывает изменение состояния. Код проверяет и номер запроса, и значение: проверка значения даёт дополнительную защиту от ошибки владельца, если счётчик был восстановлен неправильно.</p>\n<p>Счётчик должен принадлежать конкретному экземпляру поля или формы. Глобальный номер на всём сайте создаст взаимное влияние между двумя независимыми полями. В React, Vue или другом фреймворке правило то же: на <code>input</code> фиксируются новое значение и версия, а обработчик ответа получает актуальное состояние владельца перед <code>render</code>.</p>\n<p><code>AbortController</code> может отменить поддерживаемую сетевую операцию и сэкономить ресурсы. Он не заменяет проверку версии: ответ мог уже разрешиться, сервер мог обработать запрос до отмены, а другой транспорт может игнорировать сигнал. Сначала защищают право менять состояние, затем добавляют отмену как оптимизацию.</p>\n<figure><img src=\"/assets/editorial/2019/forms-validation-contract-2019.svg\" alt=\"Схема валидации формы: HTML даёт раннее ограничение, клиент хранит значение и номер запроса, API возвращает ошибку поля, а старый ответ не меняет новое состояние\" loading=\"lazy\" /><figcaption>Валидация разделена между HTML, клиентским состоянием и API. Номер запроса не позволяет позднему ответу старого значения изменить текущий input.</figcaption></figure>\n<h2>Submit — отдельный переход</h2>\n<p>Проверка поля и сохранение — разные операции. При submit браузер может выполнить constraint validation. Затем клиент решает, есть ли локальная ошибка или незавершённая удалённая проверка. После этого запрос сохранения уходит на сервер, который снова проверяет весь вход.</p>\n<p>Для фазы <code>checking</code> заранее выберите политику: дождаться текущего результата, разрешить submit и принять окончательный ответ API или временно отключить кнопку с понятным объяснением. Нельзя объявлять форму готовой только потому, что регулярное выражение прошло. Предварительный запрос «логин свободен» не резервирует имя: другой клиент может занять его до сохранения.</p>\n<p>Ответ операции сохранения имеет приоритет над предварительной проверкой. Если сервер вернул конфликт, адаптер должен показать его у актуального отправленного поля. Если человек успел изменить поле до прихода ответа, старый результат снова нельзя рисовать над новым значением.</p>\n<h2>Порядок внедрения и проверки</h2>\n<ol><li>Выпишите поля формы и разделите для каждого локальное ограничение, серверное условие и общий сбой формы.</li><li>Согласуйте с API стабильные ключи полей и коды ошибок. Неизвестный ключ направляйте в общий контейнер, а не к случайному input.</li><li>Добавьте честные HTML-ограничения: <code>required</code>, тип, длину и <code>pattern</code>. Не копируйте в браузер всю бизнес-логику.</li><li>Сделайте у каждого поля <code>label</code>, устойчивые ID подсказки и ошибки. Показывайте текст, а не только цвет.</li><li>На каждом <code>input</code> очищайте старую серверную ошибку и увеличивайте версию. При старте async-проверки сохраните эту версию.</li><li>В обработчике ответа сравните версию и, при необходимости, значение с актуальным состоянием до любого изменения UI.</li><li>Проверьте submit для пустого значения, неверного формата, известной ошибки поля, неизвестного ключа, сетевой ошибки и ответов в обратном порядке.</li><li>Пройдите сценарий клавиатурой и проверьте accessibility tree: имя поля, актуальный текст ошибки, <code>aria-invalid</code> и ID-связи должны описывать одно значение.</li><li>Повторите критичную проверку перед сохранением на сервере и воспроизведите конфликт между положительной предварительной проверкой и фактическим POST.</li></ol>\n<h2>Ограничения</h2>\n<p>Проверка доступности логина до сохранения не резервирует логин. Сервер обязан проверить условие в момент записи. Проверка версии защищает состояние интерфейса, но не делает сохранение идемпотентным, не отменяет транзакцию и не решает авторизацию. Для зависимых полей отдельно определите, очищает ли изменение одного поля результат другого.</p>\n<p>Если API не возвращает имя поля, нельзя достоверно показать ошибку под конкретным input. Не угадывайте поле по тексту сообщения: покажите нейтральную ошибку формы, сохраните код и договоритесь об изменении контракта. Если компонент уничтожен, поздний ответ должен завершиться без <code>render</code>. <code>setCustomValidity()</code> полезен для собственной локальной ошибки, но его нужно очистить при новом вводе и не использовать как замену серверному правилу.</p>\n<p>Учебный код доказывает только порядок двух promise. Он не измеряет задержки реального API, поддержку конкретного браузера, доступность выбранного компонента или поведение базы. Эти свойства проверяют на целевом контуре: с клавиатурой, Accessibility tree, сетевой ошибкой и конкурентным сохранением.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Форма готова, если тест с двумя обратными задержками оставляет последнее значение, его номер запроса, корректную фазу и пустую старую ошибку. Ответ для прежнего значения не вызывает <code>render</code>. После изменения input сообщение очищается. Известная ошибка API появляется у нужного поля, неизвестная — в общем блоке, а сервер отклоняет конфликт даже после положительной предварительной проверки.</p>\n<p>На реальном экране проверяющий должен пройти форму клавиатурой, увидеть метку и ошибку, открыть Accessibility tree и подтвердить связи по ID. Если этот прогон или серверный конфликт не проверены, готовность ограничивается локальным примером и не распространяется на весь пользовательский сценарий.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://html.spec.whatwg.org/multipage/forms.html\" target=\"_blank\" rel=\"noopener noreferrer\">WHATWG HTML Standard: Forms</a> — описывает constraint validation, свойства <code>validity</code> и методы <code>checkValidity()</code>/<code>reportValidity()</code>.</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-describedby</code> и <code>aria-errormessage</code> и их связь с текущим состоянием.</li></ul>"
}