Zustand macht mehr Sinn, wenn Ihr globaler Zustand überwiegend UI-Zustand ist_

Redux ist nicht das falsche Werkzeug. Es ist nur sehr oft das schwerere Werkzeug.

In vielen modernen React-Apps sind die größten globalen Zustandsbedürfnisse keine ereignisgesteuerten Domänen-Workflows. Es handelt sich um Dinge wie:

• modaler Zustand
• Seitenleisten-Zustand
• aktive Filter
• Benutzereinstellungen

Für diese Art von Zustand fühlt sich Zustand oft sauberer an, weil es Ihnen einen kleinen externen Store ohne die Umstände von Reducern, Aktionen und Provider überall bietet.

Eine typische Zustand-Form

import { create } from "zustand";
 
type UiStore = {
  isSidebarOpen: boolean;
  toggleSidebar: () => void;
};
 
export const useUiStore = create<UiStore>((set) => ({
  isSidebarOpen: false,
  toggleSidebar: () =>
    set((state) => ({ isSidebarOpen: !state.isSidebarOpen })),
}));

Verbraucher können sich nur für den Teil anmelden, den sie benötigen:

const isSidebarOpen = useUiStore((state) => state.isSidebarOpen);

Das ist in der Regel genug für viele Produkt-UIs.

Die echte architektonische Trennung

Teams geraten in Schwierigkeiten, wenn sie zu viel Serverzustand im selben globalen Store speichern. Gecachete API-Ergebnisse, Neuladeverhalten, optimistische Updates, Ungültigmachung und Hintergrundsynchronisierung werden in der Regel besser durch Serverzustands-Tools wie React Query gehandhabt.

Das bedeutet, dass die moderne Trennung oft so aussieht:

• Zustand für UI-Zustände
• React Query für Serverzustände

Das ist nützlicher, als zu versuchen, einen Store auszuwählen, der alles verwaltet.

Abwägungen

Redux macht nach wie vor Sinn, wenn:

• Zustandsübergänge eine strenge Struktur benötigen
• das Team explizites, ereignisgesteuertes Zustandsmodellieren wünscht
• Werkzeuge rund um Reducer und Middleware von Wert sind

Zustand macht Sinn, wenn Einfachheit und selektive Abonnements der größere Gewinn sind.

Weiterführende Literatur

• Zustand-Dokumentation
• Redux Toolkit
• TanStack Query