karim
ca859c4aa4
Standalone-Browser-Port von DOSSIER. Enthaelt das semantische Modell mit Plan-/3D-Ableitung, Zeichen- und Editierwerkzeuge, Rhino-artiges Befehlssystem, dockbares Panel-System, Resource-Manager, DXF/.lin/.pat-Import, i18n (de/en) sowie Projektdokumentation und Probe-Harness.
53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
# Zustands-Architektur & Code-Aufteilung (App.tsx entschlacken)
|
|
|
|
> Ziel: `App.tsx` von „God-Component" zu dünnem Shell. Globaler Zustand in einen
|
|
> Store, Features in eigene Module → **wartbar + parallel bearbeitbar**.
|
|
|
|
## Problem
|
|
`App.tsx` hält aktuell: Projekt-State, Auswahl, View-State (viewType/detailLevel/
|
|
renderMode/referenceLines/scale/activeLevel), Layout, ALLE Mutations-Handler
|
|
(floors/layers/components/hatches/lineStyles/walls/doors), Kontextmenü-Builder,
|
|
Inline-Editoren, Layout-Menü, View-Routing. → Risiko + Flaschenhals (jedes Feature
|
|
fasst App.tsx an → kein paralleles Arbeiten).
|
|
|
|
## Zielstruktur
|
|
```
|
|
src/state/
|
|
store.ts // Store (Zustand) — kombiniert die Slices, ein useStore-Hook
|
|
projectSlice.ts // project + alle Mutationen (floors, layers, components,
|
|
// hatches, lineStyles, walls, doors) inkl. recompute/refs-aware delete
|
|
selectionSlice.ts // selectedWallIds (+ marquee-Ergebnis)
|
|
viewSlice.ts // viewType, detailLevel, renderMode, referenceLines, activeLevelId, scale
|
|
layoutSlice.ts // wraps src/panels/layout.ts (docks + floating)
|
|
src/views/ // LevelPlanView, PerspectiveView, SectionStub, DrawingView (+ ViewRouter)
|
|
src/editors/ // FloorSettingsEditor, LayerSettingsEditor, … (heute inline in App)
|
|
src/menus/ // layerContextMenu(), levelContextMenu(), planContextMenu() — bauen ContextMenu-Items
|
|
src/ui/ // TopBar, StatusBar, ResourceManager, ContextMenu (bestehen)
|
|
src/panels/ // Docks/Panels (bestehen)
|
|
App.tsx // DÜNN: Store-Provider · TopBar · (Docks + ViewRouter) · StatusBar
|
|
// · Floating-Panels · Ressourcen-Overlay
|
|
```
|
|
|
|
## Store-Wahl: Zustand (empfohlen)
|
|
- Winzige Lib, kein Boilerplate, **Slices** gut teilbar, Selektoren verhindern
|
|
Re-Render-Sturm, kein Prop-Drilling. Passt zu „verschiedene Features = verschiedene
|
|
Slice-Dateien" → Parallelität.
|
|
- Alternative ohne Dependency: Context + useReducer oder `useSyncExternalStore`
|
|
(wie i18n). Mehr Boilerplate; bei der State-Menge ist Zustand ergonomischer.
|
|
- Komponenten: `const walls = useStore(s => s.walls)` / `useStore(s => s.addFloor)`.
|
|
PanelHostContext entfällt (Panels lesen direkt aus dem Store).
|
|
|
|
## Vorgehen (reiner Refactor — Verhalten MUSS identisch bleiben)
|
|
1. Store + Slices anlegen, Projekt-State + Mutationen aus App.tsx hierher ziehen
|
|
(1:1, gleiche Logik inkl. recomputeFloorElevations, refs-aware delete).
|
|
2. View-/Selection-/Layout-State in ihre Slices.
|
|
3. Inline-Editoren, Kontextmenü-Builder, View-Routing in `src/editors/`,`src/menus/`,`src/views/` extrahieren; sie lesen den Store.
|
|
4. App.tsx auf den Shell reduzieren.
|
|
5. Verifizieren: tsc + build + Screenshots — **pixel-/funktionsgleich** zu vorher
|
|
(Auswahl, Massstab, Kontextmenü, Panels, 3D/Plan, i18n). Reiner Umbau, kein
|
|
Feature-Wechsel.
|
|
|
|
## Auszahlung
|
|
- Danach editiert ein Wand-Feature `projectSlice`/`views`, ein Panel-Feature `panels`,
|
|
ein Editor `editors` — **disjunkte Dateien → mehrere Code-Workflows parallel** möglich.
|