Смена ответа в форме: что делать со скрытыми полями

Покупатель выбрал доставку, ввёл адрес, затем передумал и переключился на самовывоз. Адрес исчез с экрана, но остался в отправленной заявке. Менеджер получил противоречивые сведения и не понял, куда передавать заказ. В форме с ветвлениями недостаточно управлять видимостью вопросов: нужно определить, какие ответы действуют в выбранном сценарии.

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

Начните с карты зависимостей вопросов

В учебной форме есть переключатель «доставка» или «самовывоз». Для доставки нужны адрес и предусмотренный интервал, для самовывоза — точка получения. Контакт используется в обеих ветках. Отсюда следует, что смена основного ответа затрагивает разные поля по-разному: общий контакт остаётся применимым, а адрес перестаёт быть основанием задания.

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

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

Сохранить черновик и включить в заявку — разные решения

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

В другой первой версии можно очищать неприменимые ответы сразу, объяснив это при возврате. Выбор зависит от процесса и требований к хранению. Статья не устанавливает универсальную обязанность сохранять любые введённые сведения. Главное — последовательно выполнить согласованную политику и не выдавать скрытый черновик за подтверждённые данные заявки.

При самовывозе адрес из прежнего шага не используется для задания курьеру. Если компании нужно сохранить отдельную историю ввода, это другой объект и другая цель. Не смешивайте их в одном письме менеджеру без подписей. Итоговая заявка должна однозначно описывать выбранное действие.

Скрытие элемента само по себе не задаёт состав отправки

Документация MDN показывает, что input с типом hidden предназначен для невидимых пользователю данных, которые всё равно могут отправляться с формой. Отдельно MDN описывает disabled: отключённые элементы не участвуют в обычной отправке формы и проверке ограничений. Эти механизмы имеют разный смысл; слово «скрытый» не является готовым правилом исключения ответа.

Если программа собирает собственный JSON из состояния, одного атрибута disabled также недостаточно для доказательства состава запроса. Код может вручную включить сохранённое значение независимо от стандартной отправки. Поэтому приёмка должна проверять реально подготовленную заявку, а не только внешний вид элементов и наличие атрибута в разметке.

Не превращайте это в требование хранить всю бизнес-логику только в браузере. Серверу тоже нужно определить допустимые поля и проверить их связь с выбранным сценарием. Клиентское скрытие помогает интерфейсу, но не подтверждает корректность присланных сведений. Для проверки достаточно согласованных тестовых входов, без исследования чужих форм или рабочих данных посетителей.

Проверка обязательности должна следовать текущей ветке

После переключения на самовывоз нельзя требовать заполнить невидимый интервал курьера, если он больше не относится к задаче. Пользователь увидит отказ, но не сможет понять, что исправлять. Обратная ошибка — сделать необязательной точку получения только потому, что раньше действовала доставка. Требования к полям нужно вычислять по текущему сценарию.

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

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

Возврат назад проверяется как отдельный маршрут

Простой сценарий идёт только вперёд: доставка, адрес, контакт, отправка. Он не обнаруживает большинство ошибок ветвления. Добавьте путь назад к способу получения, переключение на самовывоз и повторное прохождение. Затем вернитесь к доставке и проверьте согласованную судьбу адреса: восстановился как черновик или требует нового ввода.

У пути должен быть известный конечный результат. Например, последним выбран самовывоз из точки П1, контакт сохранён, адрес не участвует в задании курьеру. Изображение последнего экрана не доказывает такой результат. Сверьте сохранённую тестовую заявку и сообщение ответственному, если его отправка предусмотрена процессом.

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

Зависимая сумма должна пересчитываться по тому же основанию

Если выбранная ветка влияет на расчёт, старые значения не должны продолжать участвовать скрыто. Для учебной демонстрации можно задать две условные составляющие без денежных единиц: базовое значение 10 и добавку доставки 3. При доставке получается 13, при самовывозе — 10. Это только арифметическая проверка зависимости, не тариф магазина и не оценка разработки.

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

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

Сохранённый черновик тоже требует проверки применимости

Пользователь может вернуться к форме после изменения её правил. Ранее сохранённые ответы не обязаны соответствовать новому набору вопросов. Определите, что восстанавливается автоматически, а что требует повторного подтверждения. Не объявляйте старый черновик полностью готовым только потому, что все его поля когда-то имели значения.

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

Состояние после входа, обновления страницы и возврата по предусмотренной кнопке проверяйте отдельно. Не каждая форма обязана поддерживать одинаковый объём восстановления. Но заявленные возможности должны быть проверены, а отсутствие поддержки — обработано понятно. Автоматическое заполнение браузером также не должно делать неприменимый ответ действующим основанием заявки.

Как принять исправление

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

Проверку получения самой заявки можно продолжить по разбору формы, которая пишет об успехе без сохранённого обращения. Здесь критерий другой: полученная заявка действительно отражает последний выбранный сценарий. Когда карта зависимостей, проверка и отправка согласованы, пользователь может передумать без риска незаметно оставить в заказе ответ из прежней ветки.