Suggestions asynchrones avec debounce

Au lieu de filtrer un tableau local, appelez un point de terminaison d’API qui renvoie les suggestions correspondant à la requête. L’appel à l’API se place dans un useEffect qui dépend de la valeur de saisie temporisée. Le filtrage est ainsi confié au serveur, ce qui permet d’effectuer une correspondance approximative, un classement et de proposer des suggestions provenant d’un ensemble de données beaucoup plus vaste.

Ajoutez deux nouvelles variables d’état à la saisie semi-automatique : isLoading (un booléen) pour afficher un indicateur pendant l’exécution de la requête, et error (une chaîne ou une valeur nulle) pour afficher un message d’erreur lorsque la requête échoue. Elles informent l’utilisateur de l’opération asynchrone au lieu de le laisser se demander pourquoi les suggestions n’apparaissent pas.

Dans le useEffect de récupération, appelez setIsLoading(true) et setError(null) au début, puis fetch(url), analysez le JSON, appelez setSuggestions(data) et, enfin, appelez setIsLoading(false) dans un bloc de finalisation ou après les chemins de réussite et d’erreur. Le tableau de dépendances de l’effet contient uniquement debouncedInputValue.

Créez un nouvel AbortController au début de l’effet et transmettez controller.signal aux options de la requête. Dans la fonction de nettoyage, appelez controller.abort(). Lorsque l’utilisateur saisit du texte et que la valeur temporisée change, la requête précédente est annulée avant le démarrage de la nouvelle, ce qui empêche les résultats obsolètes d’arriver dans le désordre.

Lorsqu’une requête est annulée, elle est rejetée avec une DOMException nommée AbortError. Dans votre bloc d’interception, vérifiez if (err.name === 'AbortError') return; afin d’ignorer silencieusement les requêtes annulées. Ne gérez que les véritables erreurs réseau ou les erreurs d’API qui doivent être présentées à l’utilisateur.

Définissez isLoading sur true avant la requête et sur false une fois celle-ci terminée ou rejetée. Utilisez un bloc finally pour garantir sa réinitialisation : fetch(url).then(...).catch(...).finally(() => setIsLoading(false)). Sans ce bloc de finalisation, une erreur de requête laisserait l’indicateur tourner indéfiniment.

Lorsque isLoading vaut true et que le champ de saisie contient du texte, affichez la liste déroulante avec un indicateur centré à l’intérieur plutôt que la liste de suggestions. L’utilisateur comprend ainsi que les résultats sont en cours d’arrivée. Une fois le chargement terminé et les suggestions reçues, remplacez l’indicateur par les véritables éléments de suggestion.

Lorsque error n’est pas nul, affichez la liste déroulante avec le message d’erreur à la place des suggestions. Un message comme « Impossible de charger les suggestions. Veuillez réessayer. » est plus convivial qu’une chaîne d’erreur brute. Vous pouvez aussi ajouter un bouton de nouvelle tentative qui relance manuellement la requête.

Évitez d’effectuer des requêtes pour des chaînes vides ou des requêtes très courtes qui produisent trop de résultats non pertinents. Ajoutez cette vérification au début de l’effet : if (debouncedInputValue.length < 2) { setSuggestions([]); return; }. Vous réduisez ainsi les appels d’API inutiles et évitez d’afficher une liste de résultats trop imposante pour un seul caractère.

Stockez les résultats récupérés dans une carte gérée par un useRef : const cache = useRef(new Map()). Avant d’effectuer la requête, vérifiez if (cache.current.has(query)) { setSuggestions(cache.current.get(query)); return; }. Après une requête réussie, stockez le résultat. Cela supprime les requêtes réseau redondantes pour les requêtes que l’utilisateur a déjà saisies.

Pour la saisie semi-automatique, un délai de temporisation de 200 à 300 ms constitue le meilleur compromis. Des délais plus courts, inférieurs à 200 ms, déclenchent trop de requêtes chez les personnes qui saisissent rapidement. Des délais plus longs, supérieurs à 400 ms, donnent une impression de lenteur et de manque de réactivité. 250 ms est une valeur par défaut couramment utilisée dans les implémentations de saisie semi-automatique en production.

Pourquoi AbortController est-il important dans une saisie semi-automatique temporisée qui récupère des données depuis une API ?

Remplacez le filtrage statique par une requête API dans un useEffect qui dépend de la valeur temporisée. Utilisez AbortController pour annuler les requêtes obsolètes. Ajoutez les états isLoading et error pour informer l’utilisateur. Définissez un seuil minimal de caractères afin d’éviter les appels excessifs. Mettez les résultats en cache dans une référence pour éviter les requêtes réseau redondantes.