Redux n'est pas le mauvais outil. C'est juste souvent l'outil le plus lourd.
Dans de nombreuses applications React modernes, les plus grands besoins en état global ne concernent pas les flux de travail de domaine basés sur les événements. Ce sont des choses comme :
- état des modal
- état de la barre latérale
- filtres actifs
- préférences utilisateur
Pour ce type d'état, Zustand semble souvent plus propre car il vous donne un petit magasin externe sans la cérémonie des réducteurs, actions et fournisseurs partout.
Une Forme Typique de Zustand
import { create } from "zustand";
type UiStore = {
isSidebarOpen: boolean;
toggleSidebar: () => void;
};
export const useUiStore = create<UiStore>((set) => ({
isSidebarOpen: false,
toggleSidebar: () =>
set((state) => ({ isSidebarOpen: !state.isSidebarOpen })),
}));
Les consommateurs peuvent s'abonner uniquement à la tranche dont ils ont besoin :
const isSidebarOpen = useUiStore((state) => state.isSidebarOpen);
Cela est généralement suffisant pour beaucoup d'interfaces produit.
La Réelle Division Architecturale
Les équipes rencontrent des problèmes lorsqu'elles stockent trop d'état serveur dans le même magasin global. Les résultats d'API mis en cache, le comportement de rechargement, les mises à jour optimistes, l'invalidation et la synchronisation en arrière-plan sont généralement mieux gérés par des outils d'état serveur comme React Query.
Cela signifie que la division moderne ressemble souvent à :
- Zustand pour l'état UI
- React Query pour l'état serveur
C'est plus utile que d'essayer de choisir un magasin pour tout posséder.
Compromis
Redux a encore du sens lorsque :
- les transitions d'état nécessitent une structure stricte
- l'équipe souhaite une modélisation d'état explicite basée sur des événements
- les outils autour des réducteurs et des middleware sont précieux
Zustand fait sens lorsque la simplicité et les abonnements sélectifs sont un plus plus important.
Lectures Supplémentaires