mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
9222ae7a1c
meldestelle/docs/90_Reports/2026-04-02_Frontend_Report.md
Stefan Mogeritsch cdadcf4611 docs(reports): add comprehensive status and recommendation reports for key roles 
- Created and saved detailed reports for Frontend, Backend, UI/UX, Architecture, DevOps, QA, Rulebook, and Curation in `docs/90_Reports/`.
- Included prioritized action items, challenges, and next steps across disciplines.
- Addressed documentation gaps and organized steps for improving workflow consistency and validation across the stack.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-02 11:15:38 +02:00

2.2 KiB
Raw Blame History

🎨 [Frontend Expert] Report - 2. April 2026

1. Aktueller Status

In den letzten Tagen lag der Fokus stark auf dem Frontend-Flow, insbesondere auf der Verwaltung von Stammdaten und der Navigation:

  • UI/UX Onboarding: Verbessertes Keyboard-Handling (Tab-Navigation, Enter-Bestätigung) und State-Saving ( rememberSaveable) zwischen Navigationswechseln.
  • Veranstalter & Veranstaltung: Einführung von VeranstalterDetailV2 und VeranstaltungKonfigV2 mit einem sauberen Bestätigungsdialog vor der endgültigen Anlage und korrekter Initialisierung der Event-Datenbank.
  • Profil-Screens (V2): Neue, detailreiche Profil-Ansichten für Reiter, Pferde, Vereine und Funktionäre inkl. Inline-Edit-Dialogen.
  • Navigation: Robuste Back-Stack-Implementierung, die sicherstellt, dass der User korrekt zwischen den Verwaltungsebenen und Profilen navigieren kann.

2. Empfehlungen & Prioritäten

🔴 P1: State-Management refaktorisieren

  • Warum: Aktuell wird viel lokaler State direkt in den V2-Composables gehalten ( var name by remember { mutableStateOf(...) }).
  • Aktion: Konsequente Auslagerung in ViewModels (z. B. VeranstalterViewModel, PferdProfilViewModel), um die Geschäftslogik von der UI zu trennen und die Testbarkeit zu erhöhen.

🟠 P2: Datenbindung & Store-Ablösung

  • Warum: Das Frontend arbeitet momentan stark mit einem Mock-Store (StoreV2).
  • Aktion: Vorbereitung der Ktor-Clients und Repositories, um die tatsächlichen Backend-Endpunkte für echte CRUD-Operationen anzubinden.

🟠 P2: CRUD-Vervollständigung (Delete)

  • Warum: Die "Bearbeiten"-Dialoge sind vorhanden, aber die Lösch-Funktionalität fehlt in den neuen V2-Screens noch weitgehend.
  • Aktion: Implementierung von Lösch-Bestätigungsdialogen und entsprechender Store-/Backend-Integration in allen Profil-Screens.

🟡 P3: UI/UX-Konsistenz & Validierung

  • Warum: Schnelle Iterationen haben teils zu unterschiedlichen Layout-Details oder fehlenden Validierungslogiken in den Edit-Dialogen geführt.
  • Aktion: Formular-Validierung härten (Pflichtfelder markieren, Fehlermeldungen anzeigen) und globales Theming ( Material 3) strikter anwenden.