SWR ou React Query : choisir le bon outil

SWR pèse environ 7 ko après compression gzip. React Query v5 pèse environ 13 ko après compression gzip. Cette différence de taille reflète les fonctionnalités supplémentaires de React Query : préchargement des requêtes, annulation des requêtes, cycle de vie des requêtes plus détaillé et DevTools intégrés.

Pour les applications sensibles à la taille ou les schémas simples de récupération et d'affichage, l'empreinte réduite de SWR constitue un avantage important.

SWR possède une API plus simple et plus minimaliste. Si votre besoin principal consiste à récupérer des données et à les afficher avec une revalidation automatique, SWR le permet élégamment avec très peu de code répétitif.

Développé par Vercel, SWR s'intègre particulièrement bien à Next.js, notamment pour combiner le préchargement effectué par getServerSideProps ou getStaticProps avec la revalidation côté client via des données de repli.

Transmettez les données préchargées à SWR via l'option fallback de SWRConfig ou l'option fallbackData de useSWR. SWR les utilise comme valeur initiale du cache, ce qui évite le clignotement du premier chargement tout en permettant une revalidation en arrière-plan.

Ce schéma constitue l'approche recommandée pour récupérer les données dans les applications Next.js utilisant Pages Router avec Vercel.

React Query offre un contrôle plus précis du cycle de vie des requêtes : staleTime, gcTime (ramasse-miettes), refetchOnWindowFocus, le nombre de tentatives et le délai entre les tentatives sont tous configurables séparément. Son système de mutation, avec les fonctions de rappel onSuccess, onError et onSettled, est très expressif.

React Query prend également en charge l'annulation des requêtes via AbortSignal, ce qui est utile pour les interfaces de recherche au fil de la saisie.

Le useInfiniteQuery de React Query, associé à getNextPageParam, est conçu spécifiquement pour le défilement infini et les schémas de chargement progressif. Il gère la logique du curseur de pagination et fournit un objet pages plat ou structuré.

SWR propose useSWRInfinite, qui couvre un besoin similaire avec une API légèrement plus bas niveau nécessitant davantage d'assemblage manuel des pages.

React Query permet de précharger des requêtes au survol ou lors d'un changement de route avec queryClient.prefetchQuery. Les données se trouvent dans le cache avant le montage du composant, ce qui permet un affichage instantané.

SWR ne possède pas d'API de préchargement intégrée au-delà des données de repli SSR. Pour le préchargement au survol, React Query constitue le meilleur choix.

React Query v5 a simplifié l'API en faisant renvoyer isPending par useQuery à la place de isLoading, en harmonisant les schémas de mise à jour optimiste et en améliorant l'inférence TypeScript. L'API de la v5 est plus claire et plus cohérente que celle des versions précédentes.

Si vous évaluez React Query, ciblez directement la v5 plutôt que d'apprendre la v4 avant de migrer.

SWR partage globalement les entrées du cache entre les composants selon leur clé, sans configuration de fournisseur autre que SWRConfig pour les valeurs par défaut. React Query nécessite QueryClientProvider avec une instance de QueryClient.

Pour le prototypage rapide ou les applications simples, le cache global de SWR, sans configuration, est plus rapide à mettre en place. Le client explicite de React Query convient mieux aux grandes applications ayant des exigences complexes en matière de mise en cache.

Choisissez SWR lorsque votre application repose principalement sur Next.js, que les schémas de récupération, d'affichage et de revalidation sont simples, que vous souhaitez une taille de paquet minimale ou que votre équipe privilégie la simplicité de l'API aux fonctionnalités avancées.

SWR est également un excellent choix lorsque vous ajoutez progressivement une bibliothèque de récupération de données à une base de code existante, sans migration majeure.

Choisissez React Query lorsque vous avez besoin d'une gestion complexe de l'état côté serveur : défilement infini, préchargement des requêtes, stratégies de récupération en arrière-plan, dépendances entre requêtes en plusieurs étapes ou contrôle précis du TTL du cache.

React Query dispose également d'un écosystème plus actif d'intergiciels et de DevTools, et son queryClient peut être testé plus facilement de manière isolée.

Certaines équipes utilisent les deux : SWR pour les récupérations simples d'une seule ressource dans les composants feuilles, et React Query pour les pages complexes comportant plusieurs requêtes et du préchargement. Cette combinaison est peu courante, mais valable si l'équipe maîtrise les deux API.

Plus généralement, les équipes en choisissent une et l'appliquent de manière cohérente dans toute l'application, afin d'éviter les changements de contexte et la surcharge liée à la double dépendance.

Comment les tailles des paquets de SWR et de React Query se comparent-elles approximativement ?

SWR (~7 ko) est plus simple, s'intègre nativement à Next.js et couvre la plupart des schémas de récupération et d'affichage avec un minimum de code. React Query (~13 ko) offre davantage de fonctionnalités : requêtes infinies, préchargement, fonctions de rappel précises pour le cycle de vie et annulation des requêtes.

Choisissez SWR pour sa simplicité et pour les projets Next.js ; choisissez React Query pour les besoins complexes liés à l'état côté serveur. Les deux bibliothèques prennent en charge TypeScript, Suspense, SSR et les schémas hors ligne.