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