Lars/shinkan-jinkendo
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Widget System aufbauen #15

New Issue
Open
opened 2026-05-07 08:58:25 +02:00 by Lars · 0 comments
Lars commented 2026-05-07 08:58:25 +02:00
Owner
Copy Link

Du arbeitest im Repo shinkan-jinkendo (React-Frontend, bestehende Auth/Rollen).

Ziel: Eine grafisch ansprechende Übersichtsseite (Dashboard) mit einem erweiterbaren Widget-System – orientiert an der Schwester-App Mitai (c:\dev\mitai-jinkendo): dort existiert bereits ein ausgereiftes, nutzerkonfigurierbares Widget-Setup. Bitte kurz die relevante Struktur in Mitai anlesen (Registry, Typen, Layout/Persistence), aber keinen blinden 1:1-Port – Shinkan soll schlank starten, aber architektonisch kompatibel bleiben.

Produktanforderungen

  • Rollenbasierte Widgets: Welche Widgets angezeigt werden, hängt von der Rolle(n) des eingeloggten Users ab (z. B. admin, trainer, … – an bestehendem user.role / Backend ausrichten).
  • Mehrere Rollen: Wenn ein User mehr als einer Rolle zugeordnet ist (oder später mehrere Rollen-Fähigkeiten), soll die Seite die Vereinigung (Union) aller Widgets dieser Rollen zeigen. Doppelte Widget-Typen nur einmal (dedupe nach stabiler widgetId). Falls Konflikte entstehen, dokumentiere die Regel im Code (z. B. erste Rolle gewinnt / feste Priorität).
  • Phase 1 (jetzt): Keine individuelle UI-Konfiguration pro Nutzer (kein Drag-Drop-Speichern, kein „Dashboard anpassen“-Flow nötig).
  • Phase 2 (später, ohne großes Refactoring): Pro Nutzer konfigurierbare Oberfläche (Anordnung ein/aus, optional Reihenfolge) – dafür von vornherein die Architektur vorbereiten:
    • Zentrale Widget-Registry (Registrierung: id, Metadaten, Default für Rollen, Lazy-Load optional).
    • Klare Trennung: „Welche Widgets sind verfügbar + für wen“ vs. „Welche Layout-Overrides hat dieser User“ (auch wenn Overrides initial leer/Default sind).
    • Datenmodell/API so designen, dass später persistierte Layout-JSON (oder ähnlich) nachgerüstet werden kann, ohne die Komponenten umzubauen.

Technische Leitplanken

  • Bestehendes Design-System (app.css, ggf. Karten/Typo) weiterverwenden, Layout modern & aufgeräumt (responsive, mobile zuerst sinnvoll).
  • Keine unnötigen Markdown-Docs im Repo, keine Scope-Creep-Refactors außerhalb Dashboard/Widget-Schicht.
  • Wenn du Backend-Touches brauchst: minimal halten; bevorzugt erst Frontend-only mit Rollen aus Auth-Kontext, es sei denn es gibt schon passende Endpunkte.
  • Nach größeren Änderungen: frontend Build prüfen; falls Playwright-Smoke existiert: Tests anpassen.

Lieferumfang

  1. Architektur kurz im PR-/Commit-Stil erklären (in der Chat-Antwort reicht).
  2. Implementierung: neue/strukturierte Widget-Schicht + ersetzte oder stark überarbeitete Dashboard-Seite.
  3. 1–3 echte Widget-Beispiele (Platzhalter ok, aber visuell stimmig), die zeigen wie Rollen die Menge beeinflussen.
  4. Konkrete Extension-Points für spätere User-Konfiguration (Types/Interfaces + leerer oder default „layout resolver“).

Bitte zuerst kurz im Codebase lesen: Auth/User-Rolle, aktuelles Dashboard.jsx, Navigation. Erst planen und nach Freigabe umsetzen

Du arbeitest im Repo `shinkan-jinkendo` (React-Frontend, bestehende Auth/Rollen). Ziel: Eine grafisch ansprechende **Übersichtsseite (Dashboard)** mit einem **erweiterbaren Widget-System** – orientiert an der Schwester-App Mitai (`c:\dev\mitai-jinkendo`): dort existiert bereits ein ausgereiftes, nutzerkonfigurierbares Widget-Setup. Bitte **kurz die relevante Struktur in Mitai anlesen** (Registry, Typen, Layout/Persistence), aber **keinen blinden 1:1-Port** – Shinkan soll schlank starten, aber **architektonisch kompatibel** bleiben. ### Produktanforderungen - **Rollenbasierte Widgets**: Welche Widgets angezeigt werden, hängt von der **Rolle(n)** des eingeloggten Users ab (z. B. admin, trainer, … – an bestehendem `user.role` / Backend ausrichten). - **Mehrere Rollen**: Wenn ein User **mehr als einer Rolle** zugeordnet ist (oder später mehrere Rollen-Fähigkeiten), soll die Seite die **Vereinigung (Union)** aller Widgets dieser Rollen zeigen. **Doppelte Widget-Typen** nur **einmal** (dedupe nach stabiler `widgetId`). Falls Konflikte entstehen, dokumentiere die Regel im Code (z. B. erste Rolle gewinnt / feste Priorität). - **Phase 1 (jetzt)**: **Keine** individuelle UI-Konfiguration pro Nutzer (kein Drag-Drop-Speichern, kein „Dashboard anpassen“-Flow nötig). - **Phase 2 (später, ohne großes Refactoring)**: Pro Nutzer **konfigurierbare Oberfläche** (Anordnung ein/aus, optional Reihenfolge) – dafür **von vornherein** die Architektur vorbereiten: - Zentrale **Widget-Registry** (Registrierung: `id`, Metadaten, Default für Rollen, Lazy-Load optional). - Klare **Trennung**: „Welche Widgets sind verfügbar + für wen“ vs. „Welche Layout-Overrides hat dieser User“ (auch wenn Overrides initial leer/Default sind). - Datenmodell/API **so designen**, dass später **persistierte Layout-JSON** (oder ähnlich) **nachgerüstet** werden kann, ohne die Komponenten umzubauen. ### Technische Leitplanken - Bestehendes Design-System (`app.css`, ggf. Karten/Typo) **weiterverwenden**, Layout **modern & aufgeräumt** (responsive, mobile zuerst sinnvoll). - **Keine unnötigen Markdown-Docs** im Repo, **keine Scope-Creep-Refactors** außerhalb Dashboard/Widget-Schicht. - Wenn du Backend-Touches brauchst: minimal halten; bevorzugt erst **Frontend-only** mit Rollen aus Auth-Kontext, es sei denn es gibt schon passende Endpunkte. - Nach größeren Änderungen: `frontend` **Build** prüfen; falls Playwright-Smoke existiert: **Tests anpassen**. ### Lieferumfang 1. Architektur kurz im PR-/Commit-Stil erklären (in der Chat-Antwort reicht). 2. Implementierung: neue/strukturierte Widget-Schicht + **ersetzte oder stark überarbeitete** `Dashboard`-Seite. 3. **1–3 echte Widget-Beispiele** (Platzhalter ok, aber visuell stimmig), die zeigen wie Rollen die Menge beeinflussen. 4. Konkrete **Extension-Points** für spätere User-Konfiguration (Types/Interfaces + leerer oder default „layout resolver“). Bitte zuerst kurz im Codebase lesen: Auth/User-Rolle, aktuelles `Dashboard.jsx`, Navigation. Erst planen und nach Freigabe umsetzen
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Lars/shinkan-jinkendo#15
No description provided.
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?