Concepts fondamentaux de SWR : obsolète puis revalidé

SWR signifie « servir les données obsolètes pendant leur revalidation », une stratégie de cache HTTP définie dans la RFC 5861. Cette stratégie consiste à servir immédiatement les données obsolètes (mises en cache) à l’utilisateur, puis à les revalider en arrière-plan et à mettre à jour l’interface lorsque les données fraîches arrivent.

Cette approche privilégie les performances perçues : les utilisateurs voient les données instantanément au lieu d’attendre un aller-retour réseau.

Avec les modèles de chargement traditionnels, les utilisateurs voient un indicateur de chargement à chaque navigation. Avec SWR, ils voient immédiatement les dernières données connues et l’interface se met à jour silencieusement en arrière-plan si les données ont changé.

Les applications semblent ainsi nettement plus rapides et la perturbation cognitive liée aux états de chargement est réduite.

SWR revalide automatiquement les données lorsque : la fenêtre du navigateur reprend le focus (l’utilisateur change d’onglet puis revient), la connexion réseau est rétablie après une période hors ligne, mutate() est appelée explicitement ou le minuteur refreshInterval configurable se déclenche.

Ces déclencheurs automatiques gardent les données à jour sans que le développeur ait à gérer manuellement la logique de nouvelle récupération.

Une clé SWR peut se trouver dans plusieurs états : chargement (aucune donnée en cache, première récupération en cours), revalidation (données en cache disponibles, actualisation en arrière-plan en cours), erreur (requête échouée) ou succès (données fraîches disponibles).

Comprendre ces états vous aide à créer des squelettes de chargement et des interfaces d’erreur précis.

SWR gère un cache global en mémoire indexé par la clé de requête (généralement une chaîne d’URL). Tout composant qui demande la même clé obtient la même valeur mise en cache et participe au même cycle de revalidation.

Cette déduplication automatique signifie que 10 composants peuvent chacun appeler useSWR avec la même clé et qu’une seule requête réseau est effectuée.

SWR sépare la logique de gestion du cache de la récupération effective des données. Vous fournissez une fonction de récupération : une fonction asynchrone qui accepte la clé et renvoie les données.

La fonction de récupération est interchangeable : utilisez fetch, axios, graphql-request ou n’importe quelle source de données asynchrone. SWR gère la mise en cache et la revalidation quelle que soit la manière dont fonctionne la fonction de récupération.

Entourez votre application de SWRConfig avec une propriété value contenant une fonction de récupération : value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}. Chaque appel à useSWR qui omet un argument fetcher utilise cette valeur par défaut globale.

Cela centralise la configuration de l’interface de programmation (URL de base, en-têtes d’authentification) en un seul endroit, sans la répéter dans chaque appel de hook.

Le modèle classique utilise useEffect + useState pour gérer manuellement les états de chargement, de données et d’erreur. SWR remplace tout cela par un seul appel qui gère automatiquement la mise en cache, la déduplication, l’actualisation en arrière-plan et la nouvelle tentative en cas d’erreur.

La réduction de code est importante : un composant typique de récupération de données passe de plus de 20 lignes à 3 lignes.

La clé identifie une requête de manière unique. Utilisez la chaîne d’URL dans les cas simples. Pour les requêtes paramétrées, utilisez une clé sous forme de tableau : [url, params], où params est un objet stable ou une chaîne. Null désactive la requête.

Une bonne conception de clé garantit que les requêtes liées partagent les mêmes entrées de cache et que les requêtes indépendantes n’entrent pas en collision.

SWR gère intelligemment la revalidation : dedupingInterval (2 secondes par défaut) empêche plusieurs revalidations de se déclencher simultanément si de nombreux composants sont montés en même temps. Une seule requête est envoyée par clé pendant la fenêtre de déduplication.

Cela évite les problèmes de ruée massive de requêtes fréquents dans les grandes arborescences de composants, où de nombreux composants récupèrent les mêmes données.

SWR est développé par Vercel, l’entreprise à l’origine de Next.js, et l’intégration est transparente. getServerSideProps ou getStaticProps peuvent précharger les données, puis SWR s’hydrate côté client à partir de cette valeur préchargée.

Vous obtenez ainsi un HTML initial rendu côté serveur avec une revalidation automatique côté client au montage, ce qui combine le meilleur de SSR et de SWR.

Laquelle des actions suivantes correspond à NOT — autrement dit, ne déclenche pas — la revalidation de SWR par défaut ?

SWR met en œuvre la stratégie « servir les données obsolètes pendant leur revalidation » : servir immédiatement les données mises en cache, revalider en arrière-plan, puis mettre à jour l’interface lorsque les données fraîches arrivent. Il déclenche une revalidation lors du retour au premier plan, de la reconnexion, de l’appel à mutate et de l’interrogation périodique. Le cache global déduplique les requêtes entre les composants et la fonction de récupération est entièrement interchangeable.

Ce modèle simplifie considérablement le code de récupération des données tout en offrant de meilleures performances perçues.