Files

T

karim ca859c4aa4 Browser-BIM (cad): semantisches Modell, abgeleitete 2D/3D-Sichten, Zeichenwerkzeuge

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.

2026-06-30 20:52:27 +02:00

3.0 KiB

Raw Blame History

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)

Store + Slices anlegen, Projekt-State + Mutationen aus App.tsx hierher ziehen (1:1, gleiche Logik inkl. recomputeFloorElevations, refs-aware delete).
View-/Selection-/Layout-State in ihre Slices.
Inline-Editoren, Kontextmenü-Builder, View-Routing in src/editors/,src/menus/,src/views/ extrahieren; sie lesen den Store.
App.tsx auf den Shell reduzieren.
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.

3.0 KiB Raw Blame History