L'état local appartient à un seul composant (ou à une petite sous-arborescence) et n'est pas nécessaire ailleurs. L'état global est partagé entre de nombreux composants, souvent distants, dans toute l'application.
() {
[query, setQuery] = ();
;
}
L'état local vit à l'intérieur du composant (useState, ref, data()). Exemples : les valeurs d'entrée, si une liste déroulante est ouverte, l'état du survol, le brouillon d'un formulaire. Aucun autre composant ne s'en soucie.
// the logged-in user is needed by the navbar, profile page, settings, checkout...
const user = useUserStore(s => s.user); // from a global store/context
L'état global est une donnée que de nombreux composants non liés doivent lire ou mettre à jour de manière cohérente : l'utilisateur authentifié, le thème, le panier d'achat, les notifications à l'échelle de l'application. Il vit dans un Context, un store (Redux/Zustand/Pinia), ou similaire.
Ask: "How many components need this, and how far apart are they?"
One component (or parent+child) → LOCAL state
Many unrelated components / whole app → GLOBAL state
// ❌ putting a single form's input in global state — unnecessary complexity
globalStore.setFormInput(value);
// ✅ keep it local — only this form uses it
const [value, setValue] = useState("");
Rendre tout global ajoute du code boilerplate, couple les composants, et peut nuire à la performance (plus de re-rendus). La meilleure pratique est de garder l'état aussi local que possible, et de le lever vers le global uniquement quand le partage l'exige vraiment.
Choisir entre local et global est l'une des décisions d'état les plus importantes.
Garder l'état local rend les composants simples, autonomes et performants ; recourir à l'état global seulement quand les données sont vraiment partagées évite une complexité inutile.
L'anti-pattern fréquent — mettre tout dans un store global « juste au cas où » — conduit à des applications gonflées et fortement couplées.
La règle directrice : localiser par défaut, globaliser seulement quand le partage l'exige.