State Management in React: Context, Zustand oder Redux?

Kurz gefasst: Trennen Sie zuerst Serverdaten von Client-Zustand. Daten aus der API gehören in eine Bibliothek wie TanStack Query, die Caching und Aktualisierung übernimmt. Für den verbleibenden Client-Zustand reicht oft lokaler State plus React Context für selten wechselnde Werte wie Theme oder angemeldeten Nutzer. Zustand ist die schlanke Wahl für gemeinsam genutzten, häufig wechselnden Zustand, Redux Toolkit lohnt sich bei großen Anwendungen mit komplexer Logik und vielen Entwicklern.

Erst die richtige Frage stellen

In vielen React-Projekten landet alles in einem globalen Store: Benutzerdaten, Produktlisten aus der API, ob ein Modal offen ist, der Inhalt eines Formulars. Das macht den Store groß, schwer testbar und langsam. Die meisten Probleme mit State Management entstehen, weil unterschiedliche Arten von Zustand gleich behandelt werden.

Es hilft, vier Arten zu unterscheiden:

• Serverzustand: Daten, die eigentlich auf dem Server liegen und nur zwischengespeichert werden, etwa Bestellungen oder Kundenlisten.
• Globaler Client-Zustand: Daten, die viele Komponenten brauchen, aber nur im Browser existieren, etwa ein Warenkorb vor dem Absenden oder UI-Einstellungen.
• Lokaler Zustand: Was nur eine Komponente betrifft, etwa ob ein Dropdown offen ist.
• URL-Zustand: Filter, Sortierung und Seitenzahl, die in die Adresszeile gehören, damit Links teilbar sind.

Serverdaten: TanStack Query statt Store

Für Daten aus einer API ist eine spezialisierte Bibliothek wie TanStack Query (früher React Query) oder SWR fast immer die bessere Wahl. Sie übernimmt Caching, Ladezustände, Fehlerbehandlung, erneutes Laden im Hintergrund und das Invalidieren nach Änderungen. Wer das selbst in Redux oder Zustand nachbaut, schreibt viel Code für ein gelöstes Problem.

In Next.js mit Server-Komponenten verschiebt sich ein Teil davon ohnehin auf den Server: Daten werden beim Rendern geladen und müssen gar nicht erst in einen Client-Store. Mehr dazu in unserem Artikel zu Next.js 15.

Nach dieser Trennung bleibt oft erstaunlich wenig globaler Client-Zustand übrig.

React Context: für seltene Änderungen

Context ist in React eingebaut und braucht keine Bibliothek. Es eignet sich gut für Werte, die viele Komponenten lesen, die sich aber selten ändern: Theme, Sprache, angemeldeter Nutzer, Feature-Flags.

Der Haken: Ändert sich der Wert eines Context, rendern alle Komponenten neu, die ihn verwenden. Für häufig wechselnde Daten, etwa Eingaben in einem großen Formular oder Echtzeit-Updates, führt das schnell zu spürbaren Leistungsproblemen. Man kann das mit mehreren getrennten Contexts und Memoisierung abmildern, aber ab einem gewissen Punkt ist eine dedizierte Bibliothek einfacher.

Zustand: schlank und pragmatisch

Zustand ist eine kleine Bibliothek, die einen globalen Store mit sehr wenig Code ermöglicht. Ein Store ist ein Hook, Komponenten lesen über Selektoren nur die Teile, die sie brauchen, und rendern nur neu, wenn sich genau diese Teile ändern.

const useCart = create<CartState>((set) => ({
  items: [],
  add: (item) => set((s) => ({ items: [...s.items, item] })),
}));

const count = useCart((s) => s.items.length);

Es gibt keinen Provider, keine Actions und Reducer im klassischen Sinn und wenig Boilerplate. Middleware für Persistenz in localStorage oder die Redux DevTools ist verfügbar. Für die meisten kleinen und mittleren Anwendungen ist Zustand der Punkt, an dem Aufwand und Nutzen am besten zusammenpassen.

Redux Toolkit: Struktur für große Teams

Redux hatte lange den Ruf, viel Boilerplate zu erzeugen. Redux Toolkit, heute der offizielle Weg, Redux zu schreiben, hat das deutlich reduziert. Die Stärke von Redux liegt in seiner Struktur: Jede Änderung ist eine benannte Action, der Zustand ändert sich nur über Reducer, und die DevTools zeigen jede Änderung mit Zeitreise-Debugging.

Das zahlt sich in großen Anwendungen mit komplexer Geschäftslogik und vielen Entwicklern aus, weil alle nach denselben Regeln arbeiten. Mit RTK Query bringt Redux Toolkit zudem eine eigene Lösung für Serverdaten mit. Für ein kleines Team und eine überschaubare Anwendung ist diese Struktur dagegen oft mehr, als gebraucht wird.

Unabhängig von der Bibliothek gilt: Logik im Store sollte unabhängig von Komponenten testbar sein. Wie man das aufbaut, zeigt unser Beitrag zu Teststrategien für React-Anwendungen, und saubere Typisierung mit TypeScript beschreibt der Artikel zu Clean Code in TypeScript.

Häufige Fragen (FAQ)

Brauche ich überhaupt eine State-Management-Bibliothek?

Oft nicht. Wenn Serverdaten über TanStack Query laufen und Filter in der URL stehen, reichen für viele Anwendungen lokaler State und ein oder zwei Contexts. Eine Bibliothek lohnt sich, sobald viele Komponenten denselben, häufig wechselnden Zustand teilen.

Ist Redux veraltet?

Nein. Redux Toolkit wird aktiv gepflegt und ist in vielen großen Anwendungen im Einsatz. Für neue, kleinere Projekte wählen Teams heute allerdings häufiger leichtere Lösungen wie Zustand.

Kann ich Zustand und TanStack Query kombinieren?

Ja, das ist eine sehr verbreitete Kombination. TanStack Query verwaltet alles, was vom Server kommt, Zustand den reinen Client-Zustand. Die beiden kommen sich nicht in die Quere.

Lohnt sich ein Wechsel von Redux zu Zustand?

Nur, wenn Redux im Alltag spürbar bremst. Ein schrittweiser Umstieg ist möglich, weil beide parallel laufen können. Oft bringt es mehr, zuerst Serverdaten aus dem Redux-Store in TanStack Query oder RTK Query zu verschieben.

Fazit

Die Wahl der Bibliothek ist der kleinere Teil der Entscheidung. Wer Serverdaten, URL-Zustand und echten Client-Zustand sauber trennt, braucht weniger globalen State, und die passende Bibliothek ergibt sich dann meist aus Teamgröße und Komplexität.

Wenn Sie eine React-Anwendung planen oder eine bestehende aufräumen möchten, sprechen Sie mit uns über Webentwicklung.