Redux erklärt: Wann zentrale Zustandsverwaltung sinnvoll ist

Wenn eine React-Anwendung wächst, reicht lokaler Component State oft nicht mehr aus. Daten wie Benutzerkonten, Warenkörbe, Filter, Berechtigungen oder Benachrichtigungen müssen dann an vielen Stellen konsistent verfügbar sein. Redux schafft dafür eine zentrale und nachvollziehbare Zustandsverwaltung und zeigt klar, wie Änderungen durch eine Anwendung fließen.

Was Redux in einer Webanwendung eigentlich verwaltet

Redux ist eine JavaScript-Bibliothek für das State Management. Mit „State“ sind alle veränderlichen Daten gemeint, die den aktuellen Zustand einer Anwendung beschreiben, zum Beispiel ein eingeloggter Benutzer, die Inhalte eines Warenkorbs oder der Status eines API-Aufrufs.

Der entscheidende Gedanke lautet, dass wichtige globale Daten nicht beliebig in einzelnen Komponenten verändert werden. Stattdessen liegen sie in einem zentralen Store. Komponenten lesen daraus die benötigten Werte und lösen bei Benutzeraktionen klar beschriebene Änderungen aus.

Redux ist dabei nicht an React gebunden. Die Bibliothek kann auch mit anderen Benutzeroberflächen oder sogar ohne UI-Framework eingesetzt werden. In React-Projekten übernimmt React Redux die Verbindung zwischen Komponenten und Store.

Lokaler State und globaler State

Nicht jeder Zustand gehört in Redux. Ein geöffnetes Dropdown, der Inhalt eines einzelnen Eingabefelds oder eine lokale Animation bleibt meist besser direkt in der jeweiligen Komponente. Dafür reichen React Hooks wie useState vollkommen aus.

Redux wird interessant, wenn mehrere weit voneinander entfernte Komponenten auf dieselben Daten zugreifen oder sie verändern müssen. Ich setze es besonders dann ein, wenn sich sonst viele Eigenschaften durch mehrere Ebenen von Komponenten weiterreichen müssten. Dieses sogenannte Prop Drilling wird bei größeren Oberflächen schnell unübersichtlich.

So funktioniert der Redux-Datenfluss

Redux folgt einem unidirektionalen Datenfluss. Das bedeutet, dass Änderungen nicht direkt und unkontrolliert in Komponenten stattfinden, sondern einen festen Weg nehmen. Genau diese Einschränkung macht das Verhalten einer komplexen Anwendung besser vorhersehbar.

1. Eine Benutzeraktion oder ein Ereignis löst eine Action aus.
2. Die Action wird mit dispatch an den Store gesendet.
3. Ein Reducer verarbeitet die Action zusammen mit dem bisherigen State.
4. Der Store erhält einen neuen Zustand.
5. Betroffene Komponenten lesen die neuen Werte und rendern erneut.

Actions beschreiben, was passiert ist

Eine Action ist ein einfaches JavaScript-Objekt mit einem Typ. Häufig enthält sie zusätzlich ein Payload, also die Nutzdaten der Änderung.

{
  type: 'cart/itemAdded',
  payload: {
    productId: 42,
    quantity: 1
  }
}

Die Action sagt nur, was passiert ist. Sie sollte nicht selbst entscheiden, wie der gesamte Zustand verändert wird. Dadurch bleibt sie leicht verständlich und kann in den Redux DevTools später nachvollzogen oder erneut abgespielt werden.

Reducer berechnen den neuen Zustand

Ein Reducer ist eine Funktion, die den bisherigen State und eine Action entgegennimmt. Daraus berechnet sie den nächsten State. Ein gut geschriebener Reducer ist vorhersagbar und frei von Seiteneffekten, also ohne direkte API-Aufrufe oder versteckte Änderungen außerhalb seiner Zuständigkeit.

const counterReducer = (state = { value: 0 }, action) => {
  if (action.type === 'counter/incremented') {
    return { value: state.value + 1 }
  }

  return state
}

Redux arbeitet grundsätzlich mit unveränderlichen Zuständen. Der alte State wird nicht direkt überschrieben. Stattdessen entsteht ein neuer State, sodass Redux und angeschlossene UI-Bibliotheken zuverlässig erkennen können, welche Daten sich geändert haben.

Der Store ist die zentrale Datenquelle

Der Store enthält den aktuellen State und nimmt Actions entgegen. Komponenten können sich für Änderungen anmelden oder über React Redux gezielt Teile des Zustands auswählen. In einer größeren Anwendung wird der Store meist in mehrere sogenannte Slices aufgeteilt, etwa für Authentifizierung, Warenkorb und Produkte.

Diese Aufteilung bedeutet nicht, dass mehrere völlig unabhängige Redux-Systeme entstehen. Es gibt weiterhin einen gemeinsamen Store, dessen Bereiche durch kleinere Reducer organisiert werden. Das hält die Struktur übersichtlich, ohne die zentrale Datenquelle aufzugeben.

Warum Redux Toolkit heute der bessere Einstieg ist

Früher war Redux für seinen hohen Anteil an Boilerplate-Code bekannt. Entwickler mussten Action-Typen, Action Creator, Reducer und Store-Konfiguration häufig von Hand anlegen. Das funktionierte, erzeugte bei kleinen Änderungen aber schnell viele Dateien und wiederholte Codebausteine.

Für neue Projekte empfiehlt das Redux-Team deshalb Redux Toolkit. Es ist kein komplett anderes State-Management-System, sondern das offizielle Werkzeugpaket für modernes Redux. Es bündelt sinnvolle Standardeinstellungen und reduziert typische Fehler.

Ein Slice bündelt zusammengehörige Logik

Mit createSlice lassen sich Initial State, Reducer und Action Creator in einer Einheit definieren. Das ist meiner Erfahrung nach der größte praktische Unterschied zu älteren Redux-Beispielen, weil eine Funktion meist an einem Ort verständlich bleibt.

import { configureStore, createSlice } from '@reduxjs/toolkit'

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    incremented(state) {
      state.value += 1
    },
    decremented(state) {
      state.value -= 1
    }
  }
})

const store = configureStore({
  reducer: {
    counter: counterSlice.reducer
  }
})

store.dispatch(counterSlice.actions.incremented())

Die scheinbare Änderung von state.value ist hier kein Verstoß gegen das Immutability-Prinzip. Redux Toolkit verwendet im Hintergrund Immer, das aus dieser Schreibweise einen korrekten neuen Zustand erzeugt. Der Code bleibt dadurch lesbar, ohne die Vorteile unveränderlicher Updates zu verlieren.

RTK Query für Abrufe und Caching

Redux Toolkit enthält mit RTK Query zusätzlich eine Lösung für Datenabrufe, Ladezustände und Caching. Das ist besonders hilfreich, wenn eine Anwendung viele API-Daten lädt und nicht jede Kombination aus „loading“, „success“ und „error“ manuell verwaltet werden soll.

Ich würde RTK Query aber nicht mit dem gesamten Anwendungszustand gleichsetzen. Serverdaten und lokaler UI-Zustand haben unterschiedliche Anforderungen. Eine gute Architektur trennt daher häufig Daten vom Backend, temporäre Benutzeroberflächen-Zustände und dauerhaft relevante globale Informationen.

Redux und React arbeiten zusammen, sind aber nicht dasselbe

React erstellt die Benutzeroberfläche, Redux organisiert Zustandsänderungen. Diese Rollen werden oft vermischt, obwohl beide Werkzeuge unabhängig voneinander funktionieren. React Redux stellt die Verbindung her, damit React-Komponenten den Store lesen und Actions auslösen können.

In einer React-Anwendung wird der Store normalerweise über einen Provider im Komponentenbaum verfügbar gemacht. Komponenten greifen dann mit useSelector auf benötigte Werte zu und verwenden useDispatch, um Actions zu senden.

import { useDispatch, useSelector } from 'react-redux'

function Counter() {
  const value = useSelector(state => state.counter.value)
  const dispatch = useDispatch()

  return (
     dispatch(counterSlice.actions.incremented())}>
      Anzahl: {value}
    
  )
}

Ein wichtiger Vorteil von React Redux liegt in der gezielten Aktualisierung. Eine Komponente kann nur den Teil des Stores auswählen, den sie wirklich benötigt. Ändert sich ein anderer Bereich, muss sie nicht automatisch neu gerendert werden. Das ist bei großen Oberflächen für Performance und Wartbarkeit relevant.

Wann Redux sinnvoll ist und wann nicht

Redux ist kein Pflichtbestandteil jeder React-Anwendung. Für eine kleine Website mit wenigen interaktiven Komponenten wäre ein globaler Store meist unnötig. Er würde zusätzliche Konzepte einführen, ohne ein echtes Problem zu lösen.

Sinnvoll wird Redux, wenn Daten an vielen Stellen benötigt werden, sich häufig ändern oder über mehrere Benutzeraktionen hinweg konsistent bleiben müssen. Die offizielle Dokumentation nennt als typische Situation eine Anwendung mit größeren Datenmengen, einem zentralen Wahrheitsstand und State, der in einer einzelnen übergeordneten Komponente nicht mehr sauber aufgehoben werden kann.

• Mehrere Bereiche benötigen dieselben Daten.
• Änderungen sollen über klar nachvollziehbare Ereignisse laufen.
• Die Anwendung besitzt komplexe Geschäftslogik.
• Fehler müssen über eine Historie von Actions reproduzierbar sein.
• Ein Team braucht verbindliche Regeln für Zustandsänderungen.

Gegen Redux spricht vor allem die zusätzliche Struktur. Auch Redux Toolkit nimmt einem nicht die Architekturentscheidungen ab. Wer jeden kleinen Wert in den Store legt, erzeugt unnötige Abhängigkeiten und macht die Anwendung schwerer verständlich.

Lesen Sie auch: Softwarebeispiele für Webentwicklung und passende Frameworks

Redux im Vergleich zu React Context

React Context eignet sich gut, um Werte wie Theme, Sprache oder Benutzerinformationen durch den Komponentenbaum zu reichen. Er ist jedoch nicht automatisch eine vollständige Lösung für komplexe Zustandslogik, Action-Historien oder umfangreiche Datenflüsse.

Meine praktische Faustregel lautet: Context ist eine gute Transportmöglichkeit für wenige, relativ stabile Werte. Redux ist die stärkere Wahl, wenn viele Ereignisse, Abhängigkeiten und Regeln zusammenkommen.

Typische Fehler bei der Einführung

Der häufigste Fehler besteht darin, Redux als Ablage für alles zu behandeln. Ein lokaler Dialogzustand wird dadurch genauso zentral verwaltet wie ein Warenkorb. Das wirkt zunächst konsequent, führt aber zu unnötig langen Datenwegen und macht Komponenten weniger eigenständig.

Ebenso problematisch ist es, Serverdaten ohne klare Strategie in eigenen Reducern zu verwalten. Ladezustände, Fehler, Cache-Invalidierung und parallele Anfragen ergeben schnell viel Handarbeit. RTK Query oder eine passende Datenbibliothek kann diese Aufgaben deutlich sauberer lösen.

• Keine direkten Mutationen außerhalb der vorgesehenen Redux-Logik.
• Keine API-Aufrufe direkt in einem Reducer.
• Keine unnötig verschachtelten States, wenn flache Strukturen ausreichen.
• Keine Speicherung von Funktionen, Promises oder DOM-Elementen im State.
• Keine globalen Werte, die nur eine einzige Komponente benötigt.

Auch die Auswahl von Daten sollte präzise erfolgen. Ein Selector, der bei jedem Aufruf neue Objekte erzeugt, kann unnötige Renderzyklen auslösen. Selektoren sollten deshalb möglichst stabil sein und nur die Daten zurückgeben, die eine Komponente tatsächlich braucht.

So würde ich ein neues Redux-Projekt starten

Bei einem neuen Projekt würde ich nicht mit der alten manuellen Redux-Syntax beginnen. Ich würde Redux Toolkit, React Redux und TypeScript verwenden, sofern das Projekt ohnehin typisiert entwickelt wird. Diese Kombination bietet gute Standardeinstellungen und reduziert viele Fehler erst zur Entwicklungszeit.

1. Installiere @reduxjs/toolkit und react-redux.
2. Lege den Store mit configureStore an.
3. Ordne jede fachliche Einheit einem Slice zu.
4. Verbinde den Store über den Provider mit der React-Anwendung.
5. Verwende Selectors zum Lesen und Actions zum Ändern des Zustands.
6. Prüfe mit Redux DevTools, ob der Datenfluss verständlich bleibt.

Für ein Team ist außerdem eine kurze Zustandskonvention hilfreich. Darin sollte stehen, welche Daten lokal bleiben, welche in Redux gehören und welche als Serverdaten behandelt werden. Diese Entscheidung spart langfristig mehr Zeit als jede einzelne technische Abkürzung.

Redux ist damit weder veraltet noch automatisch die beste Lösung. Es ist ein bewusst strukturiertes Werkzeug für Anwendungen, bei denen vorhersagbare globale Zustandsänderungen einen echten Vorteil bringen.

Die wichtigste Entscheidung fällt vor der ersten Action

Die zentrale Frage lautet nicht, ob Redux technisch eingesetzt werden kann, sondern ob die Anwendung von seiner Struktur profitiert. Bei wenigen Zuständen genügt oft React selbst. Bei komplexen Geschäftsprozessen, vielen beteiligten Komponenten und hohen Anforderungen an Nachvollziehbarkeit spielt Redux Toolkit seine Stärken aus.

Wer diese Grenze sauber zieht, erhält keinen überladenen Store, sondern eine belastbare Architektur. Genau darin liegt für mich der eigentliche Wert von Redux: nicht möglichst viel Zustand zu zentralisieren, sondern wichtige Änderungen verständlich und reproduzierbar zu machen.