Тендеры и лиды
Информация
Человек вводит «камера», а под строкой поиска появляются карандаши. Сеть работает, сервер вернул корректные данные, карточки аккуратно нарисованы. Ошибка возникает между этими частями: интерфейс показывает результат предыдущего запроса. Разберём учебный пример для дизайнера, разработчика и менеджера, которые передают поиск в реализацию.
Материал подготовлен с AI-помощью. Пример синтетический, без данных пользователей и без заявления о дефекте конкретного продукта. Проверка порядка ответов выполнена отдельно в небольшом локальном сценарии.
В нашем примере поиск отправляет запрос после каждого из трёх изменений: «ка», «кам», «камера». Для первого сервер подготовил «карандаш», для второго - «камера», для третьего - «камера для поездок». Все три ответа правильные относительно своих запросов. Но порядок их возвращения не обязан совпадать с порядком ввода.
Представим такую последовательность событий: запрос 1 отправлен для «ка»; запрос 2 - для «кам»; запрос 3 - для «камера». Затем возвращается ответ 3, после него ответ 1 и последним ответ 2. Если каждый ответ просто заменяет список, на экране останется результат для «кам». Поле при этом продолжит показывать «камера».
Один скриншот успешного поиска не определяет, что делать с этим конфликтом. В передаче макета нужна явная договорённость: какой ответ имеет право обновить список. Для этого примера правило такое: обновление разрешено только ответу, относящемуся к текущей версии поискового намерения.
На каждое изменение поискового намерения увеличиваем счётчик. Запрос получает текущий номер. Перед изменением интерфейса обработчик сравнивает номер своего запроса с актуальным. Если номера не совпадают, ответ больше не относится к текущему состоянию и не меняет ни список, ни индикатор загрузки.
Почему недостаточно сравнить текст? Человек может ввести «камера», затем «штатив», затем снова «камера». Первый и третий запросы имеют одинаковую строку, но относятся к разным действиям. Текущую версию должны учитывать также категория, сортировка, страница и другие параметры, которые влияют на результат. Для фильтра с несколькими полями полезно передавать согласованный снимок всех параметров.
Это правило выбора ответа, а не требование конкретной библиотеки. В браузерной реализации отмена fetch через AbortController может сократить ненужную работу. Однако обработчик результата всё равно стоит привязать к актуальной версии: ответ мог уже перейти в последующую обработку, а тестовый источник или другой клиент может иметь собственный механизм отмены.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13836 тендеров
проведено за восемь лет работы нашего сайта.
Вместо набора несвязанных картинок передайте несколько состояний и переходы между ними. Ниже - конкретный вариант поведения для этого учебного поиска. Команда может выбрать другое, но выбор должен быть общим.
1. Пустое поле. Запрос не отправляется. Подсказка объясняет, что искать. Старый список очищается, а все находящиеся в работе ответы становятся неактуальными.
2. Ожидание после изменения ввода. Поле уже содержит новый текст. Если используется задержка перед отправкой, это ещё не подтверждённая загрузка с сервера. В макете следует указать, остаются ли старые карточки видимыми и доступны ли они для выбора.
3. Загрузка актуального запроса. Интерфейс показывает, что обновляет результаты. В нашем варианте старые карточки скрыты и не выбираются, чтобы пользователь не принял их за ответ на новый запрос. Это выбранный компромисс, а не универсальная рекомендация для любого поиска.
4. Успешный непустой ответ. Отображаются карточки актуальной версии. Индикатор прекращается. Заголовок списка или подпись позволяет связать результаты с текущим запросом.
5. Успешный пустой ответ. Показывается «По запросу „камера“ ничего не найдено». Это подтверждённый ответ сервера, а не состояние до первого запроса. Текст может предложить изменить запрос или фильтры.
6. Ошибка актуального запроса. Пользователь видит понятный способ повторить поиск. Повтор получает новую версию, даже если текст не изменился. Ошибка устаревшего запроса не должна заменять текущий успешный результат.
7. Устаревший ответ. Визуального перехода нет. Ответ не очищает карточки, не выключает загрузку нового запроса и не показывает собственную ошибку. Этот пункт легко пропустить: его нельзя изобразить отдельным красивым экраном, но можно записать как правило.
Чтобы проверить именно правило, не обязательно ждать случайной задержки реальной сети. В локальной модели были заранее созданы три ответа. Затем они подавались обработчику во всех шести перестановках: 1-2-3, 1-3-2, 2-1-3, 2-3-1, 3-1-2 и 3-2-1. Все запросы в этой модели считаются отправленными до прихода первого ответа.
Обработчик «пришёл ответ - заменить список» оставил результат запроса 3 только в двух из шести перестановок. Обработчик с проверкой актуального номера сохранил его во всех шести. Это не статистика отказов в интернете: перестановки не описывают вероятность, сетевую скорость или нагрузку. Они перебирают небольшой набор возможных порядков.
Отдельный сценарий проверил очистку поля до прихода последнего ответа. Очистка увеличивала актуальную версию, поле и список переходили в пустое состояние, а запоздалый ответ не возвращал результаты. Проверка прошла. Если увеличивать счётчик только при отправке запроса, этот случай можно пропустить: после очистки нового запроса как раз нет.
Начните с ответа, который приходит позже нового успешного результата: он не должен менять экран. Затем верните старую ошибку во время новой загрузки: индикатор актуального запроса должен остаться. Очистите поле до ответа: список должен остаться пустым. Повторите тот же текст после другого запроса: приниматься должен только новый номер. Наконец, поменяйте категорию при неизменном тексте: прежняя категория не должна вернуться вместе с задержавшимися данными.
Проверьте и выбор карточки с клавиатуры. Если старые результаты временно остаются видимыми, договоритесь, как они помечаются и можно ли активировать их нажатием Enter. В нашем варианте они скрыты, поэтому активный пункт старого списка тоже сбрасывается. Доступность и фокус нужно проверять в реализованном интерфейсе: модель перестановок этого не доказывает.
Эта проверка не моделирует кэш, пагинацию, серверное ранжирование или длительное отсутствие сети. Для этих режимов потребуются отдельные условия. Но даже маленькая модель уже заставляет определить важную границу: ответ относится к конкретному намерению пользователя, и его приход сам по себе не даёт права менять экран.
Передайте разработчику текущие параметры, правило актуальности ответа, поведение старых карточек и пять сценариев выше. Дизайнер сможет проверить состояния, разработчик - переходы, а менеджер - наблюдаемый результат приёмки. У макета появится проверяемое поведение, которое нельзя восстановить только по картинке успешного поиска.
Олжас Азирали, основатель AZIRAL с 2019 года.
