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

Бекенд пошуку може знаходити правильні документи, проте все одно створювати заплутану ситуацію для користувача. Повільна відповідь на попереднє запитання може перезаписати новіший результат. Кількість фільтрів може відставати від списку. Панель джерел може відображати посилання з попередньої відповіді.

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

Для додатку з базою знань на React спочатку потрібно визначити, що означає кожне значення та яка операція дозволена для його зміни.

Розділіть вхідні дані від надісланого запитання

Текст, який зараз знаходиться у полі пошуку, та запитання, пов’язане з відображеним результатом, — це різні речі. Користувач може редагувати вхідні дані під час читання попереднього результату.

Модель має чітко відображати цю різницю. Зберігайте чернетку вхідних даних, ідентифікатор надісланого запиту чи прохання та стан отриманого запиту. Результат має зберігати саме той запит, на який він відповідає.

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

У режимі реального часу пошук має інші вимоги: результати мають відстежувати зміни запиту. Шар запитів чи ефект із заданим терміном життя може забезпечувати таку синхронізацію. Спочатку виберіть поведінку, а потім межі реалізації.

Отримувати значення, які не потребують окремого зберігання

Якщо кількість результатів визначається за допомогою видимого масиву, обчислюйте її на основі цього масиву. Зберігання як самого масиву, так і окремо оновлюваної кількості створює два значення, які можуть не збігатися.

Те саме стосується етикеток, створених на основі поточного стану та простого фільтрування з боку клієнта. Ефект, при якому одне значення React копіюється в інше, часто є ознакою того, що друге значення слід отримувати шляхом обчислення.

Це не означає, що весь локальний стан є зайвим. Редактований проєкт може навмисно відрізнятися від даних сервера. Важливо визначити, коли нове значення з сервера може замінити роботу користувача.

Визначте чіткого власника асинхронних завдань

Розглянемо два надіслані запити. Запит A починається першим, запит B — другим, і B завершується раніше. Якщо пізніше A безумовно замінює результат, на екрані відображається відповідь на неправильне запитання.

Пов’язуйте результати з ідентифікаторами запитів. Лише активний запит може замінити активний результат. Скасовуйте застарілі операції, якщо механізм передачі даних дозволяє це робити, водночас враховуючи можливість завершення попередніх операцій.

Шар запитів може забезпечувати цю поведінку, або окремий контролер запитів може її реалізувати. Компонент має використовувати чіткий стан, такий як «неактивний», «завантаження», «успіх» чи «помилка», замість координації ланцюга ефектів, залежності яких випадково запускають наступний крок.

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

Зберігайте докази разом із відповіддю

Поверніть відповідь та її джерельні посилання як одну відповідь, пов’язану з поданою запитанням. Коли активний результат змінюється, оновлюйте їх разом.

Корисне джерельне посилання включає стабільний ідентифікатор джерела та місцезнаходження уривка. процес роботи з якістю джерел пояснює, чому сама назва є недостатньою. Якщо додаток підтримує попередній перегляд доказів, зберігайте зв’язок між кожним відображеним твердженням та уривком, наданим для його підтвердження.

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

Перевірте взаємодію у незручний час

Швидко надішліть два запитання, а перший запит зробіть повільнішим. Змінюйте фільтри під час активного запиту. Виходьте з інтерфейсу до його завершення. Спробуйте знову після помилки. Перевіряйте, чи залишаються відповідь, позначка запиту та панель джерел консистентними.

Ці випадки розширюють оцінку RAG на сам інтерфейс. Якість доказів має значення лише тоді, коли користувач бачить докази, пов’язані з відповіддю, яку він насправді запитав.