React Montréal — Comment choisir une bibliothèque de gestion d'état ?  

Hier soir, j'ai eu le privilège de présenter un talk devant la communauté React Montréal 🙌

Le sujet : "Comment choisir une bibliothèque de gestion d'état pour vos applications React et React Native".

La gestion d'état est l'un des sujets les plus discutés dans l'écosystème React. Entre Redux, Zustand, Jotai, Recoil, Context API ou encore TanStack Query, le choix peut vite devenir déroutant — surtout quand on doit aussi penser à la compatibilité avec React Native.

Au cours de cette présentation, j'ai proposé une grille de lecture pour aider les développeurs à choisir la solution adaptée à leur contexte, en tenant compte de plusieurs critères :

• La taille et la complexité de l'application
• Le type d'état : local, partagé, ou serveur
• La courbe d'apprentissage et la DX (Developer Experience)
• La maintenabilité à long terme

📜 Historique de React State

Pour bien choisir, il faut comprendre d'où on vient. La gestion d'état dans React a beaucoup évolué :

• React 0.13 — setState sur les class components, le début de tout
• Redux (2015) — store centralisé, actions, reducers, inspiré de Flux
• Context API (React 16.3) — partage de données sans prop drilling
• Hooks (React 16.8) — useState, useReducer, useContext — révolution dans la façon d'écrire l'état local
• Zustand, Jotai, Recoil (2020+) — bibliothèques légères orientées hooks
• TanStack Query, SWR — gestion dédiée de l'état serveur

⚠️ Limites des Hooks

Les hooks ont simplifié énormément de choses, mais ils ont leurs limites :

• Re-renders excessifs — chaque changement de state redéclenche le rendu du composant et de ses enfants
• Prop drilling — même avec les hooks, passer l'état en profondeur reste fastidieux sans Context
• Context API non optimisé — un Context change → tous les consommateurs re-renderisent, même ceux qui n'utilisent pas la valeur modifiée
• Pas de devtools natifs — difficile à déboguer sans outillage externe
• État partagé complexe — useReducer peut devenir verbeux et difficile à maintenir sur des gros projets

🔀 Options Tierces

Face à ces limites, l'écosystème a répondu avec des solutions adaptées à chaque besoin :

⚖️ Différences clés entre state managements

Trois grandes familles se distinguent :

1. État global centralisé (Redux, Zustand) Un seul store contient tout l'état de l'app. Prévisible, facile à déboguer avec les devtools, mais peut devenir verbeux.

2. État atomique (Jotai, Recoil) L'état est découpé en "atomes" indépendants. Chaque composant ne s'abonne qu'aux atomes dont il a besoin — moins de re-renders inutiles.

3. État serveur (TanStack Query, SWR) Sépare clairement l'état client de l'état serveur. Gère automatiquement le cache, la revalidation et les états de chargement/erreur.

⚡ Découverte TC39 : Signals

Les Signals sont un nouveau primitif réactif en cours de standardisation dans JavaScript lui-même. Inspirés par SolidJS, Angular Signals et Preact Signals, ils permettent une réactivité fine-grained — seules les parties de l'UI qui dépendent d'une valeur se mettent à jour, sans re-render du composant entier.

// Concept simplifié
const count = new Signal(0)
count.value++ // seuls les abonnés directs se mettent à jour

Si cette proposition passe, la gestion d'état pourrait changer fondamentalement — non plus au niveau des frameworks, mais au niveau du langage. À surveiller de très près ! 👀

Ce qui m'a le plus marqué lors de cette soirée, c'est l'énergie et l'engagement de la communauté. Les questions posées après le talk étaient pertinentes, les échanges riches, et j'ai pu avoir des discussions passionnantes avec des développeurs de tous niveaux.

Un immense merci à Zenika Canada pour l'accueil et le soutien — ces événements ne seraient pas possibles sans eux. 🙏

🎥 Replay de la présentation

La présentation est disponible en replay sur YouTube. N'hésitez pas à la regarder et à partager vos retours !

🖼️ Galerie photo