pitfriedrich/chart-app
1
1
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Introduce a data service layer for chart widgets #20

New Issue
Closed
opened 2026-07-28 16:53:22 +00:00 by claude-bot · 1 comment
claude-bot commented 2026-07-28 16:53:22 +00:00
Collaborator
Copy Link
Copy Source

Problem

Chart data is written as literals inline in the views:

lineChart.setData(getTranslation("chart.revenueSeries"),
        List.of(30.0, 40.0, 35.0, 50.0, 49.0, 60.0),
        months);

The same list appears in DashboardView and GridStackView, for both the line and the bar chart. Consequences:

  • No way to refresh a widget — the data only exists at construction time.
  • No way to test data logic independently of the Vaadin component tree.
  • No place to hang a date range, a filter, or a real backend later.

Proposal

Add a small service layer between views and charts, e.g.:

  • A ChartSeries / ChartDataSet record holding series name, values and category labels.
  • A ChartDataService interface (Spring bean) with methods like revenueByMonth(...), revenueByRegion(...).
  • A dummy in-memory implementation that returns today's hardcoded numbers, so nothing changes visually.
  • Widgets pull from the service instead of holding literals.

Keep it deliberately thin — the point is the seam, not a persistence layer.

Why

Prerequisite for live refresh, the global filter bar, and per-widget refresh actions. All three need "ask for data again with different parameters", which is impossible while the data is a literal in a constructor.

Acceptance criteria

  • No chart data literals left in views/.
  • Data service is unit-testable without a Vaadin UI, with at least one test.
  • Dashboard renders identically to before.
  • ./mvnw test green.

Scope

Small to medium. Best done right after the dashboard merge, while there is only one set of chart factories to migrate.

## Problem Chart data is written as literals inline in the views: ```java lineChart.setData(getTranslation("chart.revenueSeries"), List.of(30.0, 40.0, 35.0, 50.0, 49.0, 60.0), months); ``` The same list appears in `DashboardView` and `GridStackView`, for both the line and the bar chart. Consequences: - No way to refresh a widget — the data only exists at construction time. - No way to test data logic independently of the Vaadin component tree. - No place to hang a date range, a filter, or a real backend later. ## Proposal Add a small service layer between views and charts, e.g.: - A `ChartSeries` / `ChartDataSet` record holding series name, values and category labels. - A `ChartDataService` interface (Spring bean) with methods like `revenueByMonth(...)`, `revenueByRegion(...)`. - A dummy in-memory implementation that returns today's hardcoded numbers, so nothing changes visually. - Widgets pull from the service instead of holding literals. Keep it deliberately thin — the point is the seam, not a persistence layer. ## Why Prerequisite for live refresh, the global filter bar, and per-widget refresh actions. All three need "ask for data again with different parameters", which is impossible while the data is a literal in a constructor. ## Acceptance criteria - No chart data literals left in `views/`. - Data service is unit-testable without a Vaadin UI, with at least one test. - Dashboard renders identically to before. - `./mvnw test` green. ## Scope Small to medium. Best done right after the dashboard merge, while there is only one set of chart factories to migrate.
claude-bot added the enhancement label 2026-07-28 16:53:22 +00:00
pitfriedrich added the ai-ready label 2026-07-28 17:37:40 +00:00
claude-bot added ai-wip and removed ai-ready labels 2026-07-28 18:08:02 +00:00
claude-bot commented 2026-07-28 18:19:52 +00:00
Author
Collaborator
Copy Link
Copy Source

PR: #34

Neues Package com.example.data mit ChartSeries / KpiData (Records), ChartDataService und einer In-Memory-Implementierung, die genau die bisherigen Zahlen liefert. DashboardView bekommt den Service per Constructor-Injection; die KPI-Kacheln werden aus kpis() gelegt, die Grid-IDs (kpi-revenue …) kommen aus den Daten und bleiben unverändert, gespeicherte Layouts passen also weiterhin.

Design-Entscheidung: Die Records tragen Übersetzungs-Keys (month.jan, kpi.revenueTotal), keinen fertigen Text. Labels sind locale-abhängig und brauchen zum Auflösen eine UI — genau das hätte die Testbarkeit ohne Vaadin (Akzeptanzkriterium) kaputtgemacht. Die View löst die Keys gegen das Bundle auf.

Tests: neuer InMemoryChartDataServiceTest (reines JUnit, kein Spring-Context, keine UI), DashboardViewTest unverändert grün.

Hinweis: DashboardChartPlaywrightTest.dataUpdate_keepsTheRenderedSvgInPlace war bereits auf main rot (mit gestashten Änderungen verifiziert) — seit den KPI-Kacheln ist das erste apex-chart im DOM eine Sparkline ohne xaxis.categories, dadurch war der Achsen-Patch ein struktureller Update und hat das SVG zu Recht neu gezeichnet. Der Test zielt jetzt auf ein Achsen-Chart; Produktionscode dafür unverändert. ./mvnw test ist grün.

PR: https://gitea.pitfriedrich.net/pitfriedrich/chart-app/pulls/34 Neues Package `com.example.data` mit `ChartSeries` / `KpiData` (Records), `ChartDataService` und einer In-Memory-Implementierung, die genau die bisherigen Zahlen liefert. `DashboardView` bekommt den Service per Constructor-Injection; die KPI-Kacheln werden aus `kpis()` gelegt, die Grid-IDs (`kpi-revenue` …) kommen aus den Daten und bleiben unverändert, gespeicherte Layouts passen also weiterhin. Design-Entscheidung: Die Records tragen **Übersetzungs-Keys** (`month.jan`, `kpi.revenueTotal`), keinen fertigen Text. Labels sind locale-abhängig und brauchen zum Auflösen eine `UI` — genau das hätte die Testbarkeit ohne Vaadin (Akzeptanzkriterium) kaputtgemacht. Die View löst die Keys gegen das Bundle auf. Tests: neuer `InMemoryChartDataServiceTest` (reines JUnit, kein Spring-Context, keine UI), `DashboardViewTest` unverändert grün. Hinweis: `DashboardChartPlaywrightTest.dataUpdate_keepsTheRenderedSvgInPlace` war bereits auf `main` rot (mit gestashten Änderungen verifiziert) — seit den KPI-Kacheln ist das erste `apex-chart` im DOM eine Sparkline ohne `xaxis.categories`, dadurch war der Achsen-Patch ein struktureller Update und hat das SVG zu Recht neu gezeichnet. Der Test zielt jetzt auf ein Achsen-Chart; Produktionscode dafür unverändert. `./mvnw test` ist grün.
claude-bot added ai-review and removed ai-wip labels 2026-07-28 18:19:58 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ai-blocked
AI Autofix is blocked - issue needs human
 ai-ready
May be solved by the Autofix loop
 ai-review
Autofix is done, merge ready
 ai-wip
AI Autofix is work-in-progress
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No Label ai-review enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude-bot pitfriedrich
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: pitfriedrich/chart-app#20
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?