STOP met het blindelings gebruiken van Redux!
Als een luie ontwikkelaar — ik kocht het niet. Ik vond dat het gebruik van de standaard state en context veel beter was. Er was veel te veel boilerplate in Redux en hoewel de scheiding van verantwoordelijkheden geldig is, kon dit net zo goed worden bereikt met behulp van een aangepaste hook. We gebruikten ook redux-saga voor interactie met de backend. Wat voor mij als een onnodig extra belasting voelde.
Maar ik was aan het begin van mijn carrière — dus dacht ik dat ik het een eerlijke kans zou geven. Ik gebruikte redux en redux-saga ongeveer een jaar lang. En mijn argumenten ertegenin werden alleen maar sterker. Ik bleef vragen — waarom gebruiken we redux, en mijn seniors gaven me antwoorden zoals —
- Het maakt de code beter testbaar
- Het scheidt de bedrijfslogica van de componentlogica
- Het wordt aanbevolen om useState niet te gebruiken voor complexe gegevenstypen (zoals objecten of arrays van objecten)
- redux-saga kan je meer controle geven over de API-state
- Je zou context kunnen gebruiken, maar hoeveel context providers wil je om je app heen wikkelen?
Op al deze punten had ik antwoorden, maar niet echt overtuigende. Ik bedoel, redux was redux — gebruikt door miljoenen ontwikkelaars en grote bedrijven — en ik was gewoon een junior softwareingenieur die gefrustreerd was over boilerplate.
Nu, na als Team Lead te hebben gewerkt, kan ik vol vertrouwen zeggen dat mijn seniors allemaal ongelijk hadden — en zij zouden het ermee eens zijn. Mijn reden voor het schrijven van dit artikel is dat er vandaag de dag nog steeds zoveel bedrijven zijn die redux gebruiken en het als een blinde standaard accepteren. We moeten stoppen en kijken naar de alternatieven die we hebben!
Laten we eerst het probleem dat ik met redux heb duidelijker begrijpen. Hier is de hoeveelheid code die we zouden moeten schrijven voor een eenvoudige count-state met behulp van redux. Dit is natuurlijk slechts een voorbeeld — het toont geen echte applicatie, maar het is vrij effectief.
// 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, ... });
Is het niet gewoon misdadig? Dit houdt geen rekening met de code die in je saga of thunk gaat wanneer je met de backend communiceert — dit is slechts voor een regelmatig gedeelde state-variabele — count. Stel je voor hoeveel gedoe je moet doorstaan om slechts een kleine wijziging in de logica aan te brengen — van het ene bestand naar het andere springen en ervoor zorgen dat die wijzigingen consistent zijn in alle bestanden.
Redux is bedoeld als een globale store. Het is bedoeld om de state in alle componenten in je app te delen. Maar het probleem is dat wanneer bedrijven Redux gaan gebruiken, ze de neiging hebben om alle hun API-state (die 'in de toekomst' gedeeld zou kunnen worden) in Redux op te slaan. Dit is logisch voor een project waar veel mensen aan gaan werken — en je wilt één consistente manier hebben van code schrijven. Het verhoogt echter de omvang van de code en vermindert de onderhoudbaarheid drastisch.
Hoewel ze redux-toolkit hebben geïntroduceerd en dat schoont de code inderdaad een beetje op — het kan niet op tegen veel andere bibliotheken daar buiten die het veel beter doen. Hier is de stack die we gebruiken bij My Next Developer:
React-Query: Ik gebruik react-query om alle API-states in mijn apps te beheren. Het beheert intern loading, error en success states voor alle API-calls, cached resultaten om opnieuw ophalen te voorkomen en maakt het super gemakkelijk om toegang te krijgen tot de gegevens in meerdere componenten. Dit is een prachtig hulpmiddel — zodra je het gebruikt, beloof ik je dat je niet teruggaat. Eenvoudige documentatie en een hook-gebaseerde implementatie maken het erg schoon. Hier is een populaire YouTube-afspeellijst van React Query Tutorial voor Beginners door Codevolution om react-query te leren.
Context: Er zijn zeer weinig gevallen waarin we een niet-op-API gebaseerde globale state hebben die in meerdere componenten moet worden gedeeld. In die zeldzame gevallen is context het gemakkelijkst om te implementeren. Het voegt ook onnodig geen ander bibliotheek aan de mix toe.
Ben je het niet eens? Ik zou graag je gedachten horen!
