Опишите состояния до того, как рисовать индикатор
Это предлагаемый процесс для туристического приложения разработчика, а не запись наблюдавшегося поведения API. Турист вводит offline maps, запрашивает историческое обсуждение и ждёт. Приложению нужно различать нетронутую форму, незавершённый запрос, полученные записи, успешный пустой ответ и ошибку. Одна пустая панель не передаёт эти разные ситуации.
Начните с нейтрального начального экрана, объясняющего область поиска. Ввод текста сам по себе не обязан отправлять запрос. При явной отправке сохраните вопрос вместе с запросом и покажите состояние загрузки. Оставьте ввод читаемым и не позволяйте повторным нажатиям отправить одно действие несколько раз. Индикатор сообщает об ожидании, а не доказывает продвижение поиска по архиву.
Связывайте поздний ответ с его вопросом
Представьте, что турист меняет ввод на downloaded regions, пока запрос offline maps ещё выполняется. Это иллюстративное взаимодействие, а не пример полученного поиска. Приложение должно решить, ждать ли, отправлять ли новый запрос или позволить человеку покинуть представление. Какое бы решение вы ни реализовали, прежний ответ не должен незаметно становиться ответом на новую фразу.
Связывайте каждый запрос с отправленным вводом в собственном состоянии приложения. При получении ответа проверяйте, относится ли он ещё к текущему экрану. Не показывать поздний ответ — не то же самое, что отменить работу сервера: уже отправленный запрос может успешно завершиться и быть оплачен. Проверьте это различие в своей реализации.
Считайте успешный пустой ответ результатом
Для полученных записей показывайте действительно имеющиеся поля и сохраняйте отметку исторического источника. Для пустого массива data используйте отдельное сообщение: этот запрос не вернул записей. Предложите изменить фразу или фильтры, сохранив их для осознанного решения читателя. Не заменяйте пустой ответ выдуманными популярными публикациями.
Успешные пустые запросы стоят один кредит, как и успешные ответы с записями. Поэтому изменения запроса стоит делать осознанно, а не маскировать пустые ответы под ошибки. Не утверждайте, что подходящих обсуждений нигде нет: архив неполон, а ответ связан с конкретным запросом и ограниченным окном.
Передавайте техническую проблему оператору
Ответ 400 требует проверки ввода запроса. Если приложение передало неверную дату или неподдерживаемый параметр, не обвиняйте туриста в нарушении контракта бэкендом. Ответ 401 указывает на отсутствующий или недействительный ключ сервиса; перезагрузка приложения или предложение туристу войти не обязательно исправят эти учётные данные.
Ответ 402 означает недостаток кредитов в аккаунте сервиса. Направьте это решение оператору вместо показа счёта туристу. Ответ 429 требует соблюдать Retry-After и сократить повторные запросы. Поскольку один аккаунт приложения может обслуживать разных читателей, не сообщайте автоматически одному человеку, что именно он вызвал ограничение.
Отделяйте известный сбой от неизвестного исхода
Шлюз возвращает 502 при неудачном запросе к вышестоящему сервису. Зарезервированный кредит освобождается либо отмечается как ожидающий сверки. Сохраните вопрос и прежнюю видимую страницу, затем предложите ограниченную возможность повторить запрос. Многократные автоматические повторы могут лишь увеличить число запросов, не помогая читателю понять случившееся.
Если приложение вообще не получило ответ, ему может быть неизвестно, завершился ли сервер ошибкой или успешно. Зафиксируйте неопределённость для сверки, а не показывайте уверенное утверждение о возврате или успехе. Открытый маршрут /v1/status — статическая проверка назначения сервиса и HTTP-ответа; он не разрешает этот вопрос и не подтверждает исправность архивного поиска.
Проверяйте переходы, а не только снимки экранов
Пройдите предлагаемый сценарий с владельцем приложения: отправка, изменение во время ожидания, пустой ответ, повтор после ошибки, следующая страница и уход с экрана. Для каждого перехода определите сохранённый ввод, видимое содержимое и следующее действие. Красивый макет сам по себе не доказывает, что эти переходы работают.
Не показывайте пользователям диагностику оператора, сырые ответы сервиса и учётные данные. Дайте туристу достаточно контекста, чтобы продолжить подготовку к походу без недоступной функции обсуждений. В /ru/#field-notes разобраны бюджет запросов и действие «Показать ещё», влияющие на этот процесс состояний.
