Créer une interface de recherche React avec une gestion claire de l’état
Créer une interface de recherche React où les événements, les valeurs dérivées, la durée de vie des requêtes et l’affichage des résultats restent séparés, afin que les réponses correspondent à la requête posée.
Ces dysfonctionnements commencent souvent par une responsabilité floue : plusieurs éléments d’état représentent le même fait, ou des effets en déduisent un événement que l’interface a déjà traité.
Pour une application de connaissances basée sur React, commencez par déterminer ce que signifie chaque valeur et quelle opération est autorisée à la modifier.
Séparer l’entrée de la question soumise
Le texte actuellement dans la boîte de recherche et la question associée à une réponse affichée sont deux choses distinctes. Un utilisateur peut modifier l’entrée tout en lisant le résultat précédent.
Modélisez explicitement cette différence. Conservez l’entrée provisoire, l’identité de la requête ou de la demande soumise, ainsi que l’état de la demande résultante. Le résultat doit conserver la requête à laquelle il répond.
Pour une recherche déclenchée par soumission, le gestionnaire de soumission sait déjà qu’une recherche a été demandée. Il peut appeler directement l’opération correspondante. Définir une valeur booléenne uniquement afin qu’un effet puisse la détecter ajoute une transition supplémentaire sans clarifier le flux de travail.
La recherche en temps réel présente des exigences différentes : les résultats doivent suivre une requête en évolution. Une couche de requêtes ou un effet ayant une durée de vie définie peut gérer cette synchronisation. Choisissez d’abord le comportement, puis les limites de l’implémentation.
Dériver des valeurs qui n’ont pas besoin d’un stockage indépendant
Si le compteur des résultats provient du tableau visible, calculez-le à partir de ce tableau. Stocker à la fois le tableau et un compteur mis à jour séparément crée deux valeurs qui peuvent être en désaccord.
Cela vaut également pour les étiquettes générées à partir de l’état actuel et du filtrage simple côté client. Un effet qui copie une valeur React dans une autre est souvent un signe que cette deuxième valeur devrait plutôt être dérivée.
Cela ne signifie pas pour autant que tout état local est redondant. Un brouillon modifiable peut délibérément différer des données serveur. L’essentiel est de définir quand une nouvelle valeur serveur peut remplacer le travail de l’utilisateur.
Attribuer un responsable clair aux tâches asynchrones
Considérez deux questions soumises. La demande A démarre en premier, la demande B en second, et B se termine en premier. Si A remplace ultérieurement le résultat inconditionnellement, l’écran affiche une réponse à la mauvaise question.
Associez les résultats aux identités des requêtes. Seule la requête active peut remplacer le résultat actif. Annulez les tâches obsolètes lorsque le mécanisme de transport le permet, tout en gérant la possibilité que des tâches antérieures se terminent.
Une couche de requêtes peut fournir ces comportements, ou un contrôleur de requêtes dédié peut les mettre en œuvre. Le composant doit utiliser un état explicite tel que inactif, en chargement, avec succès ou en cas d’erreur, plutôt que de coordonner une chaîne d’effets dont les dépendances déclenchent automatiquement l’étape suivante.
Les abonnements, les compteurs temporels et les écouteurs du navigateur nécessitent toujours un nettoyage au cours de leur cycle de vie. Considérez chaque effet comme représentant la propriété d’un processus de synchronisation externe, avec une configuration et un nettoyage qui doivent être cohérents entre eux.
Gardez les preuves attachées à sa réponse
Renvoyez la réponse ainsi que ses références sources en une seule réponse associée à la requête soumise. Lorsque le résultat actif change, mettez-les à jour ensemble.
Une référence source utile comprend un identifiant de source stable et l’emplacement du passage concerné. Le processus de travail axé sur la qualité des sources explique pourquoi un titre seul est insuffisant. Si l’application prend en charge les aperçus des preuves, conservez la relation entre chaque affirmation affichée et le passage fourni pour la justifier.
Distinguez un résultat vide d’une question non répondue et d’une demande échouée. Ces cas impliquent des étapes suivantes différentes pour le lecteur, même si les trois produiraient normalement une liste vide.
Testez l’interaction en des moments peu opportuns
Soumettez rapidement deux questions et ralentissez la première demande. Modifiez les filtres tant qu’une demande est en cours. Quittez l’interface avant sa finalisation. Réessayez en cas d’erreur. Vérifiez que la réponse, l’étiquette de la requête et le panneau de source restent cohérents.
Ces cas étendent l’évaluation RAG à l’interface utilisateur. La qualité des preuves n’a d’importance que si l’utilisateur voit les éléments associés à la réponse qu’il a réellement demandée.