Создайте интерфейс поиска на React с четким определением владельца состояния

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

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

Для приложения на React начните с определения того, что означает каждое значение и какая операция разрешена для его изменения.

Разделяйте вводные данные и отправленный вопрос

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

Модель должна явно отражать эту разницу. Сохраняйте черновик входных данных, идентификатор отправленного запроса или заявки, а также состояние результата. Результат должен сохранять запрос, на который он отвечает.

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

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

Вычисление значений, не требующих отдельного хранения

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

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

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

Укажите четкого ответственного за асинхронную работу

Рассмотрим два отправленных вопроса. Запрос A начинается первым, запрос B — вторым, и B завершается раньше. Если позже A безусловно заменяет результат, на экране отображается ответ на неверный вопрос.

Связывайте результаты с идентификаторами запросов. Только активный запрос может заменить активный результат. Отменяйте устаревшие операции, если транспортный слой поддерживает отмену, но при этом учитывайте возможность завершения более ранних операций.

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

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

Сохраняйте доказательства вместе с ответом

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

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

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

Проверьте взаимодействие при невыгодном времени

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

Эти случаи расширяют оценку RAG на интерфейс. Качество доказательств имеет значение только в том случае, если пользователь видит доказательства, связанные с ответом, который он на самом деле запросил.