SMETTI di usare Redux alla cieca!
Come sviluppatore pigro — non mi convinceva. Sentivo che usare il state predefinito e il context era molto meglio. C'era troppo boilerplate in Redux e la separazione delle responsabilità, sebbene valida, poteva essere ottenuta altrettanto facilmente usando un custom hook. Usavamo anche redux-saga per interagire con il backend. Mi semblava un'altra responsabilità altamente inutile.
Ma stavo iniziando la mia carriera — così ho pensato di dargli una possibilità equa. Ho usato redux e redux-saga per circa un anno. E i miei dubbi su di esso si sono solo intensificati. Continuavo a chiedermi — perché stiamo usando redux, e i miei senior mi hanno dato risposte come —
- Rende il codice più testabile
- Separa la logica di business dalla logica dei componenti
- È consigliato non usare useState per tipi di dati complessi (come oggetti o array di oggetti)
- redux-saga può darti più controllo sullo stato dell'API
- Potresti usare context, ma quanti context provider avvolgerai la tua app?
A tutte queste, avevo risposte, ma non super convincenti. Voglio dire, redux era redux — usato da milioni di sviluppatori e grandi aziende — e io ero solo un junior software engineer frustrato dal boilerplate.
Ora, dopo aver lavorato come Team Lead, posso dire con sicurezza che i miei senior avevano tutti torto — e sarebbero d'accordo. La mia ragione per scrivere questo articolo è che ancora oggi, ci sono così tante aziende che usano redux e lo accettano come uno standard cieco. Dobbiamo fermarci e guardare alle alternative che abbiamo!
Per iniziare, cerchiamo di capire più chiaramente il problema che ho con redux. Ecco la quantità di codice che dovremmo scrivere per un semplice state di conteggio usando redux. Ovviamente, questo è solo un esempio — non mostra un'applicazione reale, ma è piuttosto efficace.
// 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, ... });
Non è proprio criminale? Questo non tiene nemmeno conto del codice che va nel tuo saga o thunk quando interagisci con il backend — questo è solo per una variabile di state condivisa regolarmente — count. Immagina il numero di problemi che devi affrontare solo per fare una piccola modifica alla logica — saltando da un file all'altro e assicurandoti che quei cambiamenti siano coerenti nei file.
Redux è pensato per essere uno store globale. È da usare per condividere lo state su tutti i componenti nella tua app. Ma il problema è che, quando le aziende iniziano a usare redux, tendono a memorizzare tutto il loro stato API (che 'potrebbe' aver bisogno di essere condiviso in futuro) usando redux. Ha senso per un progetto dove molte persone lavoreranno — e vuoi avere un modo coerente di scrivere il codice. Tuttavia, aumenta la dimensione del codice e riduce drasticamente la sua manutenibilità.
Anche se hanno introdotto redux-toolkit e questo ripulisce un po' il codice — comunque non è paragonabile a molte altre librerie che fanno il lavoro molto meglio. Ecco lo stack che usiamo a My Next Developer:
React-Query: Uso react-query per gestire tutti gli stati API nelle mie app. Gestisce internamente gli stati di caricamento, errore e successo per tutte le chiamate API, cachea i risultati per evitare re-fetching e rende super facile accedere ai dati in più componenti. Questo è uno strumento bellissimo — una volta che lo usi, ti prometto che non tornerai indietro. Una documentazione semplice e un'implementazione basata su hooks la rendono molto pulita. Ecco una popolare playlist di YouTube su React Query Tutorial for Beginners di Codevolution per imparare react-query.
Context: Ci sono molto pochi casi in cui abbiamo uno state globale non basato su API che ha bisogno di essere condiviso su più componenti. In quei pochi casi, context è il più facile da implementare. Inoltre, non aggiunge inutilmente un'altra libreria al mix.
Non sei d'accordo? Mi piacerebbe sentire i tuoi pensieri!
