ARRÊTEZ d'utiliser Redux aveuglément !
En tant que développeur paresseux — je n'y ai pas cru. J'avais l'impression que l'état par défaut et le contexte étaient bien meilleurs. Il y avait bien trop de boilerplate dans Redux et la séparation des préoccupations, bien que valide, aurait pu être tout aussi facilement réalisée en utilisant un hook personnalisé. Nous avons aussi utilisé redux-saga pour interagir avec le backend. Cela me semblait être un autre fardeau tout à fait inutile.
Mais je commençais ma carrière — j'ai donc pensé que je devrais lui donner une chance équitable. J'ai utilisé redux et redux-saga pendant environ un an. Et mes arguments contre cela n'ont fait que s'intensifier. Je ne cessais de demander — pourquoi utilisons-nous redux, et mes aînés m'ont donné des réponses comme —
- Cela rend le code plus testable
- Cela sépare la logique métier de la logique des composants
- Il est recommandé de ne pas utiliser useState pour les types de données complexes (comme les objets ou les tableaux d'objets)
- redux-saga peut vous donner plus de contrôle sur l'état de l'API
- Vous pourriez utiliser le contexte, mais combien de fournisseurs de contexte allez-vous envelopper votre application ?
À tous ces points, j'avais des réponses, mais pas super convaincantes. Je veux dire, redux était redux — utilisé par des millions de développeurs et de grandes entreprises — et j'étais juste un développeur logiciel junior frustré par le boilerplate.
Maintenant, après avoir travaillé en tant que Team Lead, je peux affirmer avec confiance que mes aînés avaient tous tort — et ils seraient d'accord. Ma raison d'écrire cet article est que, même aujourd'hui, il y a tellement d'entreprises qui utilisent redux et l'acceptent comme un standard aveugle. Nous devons nous arrêter et examiner les alternatives que nous avons !
Pour commencer, comprenons plus clairement le problème que j'ai avec redux. Voici la quantité de code que nous devrions écrire pour un simple état count en utilisant redux. Évidemment, ce n'est qu'un exemple — cela ne montre pas une application réelle, mais c'est assez 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, ... });
N'est-ce pas simplement criminel ? Cela ne tient pas encore compte du code dans votre saga ou thunk lors de l'interaction avec le backend — ce n'est que pour une variable d'état partagée régulièrement — count. Imaginez le trouble que vous devez traverser juste pour apporter une modification mineure à la logique — sauter d'un fichier à un autre et vous assurer que ces modifications sont cohérentes d'un fichier à l'autre.
Redux est censé être un magasin global. Il est censé être utilisé pour partager l'état entre tous les composants de votre application. Mais le problème est que, lorsque les entreprises commencent à utiliser redux, elles ont tendance à stocker tout leur état d'API (qui « pourrait » avoir besoin d'être partagé à l'avenir) en utilisant redux. Cela a du sens pour un projet où beaucoup de gens vont travailler — et vous voulez avoir une façon cohérente d'écrire du code. Cependant, cela augmente la taille du code et réduit sa maintenabilité de manière drastique.
Bien qu'ils aient introduit redux-toolkit et que cela nettoie un peu le code — cela ne se compare toujours pas à de nombreuses autres bibliothèques qui font le travail bien mieux. Voici la pile incontournable que nous utilisons chez MyNextDeveloper :
React-Query : J'utilise react-query pour gérer tous les états d'API dans mes applications. Il gère en interne les états de chargement, d'erreur et de succès pour tous les appels d'API, met en cache les résultats pour éviter les re-fetches et facilite l'accès aux données sur plusieurs composants. C'est un outil magnifique — une fois que vous l'utilisez, je vous promets que vous ne reviendrez pas en arrière. Une documentation simple et une implémentation basée sur les hooks la rendent très claire. Voici une playlist YouTube populaire de React Query Tutorial for Beginners par Codevolution pour apprendre react-query.
Context : Il y a très peu de cas où nous avons un état global non basé sur l'API qui doit être partagé entre plusieurs composants. Dans ces rares cas, le contexte est le plus facile à implémenter. Cela n'ajoute pas non plus inutilement une autre bibliothèque au mélange.
Vous n'êtes pas d'accord ? J'aimerais bien connaître votre point de vue !
