Pourquoi la gestion d'état est l'un des problèmes frontend les plus difficiles

Ce que signifie vraiment « état » dans une appli frontend

Une définition en langage clair

Dans une appli frontend, l'état est simplement les données dont dépend votre UI et qui peuvent changer au fil du temps.

Quand l'état change, l'écran doit se mettre à jour pour refléter ce changement. Si l'écran ne se met pas à jour, s'actualise de façon incohérente ou affiche un mélange d'anciennes et de nouvelles valeurs, vous ressentez immédiatement les « problèmes d'état » : des boutons qui restent désactivés, des totaux qui ne correspondent pas, ou une vue qui ne reflète pas l'action récente de l'utilisateur.

Exemples courants vus au quotidien

L'état apparaît dans des interactions petites ou grandes, comme :

• Champs de formulaire : ce que l'utilisateur a tapé, si une case est cochée, quelles erreurs afficher
• Choix de navigation : onglet sélectionné, étape courante d'un assistant, sections développées/réduites
• Données panier/achat : articles, quantités, coupons appliqués, totaux calculés
• Session utilisateur : informations de l'utilisateur connecté, permissions, drapeaux de fonctionnalité, préférences « se souvenir de moi »

Certains de ces éléments sont « temporaires » (comme un onglet sélectionné), d'autres semblent « importants » (comme un panier). Ce sont tous de l'état parce qu'ils influencent ce que l'UI rend à un instant donné.

Pourquoi l'état n'est pas que « des variables dans un composant »

Une variable simple n'importe où n'a d'importance que là où elle vit. L'état est différent parce qu'il a des règles :

• Propriété : quelle partie de l'app a le droit de le modifier
• Flux de mise à jour : quand et comment les changements déclenchent des re-renders
• Cohérence : s'assurer que plusieurs parties de l'UI ne divergent pas

Le vrai objectif de la gestion d'état n'est pas de stocker des données, mais de rendre les mises à jour prédictibles pour que l'UI reste cohérente. Si vous pouvez répondre à « qu'est-ce qui a changé, quand et pourquoi », l'état devient gérable. Sinon, même des fonctionnalités simples se transforment en surprises.

Pourquoi l'état semble facile au début (puis plus du tout)

Au démarrage d'un projet frontend, l'état paraît presque ennuyeusement simple—dans le bon sens. Vous avez un composant, un champ, et une mise à jour évidente. Un utilisateur tape dans un champ, vous enregistrez la valeur, et l'UI se re-render. Tout est visible, immédiat et contenu.

Le cas simple : un composant, une mise à jour

Imaginez un champ texte unique qui affiche en aperçu ce que vous avez tapé :

• L'état vit dans le même composant qui rend le champ.
• La mise à jour se fait en réponse directe à l'action de l'utilisateur.
• Il n'y a pas de débat sur « qui possède » les données.

Dans ce contexte, l'état est essentiellement : une variable qui change dans le temps. Vous pouvez pointer où elle est stockée et où elle est mise à jour, et c'est tout.

Pourquoi l'état local de composant paraît simple

L'état local fonctionne parce que le modèle mental correspond à la structure du code :

• La portée est petite (un composant, peut‑être quelques enfants).
• Les mises à jour sont synchrones du point de vue de l'utilisateur.
• Le flux de données est évident : saisie → mise à jour → rendu.

Même avec un framework comme React, vous n'avez pas besoin de penser profondément à l'architecture. Les choix par défaut suffisent.

Ce qui change quand l'app grandit

Dès que l'app cesse d'être « une page avec un widget » et devient « un produit », l'état ne vit plus en un seul endroit.

La même donnée peut maintenant être nécessaire à :

• plusieurs écrans (navigation)
• des composants éloignés (UI partagée)
• des rechargements et redémarrages (persistance)
• plusieurs utilisateurs/appareils (synchronisation serveur)

Un nom de profil peut apparaître dans l'entête, être modifié dans une page de paramètres, mis en cache pour un chargement plus rapide, et aussi servir à personnaliser un message de bienvenue. Soudain, la question n'est plus « comment stocker cette valeur ? » mais « où doit vivre cette valeur pour rester correcte partout ? »

La complexité augmente de façon non linéaire

La complexité de l'état ne croît pas progressivement avec les fonctionnalités—elle saute.

Ajouter un deuxième endroit qui lit la même donnée n'est pas « deux fois plus dur ». Cela introduit des problèmes de coordination : maintenir la cohérence des vues, éviter les valeurs obsolètes, décider qui met à jour quoi et gérer le timing. Une fois que vous avez quelques pièces d'état partagées plus du travail asynchrone, vous pouvez vous retrouver avec un comportement difficile à raisonner—alors que chaque fonctionnalité individuelle semble encore simple.

Trop de sources de vérité

L'état devient pénible quand une même « vérité » est stockée à plusieurs endroits. Chaque copie peut diverger, et maintenant votre UI se dispute elle‑même.

Les suspects habituels

La plupart des applications finissent par avoir plusieurs lieux pouvant contenir la « vérité » :

• Données serveur (votre API/base) : l'enregistrement canonique
• Cache client (p. ex. le cache d'une librairie de fetch) : un miroir local à rafraîchir
• État UI local (état de composant) : ce que l'utilisateur fait en ce moment
• URL (chemin, query params, hash) : état que l'on peut partager, bookmarker et restaurer

Chacun de ces endroits est un propriétaire valide pour une partie de l'état. Le problème commence quand ils veulent tous posséder la même donnée.

Comment la duplication arrive

Un pattern courant : récupérer des données serveur, puis les copier dans l'état local « pour pouvoir les éditer ». Par exemple, vous chargez un profil utilisateur et faites formState = userFromApi. Plus tard, le serveur refait un fetch (ou un autre onglet met à jour l'enregistrement) et vous vous retrouvez avec deux versions : le cache dit une chose, votre formulaire en affiche une autre.

La duplication s'immisce aussi via des transformations « utiles » : stocker à la fois items et itemsCount, ou stocker selectedId et selectedItem.

Symptômes reconnaissables

Quand il y a plusieurs sources de vérité, les bugs ressemblent souvent à :

• « Ça marche seulement sur cet écran. »
• L'UI est incohérente après une navigation ou un rechargement.
• Les données ont l'air correctes dans un composant mais obsolètes dans un autre.
• L'enregistrement réussit, mais la vue liste ne se met pas à jour (ou se met à jour deux fois).

Règle empirique

Pour chaque morceau d'état, choisissez un seul propriétaire—l'endroit où les mises à jour sont effectuées—et traitez tout le reste comme une projection (lecture seule, dérivée ou synchronisée dans une seule direction). Si vous ne pouvez pas pointer le propriétaire, vous stockez probablement la même vérité deux fois.

Le travail asynchrone et les effets de bord compliquent l'état

Beaucoup d'état frontend semble simple parce qu'il est synchrone : un utilisateur clique, vous définissez une valeur, l'UI se met à jour. Les effets de bord cassent cette histoire pas à pas.

Qu'est‑ce qui compte comme effet de bord ?

Les effets de bord sont toutes les actions qui sortent du modèle pur « render basé sur des données » :

• Appels réseau (fetch, sauvegarde, retry)
• Timers et debounce (setTimeout, intervals)
• Abonnements (web sockets, listeners)
• Stockage navigateur (localStorage/sessionStorage)

Chacun peut se déclencher plus tard, échouer de façon inattendue ou s'exécuter plusieurs fois.

Pourquoi l'état asynchrone est plus difficile que le synchrone

Les mises à jour asynchrones introduisent le temps comme variable. Vous ne raisonnez plus en termes de « ce qui s'est passé », mais de « ce qui peut encore être en cours ». Deux requêtes peuvent se chevaucher. Une réponse lente peut arriver après une plus récente. Un composant peut être démonté alors qu'un callback asynchrone tente encore de mettre à jour l'état.

C'est pourquoi les bugs ressemblent souvent à :

• Des flags de chargement bloqués indéfiniment (le chemin d'erreur ne les nettoie pas ou la requête a été annulée)
• L'UI clignote avec d'anciennes données (valeur en cache obsolète affichée comme « finale »)
• Des réponses dépassées qui écrasent des plus récentes (la requête A se termine après la requête B)

Une stratégie simple : modéliser explicitement la requête

Au lieu de parsemer des booléens comme isLoading partout, traitez le travail asynchrone comme une petite machine à états :

• idle (rien démarré)
• loading (en cours)
• success (données disponibles)
• error (échec capturé)

Suivez les données et le statut ensemble, et conservez un identifiant (comme un id de requête ou une clé de requête) pour pouvoir ignorer les réponses tardives. Cela rend la question « que doit afficher l'UI maintenant ? » une décision claire, pas une supposition.

État UI vs État serveur (ils se ressemblent, mais ne sont pas identiques)

Beaucoup de problèmes d'état commencent par une confusion simple : traiter « ce que l'utilisateur fait maintenant » de la même façon que « ce que le backend dit être vrai ». Les deux changent dans le temps, mais suivent des règles différentes.

État UI : ce que l'interface fait

L'état UI est temporaire et piloté par l'interaction. Il existe pour rendre l'écran comme l'utilisateur s'y attend à cet instant.

Exemples : modales ouvertes/fermées, filtres actifs, brouillon d'un champ de recherche, hover/focus, onglet sélectionné, et UI de pagination (page courante, taille de page, position de scroll).

Cet état est généralement local à une page ou à un arbre de composants. Il peut être réinitialisé lors d'une navigation.

État serveur : ce que vous avez récupéré (et ce qui peut changer ailleurs)

L'état serveur est issu d'une API : profils utilisateurs, listes de produits, permissions, notifications, paramètres sauvegardés. C'est la « vérité distante » qui peut changer sans que votre UI ne fasse quoi que ce soit (quelqu'un d'autre modifie les données, le serveur recalcule, un job en arrière‑plan met à jour).

Parce qu'il est distant, il nécessite aussi des métadonnées : états de chargement/erreur, timestamps de cache, retries et invalidation.

Pourquoi les mélanger cause de la confusion

Si vous stockez des brouillons UI à l'intérieur des données serveur, un refetch peut effacer les modifications locales. Si vous stockez des réponses serveur dans l'état UI sans règles de cache, vous vous battrez contre des données obsolètes, des fetchs en double et des écrans incohérents.

Un mode d'échec courant : l'utilisateur édite un formulaire pendant qu'un refetch de fond arrive et écrase le brouillon.

Une règle pratique

Gérez l'état serveur avec des patterns de cache (fetch, cache, invalider, refetch au focus) et traitez‑le comme partagé et asynchrone.

Gérez l'état UI avec des outils UI (état local de composant, context pour des préoccupations UI réellement partagées) et gardez les brouillons séparés jusqu'à ce que vous décidiez explicitement de les « sauvegarder » sur le serveur.

État dérivé et la règle « ne stockez pas ce que vous pouvez calculer »

L'état dérivé est toute valeur que vous pouvez calculer à partir d'un autre état : un total de panier à partir des lignes, une liste filtrée à partir de la liste d'origine + la requête de recherche, ou un flag canSubmit issu des valeurs de champs et des règles de validation.

Il est tentant de stocker ces valeurs parce que c'est pratique (« je vais aussi garder total en state »). Mais dès que les entrées changent à plusieurs endroits, vous risquez la dérive : le total stocké ne correspond plus aux items, la liste filtrée ne reflète pas la requête actuelle, ou le bouton submit reste désactivé après correction d'une erreur. Ces bugs sont irritants parce que rien n'a l'air « faux » isolément—chaque variable d'état semble valide, simplement incohérente avec le reste.

Préférez les sélecteurs / valeurs calculées

Un pattern plus sûr : stocker la source minimale de vérité, et calculer le reste au moment de la lecture. En React, cela peut être une fonction simple ou un calcul mémoïsé.

const items = useCartItems();
const total = items.reduce((sum, item) =\u003e sum + item.price * item.qty, 0);

const filtered = products.filter(p =\u003e p.name.includes(query));

Dans des apps plus larges, des « selectors » (ou getters calculés) formalisent cette idée : un endroit définit comment dériver total, filteredProducts, visibleTodos, et chaque composant utilise la même logique.

Quand mettre en cache des valeurs dérivées est acceptable

Calculer à chaque rendu est généralement acceptable. Mettez en cache seulement si vous avez mesuré un coût réel : transformations coûteuses, listes gigantesques, ou valeurs dérivées partagées entre de nombreux composants. Utilisez la mémoïsation (useMemo, mémoïsation de selectors) de sorte que les clés de cache soient les vraies entrées—sinon vous revenez à la dérive, juste sous couvert d'optimisation.

Global vs Local : choisir le bon propriétaire

L'état devient pénible quand il n'est pas clair qui possède la donnée.

Ce que signifie « propriété »

Le propriétaire d'un morceau d'état est l'endroit de l'app qui a le droit de le mettre à jour. Les autres parties de l'UI peuvent le lire (via props, context, selectors, etc.), mais elles ne devraient pas le modifier directement.

Une propriété claire répond à deux questions :

• Qui peut mettre à jour cette valeur ? (le propriétaire)
• Qui peut la lire ? (les consommateurs)

Quand ces frontières s'estompent, vous obtenez des mises à jour conflictuelles, des moments « pourquoi ça a changé ? », et des composants difficiles à réutiliser.

État global : pratique, mais le couplage s'insinue

Placer l'état dans un store global (ou un context de haut niveau) peut sembler propre : tout le monde y accède et vous évitez le prop drilling. Le compromis est un couplage involontaire—des écrans non liés dépendent des mêmes valeurs et de petits changements se répercutent dans l'app.

L'état global convient aux choses véritablement transversales, comme la session utilisateur courante, les feature flags applicatifs, ou une file de notifications partagée.

Élever l'état—seulement aussi haut que nécessaire

Un pattern courant est de commencer local et d'« élever » l'état au parent commun le plus proche seulement quand deux parties sœurs doivent se coordonner.

Si un seul composant a besoin de l'état, gardez‑le là. Si plusieurs composants en ont besoin, élevez‑le au plus petit propriétaire partagé. Si de nombreuses parties éloignées en ont besoin, alors envisagez le global.

Une heuristique simple

Gardez l'état proche de l'endroit où il est utilisé sauf si le partage est requis.

Cela rend les composants plus faciles à comprendre, réduit les dépendances accidentelles, et facilite les refactorings futurs parce que moins de parties de l'app peuvent muter la même donnée.

Concurrence, courses et mises à jour hors ordre

Les apps frontend paraissent « mono‑fil », mais la saisie utilisateur, les timers, les animations et les requêtes réseau tournent indépendamment. Cela signifie que plusieurs mises à jour peuvent être en vol en même temps—et elles ne finissent pas nécessairement dans l'ordre où vous les avez lancées.

Quand les mises à jour se percutent

Une collision courante : deux parties de l'UI mettent à jour le même état.

• Une barre de recherche met à jour query à chaque frappe.
• Un menu de filtrage met à jour query (ou la même liste de résultats) quand il change.

Individuellement, chaque mise à jour est correcte. Ensemble, elles peuvent s'écraser l'une l'autre selon le timing. Pire encore, vous pouvez afficher des résultats pour une requête précédente pendant que l'UI montre les nouveaux filtres.

Conditions de course : utilisateurs rapides, réseaux lents

Les conditions de course apparaissent quand vous lancez la requête A, puis rapidement la requête B—mais la requête A revient en dernier.

Exemple : l'utilisateur tape « c », « ca », « cat ». Si la requête « c » est lente et la requête « cat » rapide, l'UI peut afficher d'abord les résultats pour « cat » puis se faire écraser par les résultats obsolètes de « c » quand cette réponse plus ancienne arrive.

Le bug est subtil car tout « a fonctionné »—juste dans le mauvais ordre.

Techniques pour réduire les bugs hors ordre

Vous voulez généralement l'une de ces stratégies :

1. Annuler la requête précédente quand une nouvelle la remplace (p. ex. avec AbortController).
2. Ignorer les réponses obsolètes en vérifiant si la réponse correspond toujours aux entrées les plus récentes.
3. Utiliser des ID de requête / numéros de séquence et n'accepter que la plus récente.

Une approche simple avec ID de requête :

let latestRequestId = 0;

async function fetchResults(query) {
  const requestId = ++latestRequestId;
  const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
  const data = await res.json();

  if (requestId !== latestRequestId) return; // stale response
  setResults(data);
}

Mises à jour optimistes (et leurs écueils)

Les optimistes rendent l'UI instantanée : vous mettez à jour l'écran avant que le serveur confirme. Mais la concurrence peut briser les hypothèses :

• L'utilisateur clique deux fois rapidement sur « J'aime » (j'aime → ne plus aimer), mais les requêtes se résolvent hors ordre.
• Vous décrémentez optimistement l'inventaire, puis un échec ultérieur oblige à un rollback—sauf que l'utilisateur a déjà navigué ou fait d'autres changements.

Pour rendre l'optimisme sûr, il faut en général une règle de réconciliation claire : suivre l'action en attente, appliquer les réponses serveur dans l'ordre, et si vous devez revenir en arrière, revenir à un checkpoint connu (pas « à l'aspect actuel de l'UI »).

Performance : quand les changements d'état coûtent trop cher

Les mises à jour d'état ne sont pas « gratuites ». Quand l'état change, l'app doit déterminer quelles parties de l'écran peuvent être affectées puis effectuer le travail pour refléter la nouvelle réalité : recalculs, re-renders, reformatage, et parfois re-fetch ou re-validation. Si cette chaîne de réaction est plus grosse que nécessaire, l'utilisateur le ressent comme latence, saccades ou boutons qui semblent « réfléchir » avant de répondre.

Pourquoi un petit changement peut sembler lourd

Un toggle unique peut déclencher beaucoup de travail supplémentaire :

• De larges sections de l'UI se re-rendent alors que seul un petit fragment a changé.
• Des listes se redessinent et se remontent, provoquant des saccades dans le scroll.
• Des objets et tableaux sont recréés à chaque mise à jour (« deep churn »), si bien que l'app ne peut pas facilement détecter ce qui a vraiment changé.

Le résultat n'est pas que technique—c'est expérientiel : la frappe est retardée, les animations décrochent, et l'interface perd son côté « réactive » que les utilisateurs associent aux produits soignés.

Pièges de performance courants

Une des causes les plus fréquentes est un état trop large : un objet « panier global » contenant beaucoup d'informations non liées. Mettre à jour un champ fait paraître tout le bucket comme nouveau, donc plus d'UI se réveille que nécessaire.

Un autre piège est de stocker des valeurs calculées et de les mettre à jour manuellement. Cela crée souvent des mises à jour supplémentaires (et du travail UI en plus) juste pour garder tout synchronisé.

Tactiques pour garder l'UI rapide

Divisez l'état en tranches plus petites. Séparez les préoccupations pour qu'un changement de champ de recherche ne rafraîchisse pas toute une page de résultats.

Normalisez les données. Au lieu de stocker plusieurs copies d'un même item, stockez‑le une fois et référencez‑le. Cela réduit les mises à jour répétées et évite les « tempêtes de changements » où une édition force la réécriture de nombreuses copies.

Mémoïsez les valeurs dérivées. Si une valeur se calcule à partir d'un autre état (comme des résultats filtrés), mettez en cache ce calcul pour qu'il ne se réexécute que quand les entrées changent vraiment.

L'objectif : moins de pauses, moins de surprises

Une bonne gestion d'état orientée perf vise surtout la containment : les mises à jour doivent affecter la plus petite zone possible, et le travail coûteux ne doit se faire que lorsque c'est vraiment nécessaire. Quand c'est le cas, les utilisateurs cessent de remarquer le framework et commencent à faire confiance à l'interface.

Déboguer et tester l'état sans conjectures

Les bugs d'état semblent souvent personnels : l'UI est « incorrecte », mais vous ne pouvez pas répondre à la question la plus simple—qui a changé cette valeur et quand ? Si un nombre bascule, une bannière disparaît ou un bouton se désactive, vous avez besoin d'une timeline, pas d'une supposition.

Rendre les changements traçables (pas mystérieux)

Le chemin le plus rapide vers la clarté est un flux de mise à jour prévisible. Que vous utilisiez des reducers, des événements ou un store, visez un pattern où :

• Les changements passent par un petit ensemble d'actions bien nommées (pas des mutations aléatoires)
• Chaque action a une charge claire (setShippingMethod('express'), pas updateStuff)
• Vous pouvez logger les actions et les transitions d'état de façon cohérente

Un logging clair des actions transforme le débogage en « suivre le ticket » plutôt qu'en « fixer le regard sur l'écran ». Même de simples console.log (nom de l'action + champs clés) valent mieux que de reconstituer ce qui s'est passé à partir des symptômes.

Tester la logique là où elle est stable

N'essayez pas de tester chaque re-render. Testez plutôt les parties qui doivent se comporter comme de la logique pure :

• Testez unitairement les reducers / mises à jour d'état : état précédent + action → état suivant attendu
• Testez unitairement les selectors / calculs dérivés : état donné → sortie calculée attendue
• Test d'intégration des flux utilisateurs clés : login → chargement des données → édition → sauvegarde → confirmation visible

Ce mélange attrape à la fois des « bugs mathématiques » et des problèmes de câblage réels.

Ajoutez une instrumentation légère pour les bugs asynchrones

Les soucis asynchrones se cachent dans les interstices. Ajoutez des métadonnées minimales qui rendent les timelines visibles :

• timestamps sur les mises à jour importantes
• ID de requête (attachez l'ID aux actions et aux réponses)

Ainsi, quand une réponse tardive écrase une plus récente, vous pouvez le prouver immédiatement—et le corriger en toute confiance.

Choisir une approche de gestion d'état (sans guerre d'outils)

Choisir un outil d'état est plus simple si vous le considérez comme le résultat de décisions de design, pas comme point de départ. Avant de comparer des librairies, cartographiez vos frontières d'état : qu'est‑ce qui est purement local au composant, qu'est‑ce qui doit être partagé, et qu'est‑ce qui est réellement « données serveur » à récupérer et synchroniser.

Critères de sélection importants

Une façon pragmatique de décider est d'observer quelques contraintes :

• Taille et durée de vie de l'app : un outil interne petit peut rester simple ; un produit pérenne profite de conventions plus strictes
• Habitudes de l'équipe : choisissez quelque chose que l'équipe peut utiliser de façon cohérente (et relire en revue)
• Besoins asynchrones : beaucoup de fetchs, cache, pagination et mutations changent la donne
• Complexité d'état : workflows cross‑page, undo/redo, formulaires multi‑étapes demandent plus de structure

Comparaison haut niveau (sans idéologie)

• Context + hooks : excellent pour l'injection de dépendances et les valeurs partagées peu fréquentes (theme, info d'auth). Ça peut servir pour l'état, mais les mises à jour fréquentes deviennent bruyantes sans patterns supplémentaires.
• Stores style Redux : conventions fortes, mises à jour prédictibles et excellent outillage. Idéal quand vous avez besoin d'une traçabilité claire ou d'une coordination complexe entre features.
• Atom stores (état finement granulaire) : ergonomique pour l'état partagé sans câbler beaucoup de reducers. Souvent plus facile à faire évoluer progressivement.
• Query caches (outils server-state) : spécialisés pour fetch, cache, déduplication, refetch en arrière‑plan et mutations. Ils éliminent une grande partie du glue asynchrone.

Évitez de penser « outil d'abord »

Si vous commencez par « on utilise X partout », vous stockerez les mauvaises choses au mauvais endroit. Commencez par la propriété : qui met à jour cette valeur, qui la lit et que doit-il se passer quand elle change.

Combiner des outils est souvent la meilleure option

Beaucoup d'apps s'en tirent bien avec une librairie server-state pour les données API et une petite solution pour l'état UI (modales, filtres, brouillons de formulaires). L'objectif est la clarté : chaque type d'état vit là où il est le plus simple à raisonner.

Où Koder.ai s'insère

Si vous itérez sur les frontières d'état et les flux asynchrones, Koder.ai peut accélérer la boucle « essayer, observer, affiner ». Comme il génère des frontends React (et des backends Go + PostgreSQL) à partir d'échanges avec un agent, vous pouvez prototyper des modèles de propriété alternatifs (local vs global, cache serveur vs brouillons UI) rapidement, puis garder la version qui reste prévisible.

Deux fonctionnalités pratiques aident lors d'expérimentations d'état : Planning Mode (pour esquisser le modèle d'état avant de construire) et snapshots + rollback (pour tester des refactors comme « supprimer l'état dérivé » ou « introduire des ID de requête » sans perdre une base fonctionnelle).

Checklist pratique pour rendre l'état moins pénible

L'état devient plus simple quand vous le traitez comme un problème de design : décidez qui le possède, ce qu'il représente et comment il change. Utilisez cette checklist quand un composant commence à sembler « mystérieux ».

1) Clarifiez la propriété et la source unique de vérité

Demandez : Quelle partie de l'app est responsable de ces données ? Placez l'état le plus près possible de l'endroit où il est utilisé, et élevez‑le seulement quand plusieurs parties en ont réellement besoin.

• Un propriétaire par morceau d'état.
• Passez les données vers le bas ; envoyez les changements vers le haut via callbacks/événements.
• Si deux endroits peuvent mettre à jour la même valeur, vous n'avez pas de source de vérité—vous avez un conflit en devenir.

2) Évitez la duplication et modélisez les valeurs dérivées

Si vous pouvez calculer quelque chose à partir d'un autre état, ne le stockez pas.

• Stockez les entrées minimales (p. ex. items, filterText).
• Calculez les sorties (p. ex. visibleItems) lors du rendu ou via mémoïsation.

3) Rendre explicites les états asynchrones (ne pas les laisser implicites)

Le travail asynchrone est plus clair quand vous le modélisez directement :

• Préférez une petite forme « request state » : status: 'idle' | 'loading' | 'success' | 'error', plus data et error.
• Traitez « loading » et « error » comme des états UI de première classe, pas comme des booléens dispersés.

4) Surveillez les antipatterns courants

• Copier des props dans l'état « au cas où » (crée de la dérive).
• Globaliser tout (rend les écrans non liés couplés).
• Soupe de booléens (isLoading, isFetching, isSaving, hasLoaded, …) au lieu d'un seul statut.

5) Refactorez par petites étapes sûres

• Séparez l'état mixte : dissociez les préoccupations UI (ouvert/fermé, texte d'entrée) des données serveur.
• Supprimez les valeurs dérivées stockées et calculez‑les à partir de la vraie source.
• Centralisez les effets de bord (fetchs, abonnements) en un seul endroit par feature.

Objectifs pratiques

Visez moins de bugs « comment est‑on arrivé dans cet état ? », des changements qui ne nécessitent pas de toucher cinq fichiers, et un modèle mental où vous pouvez pointer un endroit et dire : ici vit la vérité.