# 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.