React Context vs Zustand : quand utiliser l'un ou l'autre
Les développeurs commettent souvent une erreur avec l'état (state) de React. Ils utilisent mal le Context, puis rejettent la faute sur le Context pour les problèmes de performance.
Le problème vient généralement d'un seul et unique objet de contexte volumineux. Lorsqu'une valeur dans cet objet change, chaque composant utilisant ce contexte est re-rendu. Même si un composant n'a besoin que d'une petite partie des données, il réagit tout de même à chaque modification de l'objet.
Si vos notifications se mettent à jour toutes les 30 secondes, votre Navbar est re-rendue même si elle n'a besoin que du nom de l'utilisateur. Cela nuit gravement aux performances.
Vous pouvez corriger cela sans bibliothèque. Divisez vos contextes en fonction de leur fréquence de modification.
Au lieu d'un seul gros contexte, utilisez-en plusieurs : • UserContext pour les données utilisateur • UIContext pour l'état de la barre latérale • NotificationContext pour les alertes
Désormais, votre Navbar n'est re-rendue que lorsque les données utilisateur changent. Cette simple séparation résout la plupart des problèmes de performance.
Utilisez React Context pour les valeurs stables : • Thèmes • Statut d'authentification • Paramètres de langue
Le Context fonctionne également très bien avec les Server Components. Zustand ne fonctionne que du côté client.
Utilisez Zustand lorsque vous avez besoin d'abonnements sélectifs. Zustand permet aux composants de s'abonner à des segments (slices) spécifiques de l'état. Si une partie de votre store change, seuls les composants qui surveillent cette partie spécifique sont re-rendus.
Suivez cette logique pour vos nouveaux états :
Utilisez React Context si : • Les données sont stables (thème, authentification, langue). • Vous avez besoin qu'il fonctionne avec le SSR ou les Server Components. • Vous voulez éviter le prop drilling en divisant les contextes.
Utilisez Zustand si : • Les données changent fréquemment. • Les composants doivent surveiller des segments (slices) spécifiques de l'état. • Votre logique est complexe.
Attendez. N'utilisez aucun des deux pour les données d'API. Si vous récupérez des données depuis un serveur, utilisez TanStack Query. Context et Zustand ne gèrent ni la mise en cache ni le rafraîchissement en arrière-plan (background refetching).
Résumé : • Un seul gros objet de contexte provoque des re-rendus. Divisez-le. • Utiliser Zustand pour des valeurs stables est excessif. • Utiliser le Context pour des changements fréquents provoque des ralentissements. • Utiliser Zustand pour l'état du serveur est un mauvais choix d'outil.