HÖRT auf, Redux blind zu verwenden!
Als fauler Entwickler – ich war nicht überzeugt. Mir schien, dass die Standard-State- und Context-Verwaltung viel besser war. Redux hatte viel zu viel Boilerplate-Code und die Separation of Concerns, obwohl berechtigt, hätte genauso leicht mit einem Custom Hook erreicht werden können. Wir verwendeten auch redux-saga für die Interaktion mit dem Backend. Das wirkte auf mich wie eine weitere völlig unnötige Last.
Aber ich war gerade am Anfang meiner Karriere – also dachte ich, ich gebe Redux eine faire Chance. Ich arbeitete etwa ein Jahr lang mit Redux und redux-saga. Und meine Argumente dagegen wurden nur intensiver. Ich fragte immer wieder – warum verwenden wir Redux, und meine Vorgesetzten gaben mir Antworten wie –
- Es macht den Code besser testbar
- Es trennt die Business-Logik von der Komponenten-Logik
- Es wird empfohlen, useState nicht für komplexe Datentypen zu verwenden (wie Objekte oder Arrays von Objekten)
- redux-saga kann dir mehr Kontrolle über den API-State geben
- Du könntest Context verwenden, aber wie viele Context-Provider wirst du deine App wrappen?
Auf alle diese Punkte hatte ich Antworten, aber keine besonders überzeugenden. Redux war eben Redux – verwendet von Millionen von Entwicklern und großen Unternehmen – und ich war nur ein Junior-Softwareentwickler, der frustriert über Boilerplate-Code war.
Jetzt, nachdem ich als Team Lead gearbeitet habe, kann ich selbstbewusst sagen, meine Vorgesetzten lagen alle falsch – und sie würden zustimmen. Mein Grund für diesen Artikel ist, dass es auch heute noch so viele Unternehmen gibt, die Redux verwenden und es als blinden Standard akzeptieren. Wir müssen innehalten und uns die Alternativen ansehen, die wir haben!
Zunächst wollen wir das Problem mit Redux deutlicher verstehen. Hier ist die Menge an Code, den wir für einen einfachen Count-State mit Redux schreiben müssten. Das ist natürlich nur ein Beispiel – zeigt keine echte Anwendung, ist aber ziemlich effektiv.
// src/actionConstants.js
const ACTION_CONSTANTS = {
INCREMENT_COUNT: "INCREMENT_COUNT",
DECREMENT_COUNT: "DECREMENT_COUNT",
RESET_COUNT: "RESET_COUNT"
}
// src/store/countStore/reducer.js
const initialState = { count: 0 }
export const countReducer = (state = initialState, action) => {
switch (action.type){
case ACTION_CONSTANTS.INCREMENT_COUNT:
return { count: state.count + 1 };
case ACTION_CONSTANTS.DECREMENT_COUNT:
return { count: state.count - 1 };
case ACTION_CONSTANTS.RESET_COUNT:
return initialState;
}
}
// src/store/countStore/selectors.js
export const useCountReducer = () => {
return useSelector(store => store.countReducer)
}
// src/store/countStore/actions.js
export const incrementCount = () => ({
type: ACTION_CONSTANTS.INCREMENT_COUNT
})
export const decrementCount = () => ({
type: ACTION_CONSTANTS.DECREMENT_COUNT
})
export const resetCount = () => ({
type: ACTION_CONSTANTS.RESET_COUNT
})
// src/store/index.js
const rootReducer = combineReducers({ countReducer: countReducer, ... });
Ist das nicht einfach kriminell? Das berücksichtigt noch nicht einmal den Code in deinem Saga oder Thunk für die Backend-Interaktion – das ist nur für eine regelmäßig gemeinsam genutzte State-Variable – Count. Stell dir vor, wie viel Mühe du aufbringen musst, nur um eine kleine Änderung der Logik vorzunehmen – von einer Datei zur anderen springen und sicherstellen, dass diese Änderungen in alle Dateien konsistent eingehen.
Redux ist als globaler Store gedacht. Es soll verwendet werden, um den State über alle Komponenten in deiner App zu teilen. Das Problem ist aber: Wenn Unternehmen anfangen, Redux zu verwenden, neigen sie dazu, ihren ganzen API-State (der in Zukunft „möglicherweise" geteilt werden muss) mit Redux zu speichern. Das ist sinnvoll für ein Projekt, an dem viele Menschen arbeiten werden – und du möchtest eine konsistente Art des Code-Schreibens haben. Allerdings vergrößert das die Code-Größe und reduziert dessen Wartbarkeit drastisch.
Obwohl sie redux-toolkit eingeführt haben und das den Code ein wenig aufräumt – es vergleicht sich immer noch nicht mit vielen anderen Bibliotheken da draußen, die den Job viel besser machen. Hier ist der bevorzugte Stack, den wir bei My Next Developer verwenden:
React-Query: Ich verwende React-Query, um alle API-States in meinen Apps zu verwalten. Es verwaltet intern Loading-, Error- und Success-States für alle API-Aufrufe, cached Ergebnisse, um erneutes Abrufen zu vermeiden, und macht es super einfach, auf die Daten über mehrere Komponenten hinweg zuzugreifen. Das ist ein wunderschönes Tool – wenn du es einmal verwendest, verspreche ich dir, du wirst nicht zurückgehen. Eine einfache Dokumentation und eine Hooks-basierte Implementierung machen es sehr sauber. Hier ist eine beliebte YouTube-Playlist von React Query Tutorial für Anfänger von Codevolution, um React-Query zu lernen.
Context: Es gibt sehr wenige Fälle, in denen wir einen nicht-API-basierten globalen State haben, der über mehrere Komponenten hinweg geteilt werden muss. In diesen wenigen Fällen ist Context am einfachsten zu implementieren. Es fügt auch unnötigerweise keine weitere Bibliothek hinzu.
Bist du nicht einer Meinung? Ich würde gerne deine Gedanken hören!
