Zustand et Tanstack Query sont mort à cause de Next

Zustand et Tanstack Query sont mort à cause de Next

Depuis que React Server Components (RSC) est devenu un standard avec Next.js, ma manière de structurer mes projets a radicalement changé. 🚀

Pour rappel les 2 librairies sont des “state manager”

• Tanstack Query : Server State
• Zustand : App State (UI)

Mon raisonnement :

1️⃣ Adieu API inutiles :

Avec les Server Components, je peux effectuer directement des appels à ma base de données ou à mes services externes depuis le serveur. Plus besoin de bibliothèques comme TanStack Query pour gérer le “server state” côté client.

2️⃣ Réduction maximale du code client :

Je réduis au maximum l'utilisation des composants client, en les limitant autant que possible et en les plaçant le plus bas possible dans l’arbre de composants React.

Moins de composants client = moins d’état à gérer.

Pour les rares cas où du code client est nécessaire (interactions locales, animations, etc.), le Context API de React suffit amplement.

Pourquoi ajouter des outils comme Zustand, alors que les fonctionnalités natives répondent déjà aux besoins ?

3️⃣ Simplification des bundles :

Moins de bibliothèques côté client = des performances améliorées (taille du bundle) et un code plus simple à maintenir.

Ne développe pas des applications Next.js avec une approche de "développeur front-end React" !

Dans Next Mastery on parle de ces nouvelles approches de développement…

Pour nuancer mon post :

3 exemples de projets ne nécessitant ni Zustand ni Tanstack Query :

1️⃣ Blog ou site de contenu statique/dynamique

• Les données sont chargées côté serveur avec React Server Components (ex. : articles, catégories).
• Pourquoi ? Aucun état complexe côté client, tout est récupéré et rendu via RSC.

2️⃣ Tableau de bord analytique simple

• Les données agrégées (revenus, utilisateurs actifs) sont chargées directement via Server Components. Les interactions client sont minimes.
• Pourquoi ? Les données sont pré-rendues et mises à jour côté serveur, sans gestion d'état client.

3️⃣ Landing page avec formulaire

• Un site simple avec un formulaire (ex. : inscription, contact). Les validations se font côté serveur et avec des bibliothèques légères comme React Hook Form.
• Pourquoi ? Aucun besoin de gestion d'état persistante ou de synchronisation avec un serveur en continu.

3 exemples de projets nécessitant Zustand ou Tanstack Query :

1️⃣ Applications nécessitant des interactions utilisateur complexes

• Par exemple, une application de gestion de tâches avec drag & drop, où les utilisateurs peuvent réorganiser des tâches ou modifier des états localement avant de les synchroniser avec le serveur.
• Pourquoi Zustand ? Pour gérer localement l'état des tâches (position, statut, etc.).
• Pourquoi Tanstack Query ? Pour synchroniser les modifications avec le serveur une fois validées.

2️⃣ Application utilisant de nombreuses APIs externes

• Une application qui dépend de multiples APIs tierces pour afficher des données, comme des informations sur les produits, des avis clients, ou des taux de change.
• Pourquoi Zustand ? Pour gérer les états temporaires ou locaux entre les différentes sections de l'application (chargement, préférences utilisateur, états intermédiaires).
• Pourquoi Tanstack Query ? Pour gérer le caching, la synchronisation, et les actualisations automatiques des données provenant de plusieurs APIs externes, réduisant les appels inutiles et améliorant les performances.

3️⃣ Application de chat en temps réel

• Les messages sont récupérés depuis le serveur (WebSocket ou polling) mais nécessitent aussi une gestion locale pour les brouillons, les conversations ouvertes, etc.
• Pourquoi Zustand ? Pour stocker localement l'état des conversations, messages non envoyés, etc.
• Pourquoi Tanstack Query ? Pour synchroniser les messages et maintenir la cohérence avec le serveur.

"Et toi, comment utilises-tu Zustand ou Tanstack Query dans tes projets ?"

"Penses-tu que les Server Components vont changer la donne ?"