Stefan Mogeritsch 7bbb991e69 refactor(desktop, core): Onboarding zu DeviceInitialization umbenannt, Navigation und Screens angepasst

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>

2026-04-18 11:10:05 +02:00

2.3 KiB

Raw Blame History

ADR-0024: Plug-and-Play Komponenten-Architektur für Multiplattform-Stabilität

Status

Akzeptiert

Kontext

Das Projekt "Meldestelle" strebt eine Multiplattform-Anwendung (KMP) für Desktop, Web und Mobile an. Jüngste Stabilitätsprobleme im Frontend (der "Kartenhaus-Effekt") wurden durch eng gekoppelte UI-Komponenten und Screens verursacht. Änderungen in einem Bereich (z.B. Routing) führten zu Zusammenbrüchen in nicht verwandten Features.

Entscheidung

Wir führen eine "Plug-and-Play"-Architektur für alle Frontend-Komponenten ein. Diese Strategie stellt sicher, dass Komponenten in sich geschlossen, wiederverwendbar und unabhängig von ihrer Platzierung in der UI-Hierarchie sind.

1. Atomic Design Ebenen

Atome/Moleküle (core:design-system): Zustandlose, rein visuelle Elemente (z.B. MsButton, MsCard).
Plug-and-Play Organismen (features:* oder core:auth): Fachlich orientierte Komponenten (z.B. AuthStatusCard, PingActionGroup). Sie MÜSSEN ein ViewModel-Interface oder ein UI-State-Objekt verwenden.
Templates/Screens: Layout-orientierte Kompositionen von Organismen. Keine direkte Logik-Implementierung.

2. Striktes State Hoisting

Komponenten erhalten ihren Zustand über ein ViewModel oder ein State-Objekt, das als Parameter übergeben wird.
Sie geben Ereignisse über Lambdas zurück (z.B. onLoginClick: () -> Unit).
Sie dürfen NICHT direkt innerhalb des Composables auf globale Singletons oder Koin zugreifen.

3. Modulare Granularität

Features werden in kleine, testbare Einheiten zerlegt (z.B. PingConsole, PingControls).
Komponenten befinden sich in commonMain, um die Multiplattform-Verfügbarkeit sicherzustellen.

Konsequenzen

Positiv: Erhöhte Stabilität, höhere Wiederverwendbarkeit über Plattformen hinweg, einfacheres Testing, schnellere UI-Experimente.
Negativ: Geringfügiger Overhead bei der Definition von Interfaces und State-Objekten für kleine Komponenten.
Risiko: Over-Engineering einfacher Views. (Gegenmaßnahme: "Gesunder Menschenverstand" bei trivialen 1-Zeilen-Labels).

Einhaltung

Jede neue Feature-Implementierung MUSS gegen dieses ADR geprüft werden.
Bestehende Screens SOLLTEN im Zuge der Wartung in dieses Muster refactored werden.

2.3 KiB Raw Blame History