Автосохранение большой формы: что проверить, чтобы клиент не потерял введённые данные

После возврата форма оказывается пустой

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

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

Состояние React привязано к месту компонента в дереве интерфейса: удаление компонента уничтожает связанное состояние, как объясняет документация React. Это объясняет один класс потерь при смене шагов, но ещё не отвечает на вопрос о закрытом браузере. Заказчику полезнее описать требуемый возврат данных, чем требовать от разработчика конкретную библиотеку. Если подрядчик предлагает заменить весь сайт из-за одной пропадающей анкеты, запросите причину, по которой нельзя исправить хранение ответов отдельно от остальных страниц. Масштаб замены следует из обнаруженного ограничения, а не из названия технологии.

Почему переключение шага стирает ответы

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

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

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

В заявке на исправление назовите оба экрана и поле, которое исчезает, а также укажите, восстанавливается ли оно при повторном переходе вперёд. Это отделяет ошибку отображения от настоящего удаления ответа. Пустой экран при сохранённом значении требует другого исправления, чем отсутствие записи.

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

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

Для localStorage браузер сохраняет данные между сеансами, причём HTTP и HTTPS используют разные области хранения. Это локальная копия. Если человек продолжит заявку на другом устройстве, в другом браузере её не окажется, поэтому обещание продолжить с телефона требует серверного черновика и отдельного способа узнать пользователя.

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

Значок сохранения относится к конкретной версии

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

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

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

Закрытие браузера нельзя делать единственным моментом записи

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

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

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

Восстановление не должно незаметно подменять новую работу

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

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

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

Испытание одной заявки в нескольких состояниях

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

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

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

Задание описывает предел потери последних правок

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

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

Приложите заполненный лист испытаний и перечень браузеров, в которых принимает работу маркетолог: команда разработки ШТАБ ИТ сможет оценить объём по конкретным состояниям формы. На демонстрации восстанавливают длинную заявку с последними изменениями и продолжают её до завершения, чтобы увидеть, исполнено ли обещание сохранения.