Die Frage „React Hooks oder Redux“ ist keine Frage der Qualität, sondern des Anwendungsbereichs. Verwenden Sie React Hooks für Statusdaten innerhalb einer Komponente sowie für kleine, gemeinsam genutzte Werte wie Themes oder Gebietsschemata. Greifen Sie zu Redux, wenn mehrere unabhängige Funktionen auf dieselben Daten zugreifen, wenn mehr als fünf Entwickler am Code arbeiten oder wenn Sie eine nachvollziehbare Historie jeder Änderung benötigen. Die meisten produktiven Anwendungen nutzen letztlich beides auf unterschiedlichen Ebenen.
Stellen Sie sich den Status wie Wasser in einem Gebäude vor. Hooks sind die Wasserhähne in den einzelnen Räumen, direkt dort, wo das Wasser gebraucht wird. Redux ist die Hauptleitung, das Druckventil und der Zähler, der Ihnen genau anzeigt, wer um 3 Uhr morgens die Badewanne hat volllaufen lassen.
Dieselbe Substanz. Sehr unterschiedliche Aufgaben. Das ist der ganze Kern der Argumentation, und alles Folgende ist die Herleitung.
Die Architektur des State Managements ist eine der wenigen Entscheidungen im Frontend, deren Auswirkungen sich mit der Zeit summieren. Wählen Sie zu wenig Struktur, zahlen Sie mit längeren Einarbeitungszeiten und Fehlern, die niemand reproduzieren kann. Wählen Sie zu viel, zahlen Sie mit Boilerplate-Code, den niemand braucht.
Das Interessante daran ist die Asymmetrie. Over-Engineering kostet Sie ein paar verschwendete Wochen, die Sie sofort spüren. Under-Engineering kostet Sie Quartale schleichenden Geschwindigkeitsverlusts, den Sie erst bemerken, wenn Ihr Team bereits so groß ist, dass ein Rewrite nicht mehr kostengünstig möglich ist.
Es handelt sich also um eine CTO-Entscheidung, die als Entwicklerpräferenz getarnt ist. Wir haben jeden technischen Abschnitt unten mit dem damit verbundenen Lieferrisiko versehen, denn genau das ist der Punkt, der sich in Ihrer Roadmap niederschlägt.
React Hooks ermöglichen die Verwaltung von State und Lifecycle innerhalb von Funktionskomponenten, ganz ohne Klassen. Sie wurden mit React 16.8 eingeführt, um die Komplexität von Komponenten durch die Wiederverwendbarkeit von Logik zu reduzieren.
Der eigentliche Vorteil liegt in den Custom Hooks. Lagern Sie Verhalten, das an mehreren Stellen benötigt wird, einfach aus und vermeiden Sie so redundanten Code.
// useDebouncedValue.js
import { useEffect, useState } from 'react';
export function useDebouncedValue(value, delay = 300) {
const [debounced, setDebounced] = useState(value);
useEffect(() => {
const timer = setTimeout(() => setDebounced(value), delay);
return () => clearTimeout(timer);
}, [value, delay]);
return debounced;
}
Der Haken: Hooks geben keinerlei Konventionen vor. Wo gemeinsam genutzter State liegt, ist eine individuelle Entscheidung jedes Entwicklers, die von keinem Tooling dokumentiert wird. Bei zwei Entwicklern ist das kein Problem. Bei zehn wird es teuer.
Redux ist eine Bibliothek zur Verwaltung des globalen Anwendungszustands. Ein Store, eine strukturierte Methode zu dessen Änderung und Werkzeuge, die jede Änderung in Echtzeit überwachen.
Die offizielle Dokumentation nennt drei Prinzipien:
Redux bietet zudem eigene Hooks, useSelector und useDispatch, wodurch Funktionskomponenten ohne klassenbasierte Anbindung auf den Store zugreifen können. (Dies ist die React-Redux-Bindung, die Sie tatsächlich benötigen: Mehr dazu finden Sie in den FAQ.)
Das bringt Ihnen der Aufwand:
Der Preis: Einrichtungszeit, Boilerplate-Code und eine Lernkurve für Neulinge. Redux Toolkit reduziert all dies erheblich und ist heute der offiziell empfohlene Weg, um mit Redux zu arbeiten.
Redux ist eine Bibliothek zur Verwaltung des globalen Anwendungszustands. Sie bietet uns Entwicklern verschiedene Werkzeuge, um den Status der Anwendung im Blick zu behalten und diesen zu verändern, indem wir dem Benutzer die Möglichkeit geben, Aktionenauszulösen.
Reduxlässt sich, wie in der Dokumentation beschrieben, auf drei Grundprinzipien zurückführen:
Redux hat sogar die Bibliothek mit seinen Custom Hooksaktualisiert. Diese können verwendet werden, um die Komponenten zu integrieren, die den React Hooks Funktionen für den Zugriff auf Daten aus dem Store und zum Auslösen von Aktionen, ohne auf Klassenkomponenten angewiesen zu sein.
Nachdem wir nun etwas vertrauter mit Redux und React Hooks sind, schauen wir uns die Unterschiede zwischen ihnen an.
Die meisten Artikel zu diesem Thema setzen voraus, dass man die Sprache bereits beherrscht. Genau diese Annahme sorgt dafür, dass das Thema undurchsichtig bleibt. Hier ist also das Vokabular in einfachen Worten.
State ist jede Art von Daten, die sich im Laufe der Zeit ändert und beeinflusst, was der Nutzer sieht. Eine Formulareingabe. Ein angemeldeter Benutzer. Ein Warenkorb.
Ein Reducer ist eine Funktion, die den aktuellen State und eine Aktion entgegennimmt und dann einen neuen State zurückgibt, ohne den ursprünglichen zu verändern. Er macht jede Änderung explizit und nachvollziehbar.
Eine reine Funktion (Pure Function) liefert bei gleichem Input immer das gleiche Ergebnis und verändert nichts außerhalb ihrer selbst. Keine Netzwerkaufrufe, kein Schreiben in externe Variablen. Reducer müssen rein sein, denn nur so werden Zustandsänderungen reproduzierbar und testbar.
Das Auslösen (Dispatching) einer Aktion bedeutet, eine Änderung als einfaches Objekt zu beschreiben, anstatt sie direkt auszuführen. Man verändert den Warenkorb nicht direkt. Man sendet { type: 'basket/itemAdded', payload: item } und überlässt es dem Reducer, das Ergebnis zu berechnen.
Provider und Consumer sind die beiden Hälften der Context API von React. Der Provider hält einen Wert bereit und stellt ihn allen untergeordneten Elementen im Baum zur Verfügung. Der Consumer ist jede Komponente, die diesen Wert ausliest.
Ein Selector ist eine kleine Funktion, die einen bestimmten Teil aus dem Store extrahiert, wie zum Beispiel state => state.basket.total. Ein auf Selectoren basierendes Abonnement bedeutet, dass eine Komponente nur dann neu gerendert wird, wenn sich ihr spezifischer Teil ändert.
Blast Radius bezeichnet die Menge an Komponenten, die durch eine einzelne Zustandsänderung neu gerendert werden müssen. Klein ist hierbei besser.
Ein Thunk ist eine Funktion, die anstelle einer einfachen Action ausgelöst wird, um asynchrone Aufgaben (meist API-Aufrufe) auszuführen, bevor die eigentliche Action erfolgt.
RTK Query ist die in Redux Toolkit enthaltene Schicht für das Abrufen und Zwischenspeichern von Daten. Sie verwaltet Serverdaten, sodass diese nicht manuell im Store hinterlegt werden müssen.
Context wurde für Werte entwickelt, die sich kaum ändern. Es gibt keinerlei Selektormechanismus. Wenn sich der Wert eines Providers ändert, wird daher jeder Consumer unterhalb davon neu gerendert – auch die Komponenten, die den geänderten Teil gar nicht nutzen.
Zurück zum Vergleich mit dem Leitungssystem: Context ist ein einziges großes Rohr, das das gesamte Gebäude versorgt. Dreht man im dritten Stock den Hahn auf, bebt das ganze Haus.
Bei einem Theme-Umschalter ist das egal. Bei einem Context, der den aktuellen Benutzer, einen Warenkorb, einen Live-Benachrichtigungs-Feed und ein Filter-Panel enthält, ist das jedoch ein massives Problem. Ein einziger Tastendruck im Filter-Eingabefeld löst ein Re-Rendering der Benachrichtigungsliste aus.
Teams bemerken das meist drei Monate vor dem Launch, wenn sich die Workarounds bereits gehäuft haben. Und genau diese Workarounds sind der eigentliche Kostenfaktor: einen Context in sechs aufteilen, Provider-Werte mit Memoization versehen, Consumer in React.memoeinpacken und den Komponentenbaum umstrukturieren, um den Wirkungsbereich der Änderungen zu begrenzen.
Jede dieser Maßnahmen ist für sich genommen vertretbar. Zusammen ergeben sie jedoch einen maßgeschneiderten, undokumentierten State-Manager, den genau ein einziger Entwickler versteht und dessen Wartung teurer ist als die Bibliothek, die man ursprünglich vermeiden wollte. Das ist der klassische Weg in die technische Schuldenfalle.
Redux umgeht dies durch sein Design. Dank Selektoren wird der Wirkungsbereich eines Re-Renders genau durch das definiert, was eine Komponente tatsächlich ausliest.
useReducer gehört in Komponenten mit komplexer interner Logik. Ein mehrstufiges Formular. Ein Assistent. Ein Datengitter, das Sortierung, Filterung und Paginierung unter einen Hut bringen muss. Wo useState Sie mit fünf voneinander abhängigen Settern zurücklässt, bietet Ihnen ein Reducer eine einzige, kohärente Übergangsfunktion.
const initialState = { status: 'idle', items: [], error: null };
function feedReducer(state, action) {
switch (action.type) {
case 'FETCH_STARTED':
return { ...state, status: 'loading', error: null };
case 'FETCH_SUCCEEDED':
return { status: 'ready', items: action.payload, error: null };
case 'FETCH_FAILED':
return { ...state, status: 'error', error: action.payload };
default:
return state;
}
}
const [state, dispatch] = useReducer(feedReducer, initialState);
Er nimmt den Reducer und den Anfangszustand entgegen und gibt den aktuellen Zustand sowie eine dispatch -Funktion zurück. Schreiben Sie niemals direkt in den State. Senden Sie eine Aktion, die immer als Objekt mit einem type (was passiert ist) und einem payload (die für die Änderung benötigten Daten) strukturiert ist.
Kann also useReducer Redux ersetzen? Auf Komponentenebene stellt sich die Frage eigentlich nie, da es schlicht das richtige Werkzeug ist.
Wenn Sie es jedoch über Context auf den globalen State ausweiten, erhalten Sie einen Großteil der Struktur von Redux ohne dessen Infrastruktur. Sie werden sich dabei wiederfinden, wie Sie selector-basierte Abonnements, Middleware für asynchrone Aufgaben und Debugging-Tools neu entwickeln. Von Grund auf. An einem Dienstag, mitten in einem Sprint, bei dem es eigentlich um das Produkt gehen sollte.
Dieser Neuaufbau ist nicht kostenlos und steht bei niemandem auf der Roadmap. Die Trennlinie verläuft beim Umfang, nicht bei der Komplexität.
Ehrlich gesagt ist der Vergleich bei den meisten neuen Projekten kein reines Duell mehr. Zustand hat sich als Standard-Herausforderer etabliert, und alles andere wäre eine Scheinalternative.
Zustand ist ein minimalistischer Store. Man erstellt einen State und greift über einen Hook darauf zu. Kein Provider, kaum Boilerplate und – was entscheidend ist – selektorbasierte Abonnements direkt ab Werk. Genau das bietet einfaches Context nicht.
Laut der State of React 2025 Umfragebleiben Redux und Redux Toolkit zwar die am weitesten verbreiteten Lösungen für State Management, doch Zustand holt schnell auf und führt bei der Nutzerzufriedenheit – so deutlich, dass die Autoren der Umfrage es als Marktführer bezeichnen. Dieselbe Umfrage stellt fest, dass ein großer Teil der Befragten gar keine State-Management-Bibliothek verwendet, da useState und useContext für ihre Anforderungen völlig ausreichen.
Als Entscheidungshilfe, nicht als Trend:
Ein wichtiger Vorbehalt, und zwar der entscheidende: Vieles, wofür Teams zu einem Store greifen, ist Server-State, also gecachte API-Antworten. Das gehört in TanStack Query oder SWR, nicht in einen Client-Store. Klären Sie das zuerst, dann wird die restliche Entscheidung meist sehr viel einfacher.
Die meisten Vergleiche zucken nur mit den Schultern und sagen: „Es kommt darauf an“. Hier ist das, was wir tatsächlich verwenden, wenn wir eine React-Codebasis prüfen oder neu aufsetzen. Zwei Achsen: Anwendungskomplexität, also wie viele Funktionen sich dieselben Daten teilen, und Teamgröße, also wie viele Entwickler diese Daten verändern.
Dieselben vier Regeln in Textform, da Bilder oft schlecht transportierbar sind:
Und hier ist der Punkt, der viele überrascht: Die Teamgröße ist der stärkere Indikator, nicht die Anwendungskomplexität. Eine wirklich komplexe App, die von zwei Entwicklern mit einem gemeinsamen mentalen Modell gewartet wird, läuft hervorragend mit Hooks. Eine eher fummelige App, die von neun Entwicklern in drei Teams betreut wird, tut das nicht – und zwar nicht, weil der Code es nicht ausdrücken könnte, sondern weil neun Leute keine undokumentierte Konvention gleichzeitig im Kopf behalten können.
Stellen Sie sich ein Produkt vor, das über ein paar Quartale von zwei auf zehn Entwickler wächst.
Bei zwei Entwicklern ist eine reine Hooks-Lösung optimal. Der geteilte State liegt in drei Contexts, die Konventionen sind ungeschrieben, weil beide Entwickler sie selbst erstellt haben, und das Deployment geht schnell. Redux wäre hier nur Ballast.
Bei zehn Entwicklern schlägt diese Architektur ins Gegenteil um. Das Onboarding dauert plötzlich Wochen statt Tage, weil es keine kanonische Antwort auf die Frage „Wo liegen diese Daten?“ gibt, sondern nur Präzedenzfälle.
Zwei Entwickler lösen dasselbe Re-Render-Problem unabhängig voneinander auf inkompatible Weise.
Die Fehlersuche bei einem Produktionsvorfall bedeutet, den Zustand durch Lesen des Codes zu rekonstruieren, da es kein Aktionsprotokoll gibt. Die Entwicklungsgeschwindigkeit sinkt, ohne dass eine einzelne Entscheidung dafür verantwortlich wäre.
Der Kompromiss besteht also nicht zwischen Boilerplate und Eleganz. Es geht um Kosten, die man im Voraus zahlt, gegenüber Kosten, die man bei zunehmender Skalierung inklusive Zinsen zahlt.
Das Problem besteht übrigens in beide Richtungen. Redux für ein MVP mit zwei Entwicklern einzuführen, verursacht echte Kosten ohne Gegenwert. Das entscheidende Signal ist nicht die Anzahl der Codezeilen. Es ist der Tag, an dem Ihr Team die Frage „Warum wurde das neu gerendert?“ nicht mehr beantworten kann, ohne den Debugger zu öffnen.
Die umgekehrte Migration kommt immer häufiger vor, meist dann, wenn sich der Redux-Store als getarnter Cache für Serverdaten entpuppt.
useReduceroder einen einzelnen Zustand-Store.
Teams stellen regelmäßig fest, dass Schritt 2 die gesamte Diskussion von selbst beendet. Das Problem war nie Redux. Das Problem war die Verwendung eines Client-State-Managers als Netzwerk-Cache.
Sie möchten mehr erfahren? Unsere Leitfäden zum Thema Auswahl eines Tech-Stacks sowie asynchrone JavaScript-Muster behandeln die grundlegende Architektur rund um dieses Thema.
Redux ist eine Open-Source-Bibliothek zur Verwaltung des globalen Anwendungszustands in JavaScript-Apps, meist in Verbindung mit React. Sie speichert den gemeinsamen Zustand in einem einzigen Objekt, dem sogenannten Store, und ändert diesen ausschließlich über per Dispatch gesendete Aktionen, die von reinen Funktionen, den Reducern, verarbeitet werden. Der Name verrät es bereits: Zustandsänderungen werden reduziert auf einen einzigen, vorhersehbaren Ablauf.
Verwenden Sie Hooks für lokalen Komponentenstatus und kleine, gemeinsam genutzte Werte wie Themes oder Spracheinstellungen. Greifen Sie zu Redux, wenn mehrere Funktionen von denselben Daten abhängen, wenn mehr als fünf Entwickler an der Codebasis arbeiten oder wenn Sie eine lückenlose Nachverfolgung von Zustandsänderungen benötigen. In den meisten produktiven Anwendungen ist die Antwort: beides, auf unterschiedlichen Ebenen.
Beginnen Sie mit Hooks. Wechseln Sie zu Zustand, wenn der gemeinsame Status den Kontext übersteigt und Sie mit unnötigen Re-Renders zu kämpfen haben. Wechseln Sie zu Redux Toolkit, sobald das Team auf etwa fünf Entwickler anwächst oder die Domäne nachvollziehbare Zustandsänderungen erfordert. Zustand führt derzeit bei der Entwicklerzufriedenheit, während Redux nach wie vor am weitesten verbreitet ist.
Ja, aber nicht mehr als automatischer Standard. Die Umfrage „State of React 2025“ zeigt, dass Redux und Redux Toolkit nach wie vor die am weitesten verbreiteten Lösungen sind und die stärkste Option für große Teams und regulierte Bereiche bleiben. Für neue Projekte mit kleinen Teams sind Zustand oder gar keine Bibliothek mittlerweile der üblichere Ausgangspunkt.
Verwenden Sie useReducer bei komplexem State innerhalb einer einzelnen Komponente oder einer eng verknüpften Gruppe: etwa bei mehrstufigen Formularen, Assistenten oder Datentabellen. Nutzen Sie Redux, wenn dieser State über nicht zusammenhängende Teile der Anwendung hinweg geteilt werden muss. Nicht die Komplexität, sondern der Geltungsbereich ist hier entscheidend.
Für kleine und mittelgroße Anwendungen: ja. useContext und useReducer bilden zusammen den Großteil der Redux-Funktionalität ab. Was sie ohne erheblichen Eigenaufwand nicht ersetzen können, sind die selektorbasierte Steuerung von Re-Renders, Middleware für asynchrone Logik und die Debugging-Möglichkeiten der DevTools. Genau darauf verlassen sich große Teams.
Redux ist frameworkunabhängig und fungiert als State-Container, der mit jeder UI-Schicht funktioniert. react-redux ist die offizielle Schnittstelle, die Redux mit React verbindet und Ihnen useSelector sowie useDispatch Hooks. Beide werden benötigt, um Redux in einer React-Anwendung zu verwenden.
Das kann sie. Context verfügt über keinen Selektor-Mechanismus. Wenn sich der Wert eines Providers ändert, werden alle darunterliegenden Consumer neu gerendert – auch diejenigen, die den geänderten Teil gar nicht nutzen. Das ist in Ordnung für Werte, die sich selten ändern, aber problematisch bei allem, was häufig aktualisiert wird oder weit verbreitet ist.
Ist Redux also am Ende? Nein, natürlich nicht. React Hooks und Redux sind Ergänzungen, keine Rivalen. Hooks verwalten den Komponenten-Status und gemeinsam nutzbare Logik, Redux kümmert sich um den globalen Status, ausgelöste Aktionen und die Beobachtbarkeit, auf die große Teams angewiesen sind – und Zustand fügt sich nun nahtlos dazwischen ein.
Noch einmal zurück zum Hausbau: Man entscheidet sich nicht zwischen dem Wasserhahn und dem Hauptanschluss. Man überlegt, wie viele Räume Wasser benötigen, wie viele Leute die Hähne aufdrehen, und verlegt die Leitungen entsprechend.
Wo befindet sich Ihre Anwendung auf der Komplexitätsskala, wo steht Ihr Team in Sachen Größe und wo werden beide in zwölf Monaten sein? Planen Sie Ihre Architektur dafür. Nicht für heute.
Wenn Sie eine React-Anwendung entwickeln oder skalieren und eine klare Antwort zu Ihrer Status-Architektur benötigen, bevor diese sich verfestigt, führt unser Team technische Audits durch, die genau das leisten.
Ich bin seit 2016 Javascript-Entwickler und habe mobile Apps mit Ionic und React Native erstellt. Gitarrist und Kochliebhaber.
People who read this post, also found these interesting:
.webp)
