Quand Context est-il une bonne solution d'état et quand ne l'est-il pas ?

Question

Accepted Answer

La **Context API** de React vous permet de partager une valeur avec toute une sous-arborescence de composants sans prop drilling. C'est excellent pour les données **peu fréquentes et largement partagées** — mais ce n'est *pas* une solution complète de gestion d'état et cela a un piège de re-rendu pour l'état qui change fréquemment. ## Quand Context brille ```jsx const ThemeContext = createContext("light"); function App() { const [theme, setTheme] = useState("light"); return ( {/* any descendant can read theme — no prop drilling */} ); } ``` ```text Good fits (data that's read widely but changes rarely): ✓ Theme (dark/light) ✓ Current user / auth ✓ Locale / i18n ✓ App-wide config or feature flags ``` ## Le piège : chaque consommateur se re-rend sur N'IMPORTE QUEL changement ```jsx // ❌ a context value that changes often re-renders ALL consumers const AppContext = createContext(); // value = { user, cart, notifications, ...everything } // → updating ONE field re-renders EVERY component using the context ``` Quand la valeur du contexte change, **tous** les composants consommant ce contexte se re-rendent — indépendamment du fait qu'ils utilisent ou non la partie qui a changé. Pour l'état qui se met à jour fréquemment, cela cause des problèmes de performance. Context n'a pas d'abonnement sélectif intégré. ## Atténuations et l'alternative ```text ✓ Split into multiple focused contexts (ThemeContext, UserContext separately) ✓ Memoize the value object (useMemo) so it doesn't change identity needlessly ✗ But for high-frequency or large shared state → use a real store ``` Les bibliothèques d'état (Zustand, Redux, Jotai) résolvent le problème de re-rendu avec des **abonnements sélectifs** — les composants s'abonnent uniquement aux slices qu'ils utilisent et se re-rendent seulement quand ceux-ci changent : ```js const count = useStore(s => s.count); // re-renders ONLY when count changes ``` ## Context n'est pas un gestionnaire d'état ```text Context = a TRANSPORT mechanism (passes a value down), NOT state management itself. You still need useState/useReducer to hold the state; Context just distributes it. ``` ## Pourquoi c'est important Connaître le cas d'usage optimal de Context — et ses limites — prévient deux erreurs courantes : faire du prop-drilling de choses qui devraient être dans Context, et mettre l'état à haute fréquence dans Context (causant des re-rendus à l'échelle de l'application). La règle : Context pour les valeurs **rarement modifiées et largement partagées** (thème, utilisateur, locale) ; un store dédié avec abonnements sélectifs pour l'état partagé **fréquemment modifié ou volumineux**. Comprendre que Context distribue l'état mais ne le gère pas clarifie quand c'est suffisant et quand vous avez besoin de plus.