Comment nous avons intégré SWR dans un projet et pourquoi nous l’avons adoré

Pourquoi SWR ?

Récemment, chez SDH, nous avons eu l’occasion de développer un projet avec React, épaulé par Redux/Toolkit. Le problème, c’est que, même si les données étaient conservées et récupérées dans le store, il n’y avait aucun mécanisme de mise en cache dans l’app.  Et garder des dizaines de réponses dans le state, ce n’est pas exactement ce que j’appelle une bonne idée. Quoi qu’il en soit, on s’est vite mis à se perdre parmi tous ces slices du state, malgré l’usage de Toolkit.  

En plus, ça n’avait aucun impact côté back-end à ce stade. Avec ces blocs de données gros comme des icebergs qui dérivaient partout, certaines requêtes mettaient une éternité à se résoudre.  Et comme l’UI de l’application se résumait à de longues listes d’éléments avec peu d’opérations CRUD, il est vite apparu qu’une forme de cache nous serait bien utile. Nous avons donc opté pour SWR — une bibliothèque conçue par les développeurs de Vercel (également à l’origine de Next.js).

Qu’est-ce que SWR ?

OK, vous aimez lire des définitions ? J’espère que non, car celle-ci va être l’une des plus courtes que vous ayez jamais lues. « SWR est une bibliothèque de React Hooks pour la récupération de données distantes ». Voilà. Simple ? Oui, mais je vais maintenant vous montrer que SWR est aussi très puissant. Et au cas où vous vous poseriez la question, SWR signifie stale-while-revalidate. Ce qui explique déjà comment ça marche. SWR renvoie les données depuis le cache (stale), envoie une requête pour obtenir des données à jour (revalidate), puis renvoie les nouvelles données.  Comme je le disais, simple. 

Pourquoi nous avons adoré SWR

Il est facile de voir en quoi l’usage de SWR élimine les problèmes décrits au début de cet article. Grâce à SWR, nous avons :

• Fait tourner l’UI parfaitement (après les premières requêtes) grâce à la mise en cache 
• Supprimé presque tous les slices qui stockaient les données de l’API et la logique associée
• Simplifié le flux de revalidation des données après des opérations CRUD sur les collections
• Accéléré le développement de nouvelles fonctionnalités dépendantes de l’API

Comment l’avons-nous implémentée pour obtenir de tels résultats ? 

Comment fonctionne SWR

Après un court temps d’adaptation, SWR s’est révélé plutôt simple et très agréable à utiliser. Envie de faire une requête API avec SWR ? Voilà :

La seule subtilité, c’est le fetcher. C’est simplement votre fonction maison pour récupérer les données. L’application sur laquelle nous travaillions avait déjà axios configuré (interceptors, headers, base URL, etc.), donc nous avons simplement enveloppé notre instance axios comme ceci pour obtenir notre fetcher personnalisé :

Du coup, le hook complet peut être aussi simple que ceci (on passe la gestion des erreurs dans cet exemple) :

Et… c’est tout ! Nous avons créé un hook pour récupérer des données d’API en profitant de tous les avantages de SWR. À chaque appel, il renverra d’abord les données précédemment récupérées (si elles existent), puis revalidera et renverra ensuite la nouvelle collection.

SWR, par défaut, propose une poignée de paramètres préconfigurés (ils sont tous listés ici), qui rendent son utilisation très simple. Une option favorite à mentionner est dedupingInterval.

Scénario typique : on récupère des données dans un composant, on continue à le développer, les composants enfants se multiplient, et voilà qu’un enfant au 4e niveau a besoin des mêmes données. Comment les lui transmettre sans trop d’efforts et sans répéter les requêtes ? Pas de panique : réutilisez simplement le hook SWR… L’intervalle de déduplication empêchera d’exécuter la requête à nouveau pendant une durée spécifiée (2 secondes par défaut). Ça marche.

« Mais si j’appelle l’endpoint et qu’il renvoie les mêmes données qu’avant, mon composant va quand même se re-render ». Non : SWR implémente une comparaison profonde, donc un nouveau rendu n’est déclenché que lorsque les données ont réellement changé. Et la fonction de comparaison peut, bien sûr, être personnalisée. 

Mutation de données

Vous pourriez dire que faire des GET, c’est facile — mais qu’en est-il de la partie mutation ? C’est sûrement plus compliqué. Eh bien, pas vraiment : les mutations n’ont pas à être un cauchemar, et j’ai été surpris de voir à quel point il est facile de muter des données avec SWR (ayant déjà eu quelques aventures avec Apollo). Voici un exemple réel :

Dans cet exemple, mutate est une fonction importée depuis SWR et /users est la clé que nous lui avons donnée dans le hook useUsers (il ne faut pas forcément utiliser l’URL de l’endpoint — vous pouvez passer la clé et l’URL séparément).

Si vous souhaitez mettre en cache et mettre à jour une entité (objet) unique récupérée depuis une collection plus large, muter-la simplement par sa clé comme ceci :

Ça paraît trop simple ? Ça l’est. Essayez, et vous pourriez gagner un temps précieux à écrire moins de logique Redux et à déboguer vos appels d’API.

Intégrations SWR

Comme vous le voyez, implémenter SWR est simple ; avec quelques raffinements, il ne faut pas grand-chose pour faire évoluer les exemples ci-dessus vers des niveaux plus abstraits. Évidemment, SWR ne se limite pas à cela et propose un grand nombre d’options et d’intégrations :

intégration GraphQL

gestion des erreurs avec options de retry

revalidation automatique

prise en charge de la pagination (y compris le chargement infini)

préfetching des données

et bien plus encore (documentation)

Nous avons trouvé SWR super agréable à utiliser et nous envisagerons clairement de l’employer sur de futurs projets. Si vous souhaitez en savoir plus sur cette excellente bibliothèque, consultez leur site officiel avec documentation, configurations et exemples ici.

Bon code !