Aus #85, Refactoring-Runde 5 („Die großen Dateien (GraphCanvas 1379 Zeilen, SceneViewport 1126, PhysicsSystem 919) sind nicht zerlegt — das wäre je ein eigenes Issue.“).
Befund
Seitdem sind sie weiter gewachsen. Zeilen heute (wc -l, Stand 056a622):
Datei
Runde 5
heute
src/editor/graph/GraphCanvas.ts
1379
1406
src/editor/viewport/SceneViewport.ts
1126
1223
src/editor/debugHook.ts
—
1088
src/runtime/physics/PhysicsSystem.ts
919
940
Danach folgen VectorArtCanvas (848), serialize.ts (815) und Editor.ts (804).
SceneViewport trägt inzwischen Auswahl und Durchschalten (#203), Kontextmenü (#204), Ziehen, Marquee, drei Tilemap-Werkzeuge und die Kollisionsanzeige.
debugHook ist die Test-Schnittstelle __gm. Jedes Feature hängt dort Hooks an, und sie ist nach Themen gar nicht gegliedert.
Zu bauen (Vorschlag)
Pro Datei ein Commit, Verhalten unverändert, belegt wie in den Refactoring-Runden: Gate grün, betroffene e2e-Module grün, die Hooks unverändert erreichbar.
SceneViewport: Tilemap-Malen (Stroke, Rechteck, Füllen, Pipette) in eine eigene Klasse. Das ist der größte zusammenhängende Block, und er hat eigenen Zustand (stroke).
GraphCanvas: Ziehen/Verbinden und Rahmen (Annotations) in eigene Module, nach dem Muster von dropTarget.ts und framing.ts.
debugHook: nach Themen in Dateien (graph, scene, tabs, vectorart, pixelart …), zusammengesetzt an einer Stelle. tools/ sieht dieselbe Form wie heute.
PhysicsSystem: erst ansehen, ob sich die Schrittlogik (One-Way-Entscheidung, Kontaktereignisse) sauber trennen lässt. Sonst stehen lassen.
Offen (mit Vorschlag)
Ein Issue für alle oder eines pro Datei? Vorschlag: dieses eine, mit einem Commit pro Datei. Bleibt eine Datei bewusst stehen, steht der Grund hier.
Ab welcher Größe gilt eine Datei als zu groß? Vorschlag: keine feste Grenze. Kriterium ist, ob sich ein Block mit eigenem Zustand herauslösen lässt.
Aus #85, Refactoring-Runde 5 („Die großen Dateien (`GraphCanvas` 1379 Zeilen, `SceneViewport` 1126, `PhysicsSystem` 919) sind nicht zerlegt — das wäre je ein eigenes Issue.“).
## Befund
Seitdem sind sie weiter gewachsen. Zeilen heute (`wc -l`, Stand `056a622`):
| Datei | Runde 5 | heute |
|---|---|---|
| `src/editor/graph/GraphCanvas.ts` | 1379 | **1406** |
| `src/editor/viewport/SceneViewport.ts` | 1126 | **1223** |
| `src/editor/debugHook.ts` | — | **1088** |
| `src/runtime/physics/PhysicsSystem.ts` | 919 | **940** |
Danach folgen `VectorArtCanvas` (848), `serialize.ts` (815) und `Editor.ts` (804).
- `SceneViewport` trägt inzwischen Auswahl und Durchschalten (#203), Kontextmenü (#204), Ziehen, Marquee, drei Tilemap-Werkzeuge und die Kollisionsanzeige.
- `debugHook` ist die Test-Schnittstelle `__gm`. Jedes Feature hängt dort Hooks an, und sie ist nach Themen gar nicht gegliedert.
## Zu bauen (Vorschlag)
- **Pro Datei ein Commit, Verhalten unverändert**, belegt wie in den Refactoring-Runden: Gate grün, betroffene e2e-Module grün, die Hooks unverändert erreichbar.
- `SceneViewport`: Tilemap-Malen (Stroke, Rechteck, Füllen, Pipette) in eine eigene Klasse. Das ist der größte zusammenhängende Block, und er hat eigenen Zustand (`stroke`).
- `GraphCanvas`: Ziehen/Verbinden und Rahmen (Annotations) in eigene Module, nach dem Muster von `dropTarget.ts` und `framing.ts`.
- `debugHook`: nach Themen in Dateien (`graph`, `scene`, `tabs`, `vectorart`, `pixelart` …), zusammengesetzt an einer Stelle. `tools/` sieht dieselbe Form wie heute.
- `PhysicsSystem`: erst ansehen, ob sich die Schrittlogik (One-Way-Entscheidung, Kontaktereignisse) sauber trennen lässt. Sonst stehen lassen.
## Offen (mit Vorschlag)
1. **Ein Issue für alle oder eines pro Datei?** Vorschlag: dieses eine, mit einem Commit pro Datei. Bleibt eine Datei bewusst stehen, steht der Grund hier.
2. **Ab welcher Größe gilt eine Datei als zu groß?** Vorschlag: keine feste Grenze. Kriterium ist, ob sich ein Block mit eigenem Zustand herauslösen lässt.
meleki
added the new label 2026-09-23 07:05:35 +02:00
Erledigt in vier Commits, einer pro Datei. Das Verhalten ist gleich geblieben.
Die zwei offenen Fragen hier waren unbeantwortet, genommen habe ich die Vorschläge aus dem Issue: ein Issue mit einem Commit pro Datei. Ob eine Datei zu groß ist, entscheidet die Frage, ob sich ein Block mit eigenem Zustand herauslösen lässt.
One-Way-Regel als reine Funktion passesOneWay, Collider-Geometrie und Pose-Rechnung in bodyGeometry.ts
Scene und Graph: Die neuen Klassen sehen den View nur über eine schmale Schnittstelle (SceneViewHost, GraphCanvasHost) und haben je press/move/release. Der View ruft sie in der alten Reihenfolge auf.
debugHook:__gm hat für tools/ dieselbe Form wie vorher. Im Browser gemessen: 120 Schlüssel oben, 313 Blätter samt Stelligkeit, das JSON vorher und nachher ist byte-gleich.
PhysicsSystem ist nur zum Teil zerlegt. Der Zustand der Schrittlogik (passes, candidates, current, pairColliders) hängt an denselben Engine-Handles wie parts und bodies. Eine eigene Klasse bräuchte fast den ganzen Zustand des Systems als Schnittstelle, deshalb bleibt dieser Teil stehen.
Jeder der vier Commits ist für sich grün, in einem Wegwerf-Worktree Schritt für Schritt geprüft: 2190 → 2192 → 2192 → 2199 Tests.
Gegenproben im Browser (Pinsel, Ecke ziehen, Solid-Umriss, Drop-Ziel, Einrasten, Beads, Rahmen-Auswahl) greifen an den erwarteten Checks.
Zwei Lücken aus der Zeit vor dem Umbau geschlossen:
Dass ein gewählter Rahmen auch als gewählt gezeichnet wird, hat kein Check geprüft. Neuer e2e-Check in 36k, gegen die Verbiegung fällt er mit selected: false.
Eine um 90° falsch liegende Kapsel ist keinem Test aufgefallen. Das prüft jetzt tests/core/body-geometry.test.ts.
Neue Unit-Tests: 2 für BeadClock, 5 für die One-Way-Regel ohne Engine, 2 für die Kapsel.
Check-Summe: CI hat an 487b3aa 1313 gemessen, mit dem neuen Check sind es 1314 (gerechnet).
Funde nebenbei
PaintStroke.holderId wurde geschrieben, aber nie gelesen. Das Feld ist weg.
Im alten debugHook stand der Kommentar zu vectorArt über pixelArt, und zu assetRow gab es einen verwaisten Doppelkommentar. Behoben.
Wiki: Architecture um die neuen Bausteine ergänzt, Development mit der neuen Check-Summe (Wiki-Commit 1fbbc42).
Erledigt in vier Commits, einer pro Datei. Das Verhalten ist gleich geblieben.
Die zwei offenen Fragen hier waren unbeantwortet, genommen habe ich die Vorschläge aus dem Issue: ein Issue mit einem Commit pro Datei. Ob eine Datei zu groß ist, entscheidet die Frage, ob sich ein Block mit eigenem Zustand herauslösen lässt.
| Commit | Datei | vorher | jetzt | herausgelöst |
|---|---|---|---|---|
| e31db3d | `SceneViewport` | 1216 | **668** | Tilemap-Malen, Polygon-Ecken, Solid-Umrisse der Tilemaps |
| b830f9c | `GraphCanvas` | 1406 | **1019** | Verbinden (Pin ziehen, Palette beim Loslassen ins Leere, „Make transition“), Ziehen von Nodes und Rahmen, Rahmen-Ebene, `BeadClock` |
| ed29b2f | `debugHook` | 1097 | **86** | 7 Dateien nach Thema in `src/editor/debug/`, `debugHook.ts` setzt sie nur noch zusammen |
| f9d5e8b | `PhysicsSystem` | 940 | **820** | One-Way-Regel als reine Funktion `passesOneWay`, Collider-Geometrie und Pose-Rechnung in `bodyGeometry.ts` |
- **Scene und Graph:** Die neuen Klassen sehen den View nur über eine schmale Schnittstelle (`SceneViewHost`, `GraphCanvasHost`) und haben je `press`/`move`/`release`. Der View ruft sie in der alten Reihenfolge auf.
- **`debugHook`:** `__gm` hat für `tools/` dieselbe Form wie vorher. Im Browser gemessen: 120 Schlüssel oben, 313 Blätter samt Stelligkeit, das JSON vorher und nachher ist byte-gleich.
- **`PhysicsSystem` ist nur zum Teil zerlegt.** Der Zustand der Schrittlogik (`passes`, `candidates`, `current`, `pairColliders`) hängt an denselben Engine-Handles wie `parts` und `bodies`. Eine eigene Klasse bräuchte fast den ganzen Zustand des Systems als Schnittstelle, deshalb bleibt dieser Teil stehen.
## Tests
```
./check.sh → 146 Files, 2199 Tests, CHECK EXIT 0 (vorher 145 / 2190)
e2e 1-16,29,31,39-43 (nur Scene) → ALL PASSED – 679 checks
e2e 1-28,31,36 (+ Graph) → ALL PASSED – 932 checks
e2e 1-16,37,39-43,47,48 (+ Hooks) → ALL PASSED – 734 checks
e2e 1-28,31,36,39-43 (Endstand) → ALL PASSED – 1060 checks
```
- Jeder der vier Commits ist für sich grün, in einem Wegwerf-Worktree Schritt für Schritt geprüft: 2190 → 2192 → 2192 → 2199 Tests.
- Gegenproben im Browser (Pinsel, Ecke ziehen, Solid-Umriss, Drop-Ziel, Einrasten, Beads, Rahmen-Auswahl) greifen an den erwarteten Checks.
- **Zwei Lücken aus der Zeit vor dem Umbau geschlossen:**
- Dass ein gewählter Rahmen auch als gewählt *gezeichnet* wird, hat kein Check geprüft. Neuer e2e-Check in 36k, gegen die Verbiegung fällt er mit `selected: false`.
- Eine um 90° falsch liegende Kapsel ist keinem Test aufgefallen. Das prüft jetzt `tests/core/body-geometry.test.ts`.
- Neue Unit-Tests: 2 für `BeadClock`, 5 für die One-Way-Regel ohne Engine, 2 für die Kapsel.
- Check-Summe: CI hat an `487b3aa` 1313 gemessen, mit dem neuen Check sind es **1314** (gerechnet).
## Funde nebenbei
- `PaintStroke.holderId` wurde geschrieben, aber nie gelesen. Das Feld ist weg.
- Im alten `debugHook` stand der Kommentar zu `vectorArt` über `pixelArt`, und zu `assetRow` gab es einen verwaisten Doppelkommentar. Behoben.
Wiki: *Architecture* um die neuen Bausteine ergänzt, *Development* mit der neuen Check-Summe (Wiki-Commit `1fbbc42`).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Aus #85, Refactoring-Runde 5 („Die großen Dateien (
GraphCanvas1379 Zeilen,SceneViewport1126,PhysicsSystem919) sind nicht zerlegt — das wäre je ein eigenes Issue.“).Befund
Seitdem sind sie weiter gewachsen. Zeilen heute (
wc -l, Stand056a622):src/editor/graph/GraphCanvas.tssrc/editor/viewport/SceneViewport.tssrc/editor/debugHook.tssrc/runtime/physics/PhysicsSystem.tsDanach folgen
VectorArtCanvas(848),serialize.ts(815) undEditor.ts(804).SceneViewportträgt inzwischen Auswahl und Durchschalten (#203), Kontextmenü (#204), Ziehen, Marquee, drei Tilemap-Werkzeuge und die Kollisionsanzeige.debugHookist die Test-Schnittstelle__gm. Jedes Feature hängt dort Hooks an, und sie ist nach Themen gar nicht gegliedert.Zu bauen (Vorschlag)
SceneViewport: Tilemap-Malen (Stroke, Rechteck, Füllen, Pipette) in eine eigene Klasse. Das ist der größte zusammenhängende Block, und er hat eigenen Zustand (stroke).GraphCanvas: Ziehen/Verbinden und Rahmen (Annotations) in eigene Module, nach dem Muster vondropTarget.tsundframing.ts.debugHook: nach Themen in Dateien (graph,scene,tabs,vectorart,pixelart…), zusammengesetzt an einer Stelle.tools/sieht dieselbe Form wie heute.PhysicsSystem: erst ansehen, ob sich die Schrittlogik (One-Way-Entscheidung, Kontaktereignisse) sauber trennen lässt. Sonst stehen lassen.Offen (mit Vorschlag)
Erledigt in vier Commits, einer pro Datei. Das Verhalten ist gleich geblieben.
Die zwei offenen Fragen hier waren unbeantwortet, genommen habe ich die Vorschläge aus dem Issue: ein Issue mit einem Commit pro Datei. Ob eine Datei zu groß ist, entscheidet die Frage, ob sich ein Block mit eigenem Zustand herauslösen lässt.
e31db3dSceneViewportb830f9cGraphCanvasBeadClocked29b2fdebugHooksrc/editor/debug/,debugHook.tssetzt sie nur noch zusammenf9d5e8bPhysicsSystempassesOneWay, Collider-Geometrie und Pose-Rechnung inbodyGeometry.tsSceneViewHost,GraphCanvasHost) und haben jepress/move/release. Der View ruft sie in der alten Reihenfolge auf.debugHook:__gmhat fürtools/dieselbe Form wie vorher. Im Browser gemessen: 120 Schlüssel oben, 313 Blätter samt Stelligkeit, das JSON vorher und nachher ist byte-gleich.PhysicsSystemist nur zum Teil zerlegt. Der Zustand der Schrittlogik (passes,candidates,current,pairColliders) hängt an denselben Engine-Handles wiepartsundbodies. Eine eigene Klasse bräuchte fast den ganzen Zustand des Systems als Schnittstelle, deshalb bleibt dieser Teil stehen.Tests
selected: false.tests/core/body-geometry.test.ts.BeadClock, 5 für die One-Way-Regel ohne Engine, 2 für die Kapsel.487b3aa1313 gemessen, mit dem neuen Check sind es 1314 (gerechnet).Funde nebenbei
PaintStroke.holderIdwurde geschrieben, aber nie gelesen. Das Feld ist weg.debugHookstand der Kommentar zuvectorArtüberpixelArt, und zuassetRowgab es einen verwaisten Doppelkommentar. Behoben.Wiki: Architecture um die neuen Bausteine ergänzt, Development mit der neuen Check-Summe (Wiki-Commit
1fbbc42).