Évaluer le besoin d’une bibliothèque de state management
Objectif : Décider à partir de critères observables si le tableau de bord doit adopter une bibliothèque d’état externe.
Quand plusieurs écrans affichent les mêmes dépenses, les mises à jour peuvent devenir difficiles à coordonner. Ajouter une bibliothèque ne règle pourtant pas automatiquement ce problème : cela ajoute aussi des conventions, des dépendances et du code à maintenir. Vous allez examiner des critères concrets pour décider si le tableau de bord en a besoin.
Partir des responsabilités déjà établies
Dans les leçons précédentes, vous avez attribué les dépenses et les catégories à leur contexte, le mois sélectionné à un contexte ciblé et les filtres à leur composant. Le reducer sert à rendre certaines transitions explicites ; il ne vous oblige pas à adopter une bibliothèque externe. Commencez donc par relever les difficultés qui subsistent dans le tableau de bord, sans remplacer une solution qui fonctionne simplement parce qu’une autre est disponible.
Le coût de synchronisation entre écrans désigne ici l’effort nécessaire pour que plusieurs zones restent cohérentes après une action. Par exemple, après l’ajout d’une dépense, le récapitulatif et la liste doivent refléter la même donnée. Si la mise à jour passe déjà par une seule source partagée et que les composants concernés la lisent de façon fiable, ce besoin ne constitue pas à lui seul une raison d’ajouter une bibliothèque.
Distinguer les catégories de données
Une décision utile sépare l’état client, qui décrit les choix et interactions de l’interface, de l’état serveur, qui correspond aux données dont le serveur est la référence. Dans ce projet, un filtre de catégorie ou une recherche en cours relève de l’interface ; les dépenses enregistrées par un service distant relèveraient de l’état serveur si le projet évoluait vers une API. Cette distinction aide à choisir l’outil : une bibliothèque orientée état client ne répond pas nécessairement aux besoins de chargement, de mise en cache et de rafraîchissement de données distantes.
Comparer le bénéfice et le coût
Évaluez d’abord la fréquence des synchronisations : combien d’écrans lisent ou modifient les mêmes informations, et combien de flux doivent rester cohérents ? Comptez ensuite les besoins opérationnels : persistance entre sessions, relecture d’actions, synchronisation entre onglets, gestion de requêtes distantes ou outils de diagnostic. Enfin, estimez le coût d’adoption : dépendance supplémentaire, apprentissage de l’équipe, migration, tests et risque d’introduire une nouvelle source de vérité.
| Observation | Réponse raisonnable |
|---|---|
| Un contexte partagé couvre les quelques composants concernés ; les transitions sont compréhensibles. | Gardez les mécanismes React en place et documentez leurs responsabilités. |
| Plusieurs zones ont besoin des mêmes transitions, et leur orchestration devient difficile à tester ou à faire évoluer. | Comparez une bibliothèque adaptée à l’état client avec le reducer et les contextes déjà utilisés. |
| Les données viennent d’un serveur et nécessitent cache, revalidation ou états de chargement cohérents. | Évaluez un outil conçu pour les données distantes ; ne confondez pas ce besoin avec le stockage de filtres locaux. |
| La difficulté est un état copié à plusieurs endroits ou une responsabilité ambiguë. | Corrigez d’abord l’architecture et la source de vérité ; une bibliothèque peut seulement déplacer le problème. |
Pour le tableau de bord actuel, les filtres restent locaux, tandis que les dépenses, les catégories et le mois ont des portées définies. Si les besoins se limitent à ces interactions, une bibliothèque externe apporterait probablement plus de coût que de valeur. En revanche, si de nombreux écrans doivent appliquer les mêmes transitions complexes, ou si une API devient la source des dépenses et impose une stratégie commune de cache et de rafraîchissement, une évaluation devient pertinente.
Poser une décision vérifiable
Rédigez une décision courte qui nomme le problème, les options comparées et le critère de révision. Par exemple : « Nous conservons le contexte et le reducer : les mêmes données sont déjà partagées entre la liste et le récapitulatif. Nous réévaluerons ce choix si plusieurs écrans indépendants doivent orchestrer les mêmes transitions ou si les dépenses passent par une API avec des besoins de cache. » Cette formulation évite une migration préventive sans empêcher une évolution ultérieure.
À retenir
- Décidez à partir d’un problème observé, pas de la popularité d’un outil.
- Mesurez le nombre d’écrans, de transitions et de besoins de synchronisation concernés.
- Distinguez les interactions de l’interface des données provenant d’un serveur.
- Comparez le bénéfice attendu au coût de migration, de maintenance et de tests.
- Gardez une source de vérité claire et définissez le critère qui vous ferait réexaminer la décision.
Dans la prochaine section, vous apprendrez à repérer les rendus coûteux avant d’envisager une optimisation.