dtoro/zui
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactoring

Browse Source
This commit is contained in:
authentik Default Admin
2026-03-12 17:14:33 +01:00
parent e29c5d643c
commit f5b12949d3
6 changed files with 430 additions and 302 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
frontend/docs/IMPROVEMENTS.md
View File

@@ -21,6 +21,16 @@ This doc summarizes recent improvements and suggested next steps for readability
- **rendering.ts** documents the 3-step pipeline, how to add a source/output type, and points to `templateRefs.ts` for shared helpers.
### 4. Rendering signatures (pure module)
- **Added** `lib/graph/renderingSignatures.ts`: `buildConnectedNodeIds`, `buildSourceSignatures` (connectedNodeIds + all five signatures + sourceSignature).
- **Refactored** `useRenderingNodeState` to call `buildSourceSignatures` in a single useMemo; hook is shorter and signature logic is testable in isolation.
### 5. Canvas split
- **CanvasContextMenuContent** (`app/canvas/CanvasContextMenuContent.tsx`): context menu content (Create Node grouped by classification, Paste). CanvasPage passes `onCreateNode` and `onPaste`.
- **useCanvasConnectionPath** (`app/canvas/useCanvasConnectionPath.ts`): all connection-path state and callbacks (updating/trigger/paused/error node ids, path node ids, start/end update, add/remove paused/error). CanvasPage calls the hook with `edges` and passes the result into FlowContext.
## Design patterns in use
| Pattern | Where |
@@ -33,15 +43,8 @@ This doc summarizes recent improvements and suggested next steps for readability
## Suggested next steps
1. **CanvasPage** (~950 lines): Split into smaller units, e.g.:
- `useCanvasGraph()` or similar for graph state and connection rules.
- A dedicated component for the context menu (add node, paste, etc.).
- Keeps CanvasPage as composition + layout.
1. **CanvasPage**: Further split optional: e.g. `useCanvasGraph()` for graph state + persistence + connection rules, so the page is mostly composition and layout.
2. **useRenderingNodeState**: Consider extracting:
- Signature building (config/edges/variables/functions/data) into a pure function or small module, e.g. `buildSourceSignatures(nodes, edges, id, incomingIds, getConfigContent)`.
- Makes the hook easier to read and the logic testable in isolation.
2. **Config types**: If you add more output types (e.g. Mermaid), consider a small registry API (`registerConfigType`, `getConfigType`) instead of a single large `CONFIG_TYPES` array.
3. **Config types**: If you add more output types (e.g. Mermaid), consider a small registry API (`registerConfigType`, `getConfigType`) instead of a single large `CONFIG_TYPES` array, so extensions can register without editing the core list.
4. **Consistent node shape in lib**: `templateRefs` uses `EdgeLike` / `NodeLike`; other graph code uses inline `{ source, target }` or `nodes as ...`. You could standardize on the same minimal types where appropriate to reduce casts.
3. **Consistent node shape in lib**: `templateRefs` and `renderingSignatures` use `EdgeLike` / `NodeLike`; standardize where appropriate to reduce casts.