mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5980fbe14f
meldestelle/docs/01_Architecture/Frontend_Komponenten_Roadmap.md
Stefan Mogeritsch 5980fbe14f feat(design-system): add MsFilterBar, MsDataTable, and MsStatusBadge components 
- Implemented MsFilterBar for search, filters, and result count display in list views.
- Introduced MsDataTable for high-density, flexible data visualization with column definitions and alternate row styling.
- Added MsStatusBadge for compact, reusable status indicators with predefined styles (Success, Warning, Error, Info).
- Updated roadmap documentation to mark these components as complete in Phase 2.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-03-31 10:30:43 +02:00

3.2 KiB
Raw Blame History

Frontend-Komponenten Roadmap: Meldestelle-Biest

🏗️ [Lead Architect] | 31. März 2026

Diese Roadmap definiert den Weg von der aktuellen Prototypen-Phase hin zu einer professionellen, konsistenten und performanten Desktop-App. Wir setzen auf einen komponentengetriebenen Ansatz (High-Density UI), um die komplexe Datenverwaltung der Turniermeldestelle effizient abzubilden.

Phase 1: Cleanup & Konsolidierung (Das Fundament) ✅ [ABGESCHLOSSEN]

Bevor wir neue Features bauen, räumen wir die bestehenden Entwürfe auf, um Redundanzen zu vermeiden.

  • Design-System Refactoring:
  • Buttons.kt (DenseButton) in MsButton.kt überführt.
  • Einheitliches Naming: Alle Basis-Komponenten erhalten das Präfix Ms (z.B. MsButton.kt, MsTextField.kt).
  • Redundante Placeholder-Dateien entfernt oder in core/design-system/models/ bündeln.
  • Theme-Check:
  • Sicherstellen, dass alle Farben aus AppColors kommen und nicht hart codiert sind.
  • Typografie-Skalen für High-Density optimieren (LabelSmall für Tabellen).
  • Build-Fixes:
  • Referenzen in ping-feature korrigiert.
  • Referenzen in profile-feature korrigiert.

Phase 2: Daten-Visualisierungs-Komponenten (Das Herzstück) 🔵 [IN ARBEIT]

Turniermanagement bedeutet Arbeit mit Listen. Wir benötigen mächtige, aber kompakte Anzeige-Komponenten.

  • MsDataTable:
  • KMP-kompatible Tabelle mit Sticky Header.
  • Generische Spaltendefinition mit Custom Cell Renderern.
  • Zeilen-Selektion (Einzel-Klick) und gestreiftes Zeilen-Design.
  • MsStatusBadge:
  • Farbliche Kodierung für Nennungsstatus, Lizenzstatus und Prüfungsstatus.
  • Kompaktes Design für die Nutzung innerhalb von Tabellenzellen.
  • MsFilterBar:
  • Suchfeld mit Debounce-Unterstützung (Pattern-basiert).
  • Filter-Chips für schnelle Status-Wechsel.
  • Anzeige der Trefferanzahl (Result Count).

Phase 3: Formular- & Eingabe-System (Die Datenerfassung) ⚪ [ZUKUNFT]

Eingabe von Stammdaten muss schnell und fehlerfrei erfolgen.

  • MsEnumDropdown: Automatisches Mapping von Backend-Enums (ÖTO) auf UI-Auswahl.
  • MsValidationWrapper: Konsistente Anzeige von Fehlern (z.B. "Lizenz für diese Klasse nicht ausreichend").
  • MsSearchableSelect: Für die Verknüpfung von Reitern/Pferden (Autocomplete).

Phase 4: Layout-Patterns & Navigation ⚪ [ZUKUNFT]

Hier bringen wir alles zusammen, bevor das finale Routing implementiert wird.

  • MsMasterDetailLayout: Standard-Layout für alle Stammdaten-Screens.
  • MsActionToolbar: Einheitliche Platzierung von Hauptaktionen (Neu, Speichern, Drucken).
  • MsDialogShell: Standardisierter Rahmen für Modale und Bestätigungsdialoge.

Erfolgs-Metriken

  • Wiederverwendbarkeit: > 80% der UI besteht aus Ms-Komponenten.
  • Density: Alle relevanten Daten eines Reiters/Pferdes sind ohne Scrollen in der Detailansicht sichtbar.
  • Performance: MsDataTable rendert 500+ Zeilen flüssig auf ARM64 (Zora/Mac/Linux).

🧹 [Curator] | 2026-03-31 Dieses Dokument dient als Single Source of Truth für die Frontend-Entwicklung.