Finaliser le projet sans état dupliqué

Un tableau de bord peut sembler correct tout en affichant des chiffres qui ne correspondent plus à ses données. Cela arrive notamment lorsqu’un total, une liste filtrée ou une copie des dépenses est conservé séparément dans un état React. Vous allez faire une revue finale pour vérifier que chaque information affichée a une origine identifiable et reste cohérente après une saisie, un chargement ou un changement de filtre.

Une source canonique pour chaque donnée

Dans ce projet, `App` détient l’état canonique des dépenses et des filtres. Le hook `useDepenses` fournit les dépenses chargées et les états associés au chargement ; l’intégration dans `App` doit faire converger ces données avec celles ajoutées par le formulaire, au lieu de créer une seconde liste indépendante. Les composants reçoivent ensuite leurs données et leurs fonctions par props, comme vous l’avez mis en place lors de la remontée d’état.

Appliquez cette règle à chaque valeur affichée : demandez-vous quel état la produit et si cet état est indispensable. Les dépenses chargées ou ajoutées sont des données canoniques ; les filtres sélectionnés sont également un état utilisateur. En revanche, la liste filtrée, le total mensuel et le nombre de dépenses sont des résultats calculables à partir de ces données : les stocker à leur tour créerait des copies susceptibles de diverger.

Auditer les effets et le flux des données

Reprenez `src/hooks/useDepenses.ts` et `src/services/apiDepenses.ts` pour confirmer que l’effet déclenche le chargement, transmet le signal d’annulation au service et nettoie correctement la requête. Vérifiez que le tableau de dépendances correspond aux valeurs réellement lues par l’effet. Un chargement initial prévu une seule fois ne doit pas être relancé à chaque rendu par l’ajout accidentel d’une dépendance instable ; inversement, une valeur utilisée par un effet ne doit pas être omise si son changement doit modifier le comportement.

Suivez ensuite le trajet des données dans `src/App.tsx` : les dépenses et les filtres partent de leur état détenu par `App`, puis sont transmis aux composants concernés. `ListeDepenses` affiche la collection calculée pour les filtres courants et `RecapitulatifMensuel` reçoit ou calcule les informations du mois sélectionné à partir des mêmes données canoniques. Le formulaire signale une nouvelle dépense à `App` ; il ne conserve pas sa propre copie de la liste.

Confirmer la cohérence par des parcours ciblés

Commencez par relever les dépenses visibles et le récapitulatif du mois sélectionné. Ajoutez ensuite une dépense valide appartenant à ce mois : elle doit apparaître dans la liste concernée et modifier le total ainsi que le nombre affiché. Changez de catégorie, puis de mois ; les résultats doivent changer en fonction des filtres sans que les dépenses d’origine soient modifiées.

Vérifiez aussi les cas qui révèlent souvent une divergence : une liste vide, une erreur de chargement, une catégorie sans résultat et une dépense située dans un autre mois. Dans chacun de ces cas, distinguez l’état de la requête des données disponibles, puis vérifiez que le récapitulatif correspond exactement aux dépenses retenues par ses règles de calcul. Le détail des scénarios de test manuel a été vu dans la leçon précédente ; ici, l’objectif est de relier chaque résultat à sa source d’état.

• Conservez les dépenses et les filtres dans l’état canonique détenu par `App`.
• Calculez la liste filtrée et le récapitulatif depuis ces données, sans les stocker en doublon.
• Vérifiez que le formulaire transmet ses nouvelles données à `App` et que tous les composants affichent la même source.
• Contrôlez les dépendances et le nettoyage des effets sans changer la logique déjà validée.

Le tableau de bord est finalisé lorsque ses parcours restent cohérents et que toute valeur affichée peut être reliée à une seule source d’état ou à un calcul dérivé de celle-ci.