Форма показывает старые данные после нового выбора

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

Ниже рассмотрена учебная форма с условными городами А и Б. Проблема относится к асинхронным подсказкам, зависимым спискам и другим данным, запрашиваемым после ввода. Это не диагностика конкретной службы доставки. Все ответы вымышлены; для воспроизведения не нужны настоящие адреса покупателей или создание реальных заказов. Проверяется согласованность состояния интерфейса, а доступность услуг требует самостоятельной серверной проверки.

Почему последний ответ может относиться к прошлому выбору

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

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

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

Проверяйте попытку, а не только значение поля

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

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

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

Отмена запроса и актуальность результата решают разные задачи

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

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

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

Старые ошибки и индикатор ожидания тоже способны опоздать

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

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

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

Очистка выбора должна прекращать право старого ответа

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

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

Сохранение черновика рассматривайте отдельно. Можно помнить ранее выбранный пункт, но восстановленный выбор нужно сопоставить с действующими условиями. Сам факт, что значение когда-то было допустимо для А, не делает его допустимым для Б. В статье о смене ветки формы разобран состав отправляемых данных; здесь проверяется приход новых данных в неправильный момент.

Отправка заявки проверяется отдельно от подсказок

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

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

Воспроизводимый тест полезнее случайных быстрых кликов

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

Отдельно пройдите А → Б → А и верните старый ответ А после нового. Затем замените устаревший ответ ошибкой, очистите поле во время ожидания и закройте окно. У каждого сценария заранее задайте ожидаемое состояние результата, сообщения и индикатора. Такие проверки показывают границы исправления лучше одного удачного прохождения формы.

В учебной проверке с управляемыми Promise старое присваивание перезаписало Б результатом А. Проверка номера попытки сохранила новый результат, включая возврат к А, и не показала ошибку устаревшего Б. Это проверка ограниченной модели без реального сетевого API. После переноса решения в проект нужны собственные испытания браузерного поведения, кеша и полного пути отправки заявки.