ui/client/features/pages-editor/hooks/useSnippetFlow
Cockpit client (features), v0.9. Source: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx.
Type Aliases#
InteractiveFlowNode#
InteractiveFlowNode =
Omit<SnippetFlowNode,"data"> &object
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:32
Type Declaration#
data
data:
InteractiveNodeData
InteractiveNodeData#
InteractiveNodeData =
SnippetFlowNodeData&NodeToolbarActions
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:31
NodeToolbarActions#
NodeToolbarActions =
object
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:23
Ticket F.3 follow-up — the per-node toolbar actions
JsxFlowNode renders, attached to each node's data here (in the hook
layer, which is allowed to hold closures/React state) rather than in
domain's buildSnippetFlowGraph (which stays a pure, closure-free
transform per DOMAIN-001). canRemove is false only for the snippet's
own single root — a hard structural rule, not a runtime edge case — the
other three actions are always offered and rely on the same server-side
validation + inline-error pattern #121 already established (already at
the first/last sibling, or a self-closing element for add-child).
Properties#
canRemove
canRemove:
boolean
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:24
onAddChild
onAddChild: () =>
void
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:28
Returns
void
onMoveDown
onMoveDown: () =>
void
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:27
Returns
void
onMoveUp
onMoveUp: () =>
void
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:26
Returns
void
onRemove
onRemove: () =>
void
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:25
Returns
void
Functions#
useSnippetFlow()#
useSnippetFlow(
snippet,onSnippetChange):object
Defined in: ui/client/features/pages-editor/hooks/useSnippetFlow.tsx:60
Ticket F.1 — derives the visual composer's React Flow
graph by re-parsing the snippet's own live text on every change
(debounced), never a cached/persisted layout — #119's constraint 1. Takes
the exact same snippet string useSnippetEditor already holds as local
state (the text the user is actively editing), not the page-level tree
fetched once when the file was opened, so the canvas always reflects
unsaved in-progress edits too. Called directly from SnippetFlowCanvas — a
component may import a hook; only the hook may reach into domain/services
(COMPONENT-003).
Ticket F.2 follow-up: also exposes rewireWire, called
from the canvas's onReconnect handler when a wire's child-side endpoint is
dragged onto a different sibling. On success the new snippet text is
handed to onSnippetChange (wired to useSnippetEditor's setSnippet +
requestSave, so it lands in the existing diff-preview-before-save flow
rather than a second write path) — on rejection, wireError carries the
inline message and the snippet is left untouched.
Ticket F.3 follow-up: nodes also carry a per-node
toolbar (removeNode/moveNode/addChild, reusing the same
wireError inline-message state #121 introduced rather than a second
one — these are all "snippet edit failed" the same way a bad rewire is).
Parameters#
snippet
string
onSnippetChange
(next) => void
Returns#
object
edges
edges:
SnippetFlowEdge[] =graph.edges
nodes
nodes:
InteractiveFlowNode[]
parseError
parseError:
string|null
rewireWire
rewireWire: (
parentId,propName,fromChildId,toChildId) =>Promise<void>
Parameters
parentId
string
propName
string
fromChildId
string
toChildId
string
Returns
Promise<void>
roots
roots:
PagesEditorNode[]
wireError
wireError:
string|null
References#
SnippetFlowNodeData#
Re-exports SnippetFlowNodeData