SLUTA använda Redux blindt!
Som en lat utvecklare — jag köpte det inte. Jag kände att det var mycket bättre att använda standardtillståndet och context. Det fanns mycket för mycket boilerplate i Redux och separation of concerns, även om det var giltigt, kunde lika lätt uppnås med en anpassad hook. Vi använde också redux-saga för att interagera med backend. Det kändes som en till mycket onödig börda för mig.
Men jag började min karriär — så jag tänkte att jag skulle ge det en rättvis chans. Jag använde redux och redux-saga i ungefär ett år. Och mina argument mot det intensifierades bara. Jag fortsatte fråga — varför använder vi redux, och mina överordnade gav mig svar som —
- Det gör koden mer testbar
- Det separerar affärslogiken från komponentlogiken
- Det rekommenderas att inte använda useState för komplexa datatyper (som objekt eller matriser av objekt)
- redux-saga kan ge dig mer kontroll över API-tillståndet
- Du kunde använda context, men hur många context-leverantörer skulle du slinga runt din app?
På alla dessa hade jag svar, men inte super-övertygande. Jag menar, redux var redux — använt av miljontals utvecklare och stora företag — och jag var bara en junior-softwareingenjör med frustration över boilerplate.
Nu, efter att ha arbetat som teamledare, kan jag säga med säkerhet att mina överordnade hade helt fel — och de skulle hålla med. Min anledning till att skriva denna artikel är att även idag finns det så många företag som använder redux och accepterar det som en blind standard. Vi måste pausa och titta på de alternativ vi har!
Till att börja med, låt oss förstå problemet jag har med redux mer tydligt. Här är mängden kod vi skulle behöva skriva för ett enkelt räknetillstånd med redux. Uppenbart, detta är bara ett exempel — visar inte en riktig applikation, men det är ganska effektivt.
// 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, ... });
Är det inte bara kriminellt? Detta står inte för koden som går in i din saga eller thunk när du interagerar med backend — detta är bara för en vanligt delad tillståndsvariabel — count. Föreställ dig mängden besvär du måste gå igenom bara för att göra en mindre ändring av logiken — hoppa från en fil till en annan och se till att dessa ändringar är konsekventa på alla filer.
Redux är avsett att vara ett globalt arkiv. Det är avsett att användas för att dela tillståndet mellan alla komponenter i din app. Men problemet är att när företag börjar använda redux tenderar de att lagra all sin API-tillstånd (som 'kanske' behöver delas i framtiden) med redux. Detta är vettigt för ett projekt där många människor kommer att arbeta — och du vill ha ett konsekvent sätt att skriva kod på. Det ökar dock kodens storlek och minskar dess underhållbarhet drastiskt.
Även om de har introducerat redux-toolkit och det rengör koden lite — det står fortfarande inte i jämförelse med många andra bibliotek där ute som hjälper till att göra jobbet mycket bättre. Här är den standard stack vi använder på My Next Developer:
React-Query: Jag använder react-query för att hantera all API-tillståndet i mina appar. Det hanterar internt inläsning, fel och framgångstillstånd för alla API-anrop, cachelagrar resultat för att undvika omhämtning och gör det super enkelt att få tillgång till data på flera komponenter. Detta är ett vackert verktyg — när du väl använt det, lovar jag att du inte går tillbaka. Enkel dokumentation och en hooks-baserad implementering gör den mycket ren. Här är en populär YouTube-spellista med React Query Tutorial för nybörjare av Codevolution för att lära dig react-query.
Context: Det finns mycket få fall där vi har ett icke-API-baserat globalt tillstånd som behöver delas mellan flera komponenter. I dessa få fall är context det enklaste att implementera. Det lägger inte heller onödigt till ett annat bibliotek i mixen.
Håller du inte med? Jag skulle älska att höra dina tankar!
