feat: add month dropdown to dashboard Budget vs Actual (#31) #32

Merged

maximus merged 2 commits from fix/simpl-resultat-31-dashboard-month-dropdown into main

2026-03-11 00:12:40 +00:00

medic-bot commented

2026-03-10 18:05:01 +00:00

Collaborator

Summary

Fixes #31

Added a month dropdown selector to the Dashboard's Budget vs Actual section, matching the existing one in Reports
Default value is the last completed month (same logic as Reports)
Reduced the dropdown font size in both Reports and Dashboard for better visual balance

Changes

src/hooks/useDashboard.ts: Added budgetYear/budgetMonth state with last completed month default, SET_BUDGET_MONTH action, setBudgetMonth callback
src/pages/DashboardPage.tsx: Added month dropdown in Budget vs Actual section title with 24-month options
src/pages/ReportsPage.tsx: Reduced dropdown font size from text-2xl to text-lg
Updated both changelogs

## Summary Fixes #31 - Added a month dropdown selector to the Dashboard's Budget vs Actual section, matching the existing one in Reports - Default value is the last completed month (same logic as Reports) - Reduced the dropdown font size in both Reports and Dashboard for better visual balance ## Changes - `src/hooks/useDashboard.ts`: Added `budgetYear`/`budgetMonth` state with last completed month default, `SET_BUDGET_MONTH` action, `setBudgetMonth` callback - `src/pages/DashboardPage.tsx`: Added month dropdown in Budget vs Actual section title with 24-month options - `src/pages/ReportsPage.tsx`: Reduced dropdown font size from `text-2xl` to `text-lg` - Updated both changelogs

medic-bot added 1 commit 2026-03-10 18:05:02 +00:00

feat: add month dropdown to dashboard Budget vs Actual section (#31 ) 7d770f8b66

- Add budgetYear/budgetMonth state to useDashboard hook with last
  completed month as default
- Add month dropdown selector in the dashboard BudgetVsActual title
- Reduce dropdown font size in both Reports and Dashboard pages

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

medic-bot commented

2026-03-10 22:46:02 +00:00

Author

Collaborator

Reviewer automatique — needs-simplify

Le fix répond correctement à l'issue (dropdown mois dans le dashboard, dernier mois complété par défaut, police réduite). Pas de problème bloquant, mais des non-null assertions fragiles et une duplication de logique entre DashboardPage et ReportsPage à factoriser.

Suggestions de simplification

src/hooks/useDashboard.ts : Les paramètres bYear?: number, bMonth?: number sont optionnels dans la signature de fetchData mais utilisés avec des non-null assertions (bYear!, bMonth!). C'est fragile : si un futur appelant omet ces params, ça passera undefined silencieusement à getBudgetVsActualData. Solution : rendre les paramètres obligatoires (supprimer les ?) puisque l'unique appelant les fournit toujours, ou leur donner des valeurs par défaut (bYear = state.budgetYear).
src/pages/DashboardPage.tsx : La logique de génération de monthOptions (Array.from + Intl.DateTimeFormat) est dupliquée quasi à l'identique entre DashboardPage et ReportsPage. Extraire dans un hook partagé (ex: useMonthOptions(language)) ou un utilitaire pour éviter la dérive entre les deux copies.

## Reviewer automatique — needs-simplify Le fix répond correctement à l'issue (dropdown mois dans le dashboard, dernier mois complété par défaut, police réduite). Pas de problème bloquant, mais des non-null assertions fragiles et une duplication de logique entre DashboardPage et ReportsPage à factoriser. ### Suggestions de simplification - **src/hooks/useDashboard.ts** : Les paramètres `bYear?: number, bMonth?: number` sont optionnels dans la signature de `fetchData` mais utilisés avec des non-null assertions (`bYear!`, `bMonth!`). C'est fragile : si un futur appelant omet ces params, ça passera `undefined` silencieusement à `getBudgetVsActualData`. Solution : rendre les paramètres obligatoires (supprimer les `?`) puisque l'unique appelant les fournit toujours, ou leur donner des valeurs par défaut (`bYear = state.budgetYear`). - **src/pages/DashboardPage.tsx** : La logique de génération de `monthOptions` (Array.from + Intl.DateTimeFormat) est dupliquée quasi à l'identique entre DashboardPage et ReportsPage. Extraire dans un hook partagé (ex: `useMonthOptions(language)`) ou un utilitaire pour éviter la dérive entre les deux copies.

maximus added 1 commit 2026-03-10 22:53:38 +00:00

fix: address reviewer feedback (#31 ) 65815ef2e0

- Remove non-null assertions on bYear/bMonth in useDashboard fetchData
  by making parameters required
- Extract shared computeDateRange and buildMonthOptions into
  src/utils/dateRange.ts to eliminate duplication across useDashboard,
  useReports, DashboardPage and ReportsPage

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

medic-bot commented

2026-03-10 22:57:43 +00:00

Author

Collaborator

Reviewer automatique — approved

Le refactoring répond aux commentaires du round 1 : la duplication de computeDateRange et buildMonthOptions est éliminée via un utilitaire partagé (dateRange.ts), les paramètres bYear/bMonth de fetchData sont maintenant requis (plus de non-null assertions fragiles), et le dropdown mois fonctionne correctement dans le dashboard avec le dernier mois complété par défaut.

Suggestions de simplification

src/utils/dateRange.ts : Ce module partagé mériterait des tests unitaires (computeDateRange avec chaque period, buildMonthOptions avec rollover janvier). La logique existait déjà sans tests, mais maintenant qu'elle est centralisée c'est le bon moment pour en ajouter — à faire dans un ticket séparé.

## Reviewer automatique — approved Le refactoring répond aux commentaires du round 1 : la duplication de computeDateRange et buildMonthOptions est éliminée via un utilitaire partagé (dateRange.ts), les paramètres bYear/bMonth de fetchData sont maintenant requis (plus de non-null assertions fragiles), et le dropdown mois fonctionne correctement dans le dashboard avec le dernier mois complété par défaut. ### Suggestions de simplification - **src/utils/dateRange.ts** : Ce module partagé mériterait des tests unitaires (computeDateRange avec chaque period, buildMonthOptions avec rollover janvier). La logique existait déjà sans tests, mais maintenant qu'elle est centralisée c'est le bon moment pour en ajouter — à faire dans un ticket séparé.