Lars/mitai-jinkendo
1
0
Fork 0
Code Issues 33 Pull Requests Actions Packages Projects Releases 5 Wiki Activity
22c5f695c9
mitai-jinkendo/docs/issues/issue-fitness-dashboard-layer2b.md
Lars 22c5f695c9
All checks were successful
Deploy Development / deploy (push) Successful in 54s
Details
Build Test / pytest-backend (push) Successful in 4s
Details
Build Test / lint-backend (push) Successful in 0s
Details
Build Test / build-frontend (push) Successful in 16s
Details
refactor: update fitness dashboard integration and terminology 
- Changed the fitness overview path from `/activity` to `/history` and updated related navigation labels to reflect this change.
- Refactored the `FitnessDashboardOverview` component to accept external period control and conditionally display the period selector.
- Integrated the `FitnessDashboardOverview` into the `History` page, enhancing the user experience with consistent terminology and layout.
- Removed the fitness overview from the `ActivityPage` to streamline the interface and focus on activity data collection.
2026-04-19 21:37:12 +02:00

2.3 KiB
Raw Blame History

Fitness-Dashboard (Layer 2b) – Abnahme & technische Zuordnung

Status: umgesetzt (Frontend + Backend)
Bezug: Issue #53 (Phase 0c) – Layer 1 → Layer 2b Bundle → UI nur Darstellung
Stand: 2026-04-19

Ziel

  • Eine Fitness-Übersicht auf /history (Tab Fitness), analog Körper/Ernährung — keine parallelen Berechnungen im Client für Layer 2b.
  • Single Source of Truth: data_layer/activity_metrics (und Scores/Focus wie bei den Platzhaltern), identische Chart-Payloads wie die bestehenden Chart-Endpunkte A1/A2.

Backend

Bestandteil Pfad / Endpoint
Chart-Payloads (A1/A2) build_training_volume_chart_payload, build_training_type_distribution_chart_payload in backend/data_layer/activity_metrics.py
KPI-Kacheln (Struktur für UI) backend/data_layer/fitness_interpretation.py → build_fitness_dashboard_kpi_tiles
Bundle backend/data_layer/fitness_viz.py → get_fitness_dashboard_viz_bundle(profile_id, days)
API GET /api/charts/fitness-dashboard-viz?days=7…9999 in backend/routers/charts.py

Hinweise:

  • days >= 9999 wählt eine lange Historie für die Zusammenfassung (analog Ernährungs-Bundle).
  • calculate_quality_sessions_pct(profile_id, days) unterstützt ein variables Fenster (wird auch vom Quality-Chart genutzt).

Frontend

Bestandteil Pfad
API-Client getFitnessDashboardViz(days) in frontend/src/utils/api.js
Darstellung frontend/src/components/FitnessDashboardOverview.jsx
Einbindung frontend/src/pages/History.jsx → ActivitySection (gemeinsamer PeriodSelector wie die Liste darunter)
Erfassung /activity bleibt reine Erfassung; Capture-Hub-Label Aktivität

Erweiterungen (optional)

  • Weitere Charts aus A3–A8 ins Bundle ziehen (weiterhin nur Payload-Referenz, keine Duplikat-Logik im Router).
  • Gitea-Issue anlegen/verknüpfen, falls formale Nachverfolgung gewünscht.

Abnahme-Checkliste

  • Bundle liefert has_activity_entries, summary, kpi_tiles, charts.training_volume, charts.training_type_distribution, meta.
  • Keine clientseitige Neuberechnung der KPIs aus Rohlisten.
  • /api/charts/training-volume und /training-type-distribution nutzen dieselben Builder wie das Bundle.