Context API
React 🟡 MidDéfinition
Partage de données sans prop drilling via createContext et un fournisseur. Depuis React 19 (5 décembre 2024), on rend directement <MonContext value={...}> au lieu de <MonContext.Provider>, et use(MonContext) peut remplacer useContext. Attention : chaque changement de valeur re-rend tous les consommateurs.
Analogie
Comme un haut-parleur dans un magasin : tout le monde entend l'annonce, même ceux qui ne sont pas concernes.
Exemple de code
const AuthCtx = createContext(null);
function AuthProvider({ children }) {
const [user, setUser] = useState(null);
const value = useMemo(() => ({ user, setUser }), [user]);
// React 19 : le Context est lui-même le fournisseur
return <AuthCtx value={value}>{children}</AuthCtx>;
}
function Avatar() {
const { user } = use(AuthCtx); // ou useContext(AuthCtx)
return <img src={user?.avatar} alt="" />;
}
Cas d'usage
Données peu changeantes (theme, auth, locale) partagées a travers l'arbre.
Anti-pattern
Termes liés
En entretien
Explique-moi Context API et son piège de performance.
Context API partage des données sans prop drilling via createContext et un fournisseur, mais chaque changement de valeur re-rend tous les consommateurs. Il faut donc le réserver à des données peu changeantes comme le thème, l'authentification ou la locale.
Qu'est-ce qui change dans l'écriture du Provider depuis React 19 ?
On peut rendre directement <MonContext value={...}> au lieu de <MonContext.Provider>, et use(MonContext) peut remplacer useContext. C'est une simplification syntaxique, le comportement de re-rendu des consommateurs reste identique.
Quel anti-pattern évite-t-on avec Context ?
Stocker du state fréquemment mis à jour dans un seul Context non découpé, ce qui provoque des re-rendus en cascade sur tous les consommateurs. Il vaut mieux découper en plusieurs contextes selon la fréquence de mise à jour.
Fiche mise à jour le 2026-09-27