Dérivations asynchrones dans React

Nous avons un problème, l'async est difficile.

Imaginez que vous ayez une simple API GET, une recherche qui reçoit en paramètre un searchText. Vous l'appelez en utilisant votre outil de requête http de préférence et obtenez une promesse, il résout la liste de tout ce que vous recherchez.

Comment puis-je l'appeler dans un composant React ?

Tout d’abord, il est important de remarquer une chose, ce que j’ai décrit peut être modélisé comme :

result = await searchAPI(searchText);

Soyons conceptuels ici. C'est une dérivation. Pour chaque version de searchText, vous pouvez obtenir un résultat différent. Mais il y a quelques problèmes ici :

• ce sont des données externes.
• il renvoie une promesse.

Comment puis-je l'appeler une dérivation dans React ?

L'utilisation de bibliothèques tierces, telles que TanStack Query et SWR, résout notre problème. Ils nous donnent des hooks que nous pouvons utiliser dans un composant React, recevant nos états et accessoires et recalculant (récupérant) vers l'API lorsqu'elle change. Regardez cet exemple :

const { data: searchResult, loading } = useQuery({queryKey: [search, searchText],queryFn: getSearch,});

Ok, nous avons résolu la dérivation asynchrone, n'est-ce pas ?

Pas vraiment.

Au fait, je recommande toujours d'utiliser simplement une de ces bibliothèques, elles sont géniales et permettent de gagner beaucoup de temps avec des cas plus complexes (comme la récupération, la nouvelle tentative, le contrôle du cache, etc.), mais nous ne pouvons pas compter sur une troisième -partie pour résoudre un problème conceptuel de React.

Pour en revenir à la réactivité, nous devons avoir un moyen de traiter les cas asynchrones dans un modèle de dérivation. React devrait nous donner une primitive pour ce cas. Eh bien, jusqu'à la version 18, nous ne l'avions pas, mais dans la 19, c'est différent.

Le cas « d’utilisation »

React 19 introduit une nouvelle primitive appelée use. Oui, le nom est un peu déroutant, mais son rôle sur le modèle de réactivité de React est assez important. Avec lui, nous pouvons résoudre les promesses lors du rendu d'un composant. La dérivation manquante.

Avant cela, la seule façon d'appeler une récupération lors du rendu d'un composant était d'utiliser useEffect, d'appeler la promesse et sur la clause then, de définir un état avec la valeur qui vient en réponse. Cela a fonctionné, en quelque sorte, mais nous avons eu tous les problèmes liés à l'utilisation d'un effet pour le faire.
La primitive d'utilisation nous permet de résoudre la promesse lors du rendu du composant, ce qui nous permet d'utiliser l'état et les accessoires pour créer la promesse, puis de résoudre ces promesses et de l'utiliser sur nos fonctions et JSX.

const useCountTotal = (count: number) => {
  const countTotalPromise = useMemo(() => genericPromise(count), [count]);


  const result = use(countTotalPromise);


  return result;
}


function AsyncDerivation({count}: { count: number}) {
  const result = useCountTotal(count);

  return (
    <div>Total count is: {result}</div>
  )
}

Au moment où j'écris ceci, nous n'avons pas encore la version finale de React 19. Il y a quelques mises en garde et la primitive évoluera probablement dans le futur pour fonctionner dans plus d'endroits.

Une particularité de l'utilisation primitive est qu'elle doit être utilisée avec Suspense et il y a une très bonne raison à cela.

Composants Async et React

L'idée conceptuelle de wait est sympa, mais elle présente un défaut lorsqu'elle est associée aux composants React. Vous ne pouvez pas simplement utiliser wait pendant le rendu. React appelle un composant pour obtenir la réponse JSX et l'utilise sur son flux pour restituer une interface utilisateur.

Si nous pouvions simplement tout arrêter dans une attente, React ne pourrait pas accéder aux enfants de ce composant et continuer son travail jusqu'à la fin de l'arborescence. Nous arrêterions le flux de rendu et empêcherions l’interface utilisateur d’être mise à jour et gelée.

Comment résoudre ça ?

On peut regarder les deux exemples que j'ai utilisés dans cet article. La première adopte l'approche consistant à renvoyer des indicateurs tels que le chargement, sans bloquer le flux de rendu. Lorsque la promesse est résolue, elle lance un nouveau rendu, mettant à jour les indicateurs, le chargement devient faux et les données reçoivent les données de réponse.

L'approche d'utilisation est différente. Elle se comporte vraiment comme la primitive d'attente, donc le flux de rendu du composant est arrêté là, jusqu'à la résolution.

Attends, attends, attends, tu as dit que c'était un problème, non ?

Et voilà, Suspense pour le salut. Lorsque vous utilisez la primitive d'utilisation, elle sera enveloppée dans un composant Suspense, le flux de rendu cessera d'attendre la résolution d'utilisation et l'utilisateur obtiendra le rendu de secours sur l'interface utilisateur (normalement un spinner ou un squelette de chargement, quelque chose pour indiquer que nous y chargent des trucs).

Lorsque la promesse d'utilisation est résolue, nous poursuivons le rendu et mettons à jour l'interface utilisateur en conséquence. Pas besoin d'utiliser useEffect.

Conclusion

La primitive use sera très utile pour les auteurs de bibliothèques souhaitant utiliser Suspense et travailler avec un comportement asynchrone. Pour le développeur d’applications, cela corrige un cas supplémentaire dans le modèle de réactivité de base, qui conviendra parfaitement aux cas d’utilisation simples. Comme il tient ses promesses, il ne se limite pas uniquement aux requêtes http, mais à tous les cas asynchrones et à l'utilisation d'API externes, ce qui peut ajouter plus de ressources à l'écosystème.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!