pict-section-flow 0.0.12 → 0.0.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/launch.json +1 -1
- package/README.md +19 -0
- package/docs/Data_Model.md +158 -0
- package/docs/Event_System.md +156 -0
- package/docs/_sidebar.md +9 -4
- package/docs/card-help/EACH.md +19 -0
- package/docs/card-help/FREAD.md +24 -0
- package/docs/card-help/FWRITE.md +24 -0
- package/docs/card-help/GET.md +22 -0
- package/docs/card-help/ITE.md +23 -0
- package/docs/card-help/LOG.md +23 -0
- package/docs/card-help/NOTE.md +17 -0
- package/docs/card-help/PREV.md +18 -0
- package/docs/card-help/SET.md +27 -0
- package/docs/card-help/SPKL.md +22 -0
- package/docs/card-help/STAT.md +23 -0
- package/docs/card-help/SW.md +25 -0
- package/docs/retold-catalog.json +24 -1
- package/docs/retold-keyword-index.json +6585 -2179
- package/example_applications/simple_cards/package.json +1 -0
- package/example_applications/simple_cards/source/card-help-content.js +16 -0
- package/example_applications/simple_cards/source/cards/FlowCard-Comment.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-DataPreview.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-Each.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-FileRead.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-FileWrite.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-GetValue.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-IfThenElse.js +2 -1
- package/example_applications/simple_cards/source/cards/FlowCard-LogValues.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-SetValue.js +2 -1
- package/example_applications/simple_cards/source/cards/FlowCard-Sparkline.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-StatusMonitor.js +2 -0
- package/example_applications/simple_cards/source/cards/FlowCard-Switch.js +2 -0
- package/package.json +4 -2
- package/scripts/generate-card-help.js +214 -0
- package/source/providers/PictProvider-Flow-CSS.js +3 -5
- package/source/services/PictService-Flow-ConnectionHandleManager.js +3 -0
- package/source/services/PictService-Flow-InteractionManager.js +67 -1
- package/source/services/PictService-Flow-Tether.js +164 -10
- package/source/views/PictView-Flow.js +48 -0
package/.claude/launch.json
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
{
|
|
5
5
|
"name": "simple-cards",
|
|
6
6
|
"runtimeExecutable": "npx",
|
|
7
|
-
"runtimeArgs": ["http-server", "example_applications/simple_cards", "-p", "8085", "-c-1"],
|
|
7
|
+
"runtimeArgs": ["http-server", "example_applications/simple_cards/dist", "-p", "8085", "-c-1"],
|
|
8
8
|
"port": 8085
|
|
9
9
|
}
|
|
10
10
|
]
|
package/README.md
CHANGED
|
@@ -77,6 +77,25 @@ class IfThenElseCard extends libPictFlowCard
|
|
|
77
77
|
}
|
|
78
78
|
```
|
|
79
79
|
|
|
80
|
+
### Card Help from Markdown
|
|
81
|
+
|
|
82
|
+
Store help documentation as markdown files in `docs/card-help/` named by card code (e.g. `ITE.md`, `SET.md`). The build script converts them to HTML and generates a JavaScript module:
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
npm run generate-help
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Reference the generated content in your card constructor:
|
|
89
|
+
|
|
90
|
+
```javascript
|
|
91
|
+
const libCardHelp = require('./card-help-content');
|
|
92
|
+
|
|
93
|
+
// In the constructor options object:
|
|
94
|
+
Help: libCardHelp['ITE'] || false,
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
The `|| false` fallback ensures the build never fails if a markdown file is missing.
|
|
98
|
+
|
|
80
99
|
## Configuration Options
|
|
81
100
|
|
|
82
101
|
| Option | Type | Default | Description |
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
# Data Model
|
|
2
|
+
|
|
3
|
+
The entire flow graph state is represented by a single JSON object called **FlowData**. Every mutation goes through the `DataManager` service and triggers a re-render. This structure is what gets persisted when you call `marshalFromView()` and restored with `marshalToView()`.
|
|
4
|
+
|
|
5
|
+
## FlowData Structure
|
|
6
|
+
|
|
7
|
+
```javascript
|
|
8
|
+
{
|
|
9
|
+
Nodes: [], // Array of node objects
|
|
10
|
+
Connections: [], // Array of connection objects
|
|
11
|
+
OpenPanels: [], // Array of panel objects
|
|
12
|
+
SavedLayouts: [], // Array of layout snapshots
|
|
13
|
+
ViewState:
|
|
14
|
+
{
|
|
15
|
+
PanX: 0, // Viewport horizontal offset
|
|
16
|
+
PanY: 0, // Viewport vertical offset
|
|
17
|
+
Zoom: 1, // Viewport zoom level
|
|
18
|
+
SelectedNodeHash: null,
|
|
19
|
+
SelectedConnectionHash: null,
|
|
20
|
+
SelectedTetherHash: null
|
|
21
|
+
}
|
|
22
|
+
}
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Node
|
|
26
|
+
|
|
27
|
+
Each node represents a discrete operation in the flow graph.
|
|
28
|
+
|
|
29
|
+
```javascript
|
|
30
|
+
{
|
|
31
|
+
Hash: 'abc123', // Unique identifier (auto-generated)
|
|
32
|
+
Type: 'ITE', // Card type code (references NodeTypes)
|
|
33
|
+
X: 200, // Horizontal position in SVG space
|
|
34
|
+
Y: 150, // Vertical position in SVG space
|
|
35
|
+
Width: 200, // Node width in pixels
|
|
36
|
+
Height: 100, // Node height in pixels
|
|
37
|
+
Title: 'If-Then-Else', // Display title on the node
|
|
38
|
+
Ports: // Array of port definitions
|
|
39
|
+
[
|
|
40
|
+
{
|
|
41
|
+
Hash: 'port-1',
|
|
42
|
+
Direction: 'input', // 'input' or 'output'
|
|
43
|
+
Side: 'left', // Port position on node edge
|
|
44
|
+
Label: 'In', // Port label text
|
|
45
|
+
PortType: 'event-in', // Optional type for coloring
|
|
46
|
+
DataType: 'boolean', // Optional data type hint
|
|
47
|
+
MinimumInputCount: 1, // Minimum connections (0 = optional)
|
|
48
|
+
MaximumInputCount: 1 // Maximum connections (-1 = unlimited)
|
|
49
|
+
}
|
|
50
|
+
],
|
|
51
|
+
Style: // Optional per-node style overrides
|
|
52
|
+
{
|
|
53
|
+
BodyFill: '#fef5e7',
|
|
54
|
+
BodyStroke: '#e67e22',
|
|
55
|
+
BodyStrokeWidth: 1,
|
|
56
|
+
TitleBarColor: '#e67e22'
|
|
57
|
+
},
|
|
58
|
+
Data: {} // User-defined payload (card-specific)
|
|
59
|
+
}
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### Port Side Positions
|
|
63
|
+
|
|
64
|
+
Ports can be placed at 12 positions around the node perimeter using a zone system:
|
|
65
|
+
|
|
66
|
+
```
|
|
67
|
+
top-left top top-right
|
|
68
|
+
left-top (body) right-top
|
|
69
|
+
left right
|
|
70
|
+
left-bottom (body) right-bottom
|
|
71
|
+
bottom-left bottom bottom-right
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
The legacy four-value sides (`left`, `right`, `top`, `bottom`) map to the middle zone of each edge.
|
|
75
|
+
|
|
76
|
+
## Connection
|
|
77
|
+
|
|
78
|
+
A connection links an output port on one node to an input port on another.
|
|
79
|
+
|
|
80
|
+
```javascript
|
|
81
|
+
{
|
|
82
|
+
Hash: 'conn-1',
|
|
83
|
+
SourceNodeHash: 'node-a',
|
|
84
|
+
SourcePortHash: 'port-out',
|
|
85
|
+
TargetNodeHash: 'node-b',
|
|
86
|
+
TargetPortHash: 'port-in',
|
|
87
|
+
Data:
|
|
88
|
+
{
|
|
89
|
+
LineMode: 'bezier', // 'bezier' or 'orthogonal'
|
|
90
|
+
HandleCustomized: false, // True if handles have been manually moved
|
|
91
|
+
|
|
92
|
+
// Bezier handles (multi-point curve control)
|
|
93
|
+
BezierHandles: [{ x: 300, y: 175 }],
|
|
94
|
+
|
|
95
|
+
// Orthogonal handles (right-angle path corners)
|
|
96
|
+
OrthoCorner1X: 250,
|
|
97
|
+
OrthoCorner1Y: 150,
|
|
98
|
+
OrthoCorner2X: 350,
|
|
99
|
+
OrthoCorner2Y: 200,
|
|
100
|
+
OrthoMidOffset: 0
|
|
101
|
+
}
|
|
102
|
+
}
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
### Connection Routing
|
|
106
|
+
|
|
107
|
+
Connections support two path modes:
|
|
108
|
+
|
|
109
|
+
- **Bezier** (default) — Smooth curves with one or more control handles. Right-click a connection to add a handle; drag handles to reshape the curve.
|
|
110
|
+
- **Orthogonal** — Right-angle paths with two corner points. Double-click a connection handle to toggle between bezier and orthogonal modes.
|
|
111
|
+
|
|
112
|
+
## Panel
|
|
113
|
+
|
|
114
|
+
An open properties panel associated with a node.
|
|
115
|
+
|
|
116
|
+
```javascript
|
|
117
|
+
{
|
|
118
|
+
Hash: 'panel-1',
|
|
119
|
+
NodeHash: 'node-a', // The node this panel belongs to
|
|
120
|
+
PanelType: 'Form', // 'Template', 'Markdown', 'Form', 'View', or 'Info'
|
|
121
|
+
Title: 'Set Value Properties',
|
|
122
|
+
X: 450, // Panel position in SVG space
|
|
123
|
+
Y: 100,
|
|
124
|
+
Width: 320,
|
|
125
|
+
Height: 200
|
|
126
|
+
}
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
Each panel is rendered as an HTML `foreignObject` inside the SVG, with a tether line connecting it to its parent node. Panels can be dragged, resized, and have tabbed views for Properties, Help, and Appearance.
|
|
130
|
+
|
|
131
|
+
## ViewState
|
|
132
|
+
|
|
133
|
+
Viewport and selection state, persisted with the flow data.
|
|
134
|
+
|
|
135
|
+
```javascript
|
|
136
|
+
{
|
|
137
|
+
PanX: -120, // Horizontal pan offset
|
|
138
|
+
PanY: -50, // Vertical pan offset
|
|
139
|
+
Zoom: 0.85, // Zoom level (0.1 to 5.0)
|
|
140
|
+
SelectedNodeHash: 'node-a', // Currently selected node (null if none)
|
|
141
|
+
SelectedConnectionHash: null, // Currently selected connection
|
|
142
|
+
SelectedTetherHash: null // Currently selected tether line
|
|
143
|
+
}
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
## Relationships
|
|
147
|
+
|
|
148
|
+
```mermaid
|
|
149
|
+
erDiagram
|
|
150
|
+
FlowData ||--o{ Node : contains
|
|
151
|
+
FlowData ||--o{ Connection : contains
|
|
152
|
+
FlowData ||--o{ Panel : contains
|
|
153
|
+
FlowData ||--|| ViewState : has
|
|
154
|
+
Node ||--o{ Port : has
|
|
155
|
+
Connection }o--|| Port : "source port"
|
|
156
|
+
Connection }o--|| Port : "target port"
|
|
157
|
+
Panel }o--|| Node : "attached to"
|
|
158
|
+
```
|
|
@@ -0,0 +1,156 @@
|
|
|
1
|
+
# Event System
|
|
2
|
+
|
|
3
|
+
Pict-Section-Flow exposes a rich event system through the `EventHandlerProvider`. Register handlers to react to user interactions, data changes, and lifecycle events without modifying core code.
|
|
4
|
+
|
|
5
|
+
## Registering Handlers
|
|
6
|
+
|
|
7
|
+
```javascript
|
|
8
|
+
let tmpFlowView = _Pict.views.MyFlow;
|
|
9
|
+
|
|
10
|
+
// Register a named handler
|
|
11
|
+
tmpFlowView._EventHandlerProvider.registerHandler(
|
|
12
|
+
'onNodeAdded',
|
|
13
|
+
(pNode, pFlowView) =>
|
|
14
|
+
{
|
|
15
|
+
console.log('Node added:', pNode.Title);
|
|
16
|
+
},
|
|
17
|
+
'my-node-handler'
|
|
18
|
+
);
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
The third parameter is an optional handler hash for later removal. If omitted, a unique hash is generated and returned.
|
|
22
|
+
|
|
23
|
+
## Removing Handlers
|
|
24
|
+
|
|
25
|
+
```javascript
|
|
26
|
+
// Remove a specific handler
|
|
27
|
+
tmpFlowView._EventHandlerProvider.removeHandler('onNodeAdded', 'my-node-handler');
|
|
28
|
+
|
|
29
|
+
// Remove all handlers for an event
|
|
30
|
+
tmpFlowView._EventHandlerProvider.removeAllHandlers('onNodeAdded');
|
|
31
|
+
|
|
32
|
+
// Remove all handlers for all events
|
|
33
|
+
tmpFlowView._EventHandlerProvider.removeAllHandlers();
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## Querying Handlers
|
|
37
|
+
|
|
38
|
+
```javascript
|
|
39
|
+
// Check if any handlers are registered
|
|
40
|
+
tmpFlowView._EventHandlerProvider.hasHandlers('onNodeAdded'); // true or false
|
|
41
|
+
|
|
42
|
+
// Count registered handlers
|
|
43
|
+
tmpFlowView._EventHandlerProvider.getHandlerCount('onNodeAdded'); // number
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
## Available Events
|
|
47
|
+
|
|
48
|
+
### Node Events
|
|
49
|
+
|
|
50
|
+
| Event | Payload | Description |
|
|
51
|
+
|-------|---------|-------------|
|
|
52
|
+
| `onNodeSelected` | `node` or `null` | A node was selected or deselected |
|
|
53
|
+
| `onNodeAdded` | `node` | A new node was created |
|
|
54
|
+
| `onNodeRemoved` | `node` | A node was deleted |
|
|
55
|
+
| `onNodeMoved` | `node` | A node was dragged to a new position |
|
|
56
|
+
|
|
57
|
+
### Connection Events
|
|
58
|
+
|
|
59
|
+
| Event | Payload | Description |
|
|
60
|
+
|-------|---------|-------------|
|
|
61
|
+
| `onConnectionSelected` | `connection` | A connection was selected |
|
|
62
|
+
| `onConnectionCreated` | `connection` | A new connection was created between ports |
|
|
63
|
+
| `onConnectionRemoved` | `connection` | A connection was deleted |
|
|
64
|
+
| `onConnectionHandleMoved` | `connection` | A bezier or orthogonal handle was dragged |
|
|
65
|
+
| `onConnectionModeChanged` | `connection` | A connection toggled between bezier and orthogonal |
|
|
66
|
+
|
|
67
|
+
### Panel Events
|
|
68
|
+
|
|
69
|
+
| Event | Payload | Description |
|
|
70
|
+
|-------|---------|-------------|
|
|
71
|
+
| `onPanelOpened` | `panelData` | A properties panel was opened |
|
|
72
|
+
| `onPanelClosed` | `panelData` | A properties panel was closed |
|
|
73
|
+
| `onPanelMoved` | `panelData` | A properties panel was dragged |
|
|
74
|
+
|
|
75
|
+
### Tether Events
|
|
76
|
+
|
|
77
|
+
| Event | Payload | Description |
|
|
78
|
+
|-------|---------|-------------|
|
|
79
|
+
| `onTetherSelected` | `panelData` | A tether line was selected |
|
|
80
|
+
| `onTetherHandleMoved` | `panelData` | A tether handle was dragged |
|
|
81
|
+
| `onTetherModeChanged` | `panelData` | A tether toggled between bezier and orthogonal |
|
|
82
|
+
|
|
83
|
+
### Layout and Meta Events
|
|
84
|
+
|
|
85
|
+
| Event | Payload | Description |
|
|
86
|
+
|-------|---------|-------------|
|
|
87
|
+
| `onLayoutSaved` | `layoutData` | A layout snapshot was saved |
|
|
88
|
+
| `onLayoutRestored` | `layoutData` | A saved layout was restored |
|
|
89
|
+
| `onLayoutDeleted` | `layoutData` | A saved layout was deleted |
|
|
90
|
+
| `onFlowChanged` | `flowData` | Catch-all fired after any data mutation |
|
|
91
|
+
| `onThemeChanged` | `themeKey` | The active theme was switched |
|
|
92
|
+
|
|
93
|
+
## Common Patterns
|
|
94
|
+
|
|
95
|
+
### Undo/Redo Stack
|
|
96
|
+
|
|
97
|
+
```javascript
|
|
98
|
+
let tmpUndoStack = [];
|
|
99
|
+
let tmpRedoStack = [];
|
|
100
|
+
|
|
101
|
+
tmpFlowView._EventHandlerProvider.registerHandler(
|
|
102
|
+
'onFlowChanged',
|
|
103
|
+
(pFlowData) =>
|
|
104
|
+
{
|
|
105
|
+
tmpUndoStack.push(JSON.parse(JSON.stringify(pFlowData)));
|
|
106
|
+
tmpRedoStack = [];
|
|
107
|
+
},
|
|
108
|
+
'undo-tracker'
|
|
109
|
+
);
|
|
110
|
+
|
|
111
|
+
function undo()
|
|
112
|
+
{
|
|
113
|
+
if (tmpUndoStack.length < 2) return;
|
|
114
|
+
tmpRedoStack.push(tmpUndoStack.pop());
|
|
115
|
+
tmpFlowView.setFlowData(tmpUndoStack[tmpUndoStack.length - 1]);
|
|
116
|
+
}
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
### Server Sync
|
|
120
|
+
|
|
121
|
+
```javascript
|
|
122
|
+
tmpFlowView._EventHandlerProvider.registerHandler(
|
|
123
|
+
'onFlowChanged',
|
|
124
|
+
(pFlowData) =>
|
|
125
|
+
{
|
|
126
|
+
fetch('/api/flows/save',
|
|
127
|
+
{
|
|
128
|
+
method: 'POST',
|
|
129
|
+
headers: { 'Content-Type': 'application/json' },
|
|
130
|
+
body: JSON.stringify(pFlowData)
|
|
131
|
+
});
|
|
132
|
+
},
|
|
133
|
+
'server-sync'
|
|
134
|
+
);
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
### Selection Sidebar
|
|
138
|
+
|
|
139
|
+
```javascript
|
|
140
|
+
tmpFlowView._EventHandlerProvider.registerHandler(
|
|
141
|
+
'onNodeSelected',
|
|
142
|
+
(pNode) =>
|
|
143
|
+
{
|
|
144
|
+
if (pNode)
|
|
145
|
+
{
|
|
146
|
+
document.getElementById('sidebar-title').textContent = pNode.Title;
|
|
147
|
+
document.getElementById('sidebar-type').textContent = pNode.Type;
|
|
148
|
+
}
|
|
149
|
+
else
|
|
150
|
+
{
|
|
151
|
+
document.getElementById('sidebar-title').textContent = 'No selection';
|
|
152
|
+
}
|
|
153
|
+
},
|
|
154
|
+
'sidebar-updater'
|
|
155
|
+
);
|
|
156
|
+
```
|
package/docs/_sidebar.md
CHANGED
|
@@ -1,13 +1,18 @@
|
|
|
1
1
|
- Getting Started
|
|
2
2
|
|
|
3
|
-
- [
|
|
4
|
-
- [
|
|
5
|
-
- [
|
|
3
|
+
- [Overview](/)
|
|
4
|
+
- [Quick Start](Getting_Started.md)
|
|
5
|
+
- [Custom Styling](Custom-Styling.md)
|
|
6
|
+
|
|
7
|
+
- Architecture
|
|
8
|
+
|
|
9
|
+
- [Design Overview](Architecture.md)
|
|
10
|
+
- [Data Model](Data_Model.md)
|
|
11
|
+
- [Event System](Event_System.md)
|
|
6
12
|
|
|
7
13
|
- Reference
|
|
8
14
|
|
|
9
15
|
- [Implementation Reference](Implementation_Reference.md)
|
|
10
|
-
- [Custom Styling](Custom-Styling.md)
|
|
11
16
|
- [Layout Persistence](Layout_Persistence.md)
|
|
12
17
|
|
|
13
18
|
- API — Data Management
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Each (Loop Iterator)
|
|
2
|
+
|
|
3
|
+
The **Each** node iterates over a collection, executing connected downstream nodes once for each item. When iteration completes, the **Done** output fires.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **Collection** (input) — an array or iterable to loop over
|
|
8
|
+
- **Item** (output) — fires once per element with the current item
|
|
9
|
+
- **Done** (output) — fires after all items have been processed
|
|
10
|
+
|
|
11
|
+
## Behavior
|
|
12
|
+
|
|
13
|
+
When a collection arrives at the input port, the Each node processes items sequentially. For every element in the collection, the **Item** output is activated with the current element as the payload. After the final element is processed, the **Done** output fires to signal completion.
|
|
14
|
+
|
|
15
|
+
## Tips
|
|
16
|
+
|
|
17
|
+
- Connect **Item** to a processing chain and **Done** to continuation logic
|
|
18
|
+
- Nested loops are supported by chaining multiple Each nodes
|
|
19
|
+
- Empty collections skip directly to the **Done** output
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# File Read
|
|
2
|
+
|
|
3
|
+
The **File Read** node reads the contents of a file from the filesystem and outputs the data.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **Path** (input) — the filesystem path to read
|
|
8
|
+
- **Data** (output) — the file contents on success
|
|
9
|
+
- **Error** (output) — fires if the read operation fails
|
|
10
|
+
|
|
11
|
+
## Properties
|
|
12
|
+
|
|
13
|
+
- **FilePath** — the path to the file to read
|
|
14
|
+
- **Encoding** — character encoding for text files (e.g. `utf8`, `ascii`)
|
|
15
|
+
|
|
16
|
+
## Behavior
|
|
17
|
+
|
|
18
|
+
When triggered, the node reads the file at the configured path. On success, the raw file contents are emitted from the **Data** output. If the file does not exist or cannot be read, the **Error** output fires with a descriptive error message.
|
|
19
|
+
|
|
20
|
+
## Tips
|
|
21
|
+
|
|
22
|
+
- Use a Get Value node upstream to dynamically set the file path
|
|
23
|
+
- Pair with a Data Preview node to inspect the file contents
|
|
24
|
+
- Connect the **Error** output to logging or notification nodes for robust error handling
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# File Write
|
|
2
|
+
|
|
3
|
+
The **File Write** node writes data to a file on the filesystem.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **Path** (input) — the destination filesystem path
|
|
8
|
+
- **Data** (input) — the content to write
|
|
9
|
+
- **Done** (output) — fires after a successful write
|
|
10
|
+
- **Error** (output) — fires if the write operation fails
|
|
11
|
+
|
|
12
|
+
## Behavior
|
|
13
|
+
|
|
14
|
+
When both inputs are satisfied, the node writes the provided data to the specified file path. On success the **Done** output fires. If the write fails (for example due to permissions or a missing directory), the **Error** output fires with a descriptive error message.
|
|
15
|
+
|
|
16
|
+
## Properties Panel
|
|
17
|
+
|
|
18
|
+
The properties panel shows a View-based info panel with details about the configured file path and write options.
|
|
19
|
+
|
|
20
|
+
## Tips
|
|
21
|
+
|
|
22
|
+
- Directories in the path are not created automatically — ensure they exist before writing
|
|
23
|
+
- Combine with a Set Value node to format data before writing
|
|
24
|
+
- Connect the **Error** output to a Log Values node to capture write failures
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Get Value
|
|
2
|
+
|
|
3
|
+
The **Get Value** node retrieves a named variable from the flow context and emits its current value.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **In** (input) — trigger to read the value
|
|
8
|
+
- **Value** (output) — the retrieved value
|
|
9
|
+
|
|
10
|
+
## Behavior
|
|
11
|
+
|
|
12
|
+
When triggered, the node looks up a named key in the flow context and emits the stored value from the **Value** output. If the key does not exist, the output value is `undefined`.
|
|
13
|
+
|
|
14
|
+
## Usage
|
|
15
|
+
|
|
16
|
+
Pair with a **Set Value** node to establish a read/write variable pattern. The Set Value node stores a value under a named key; the Get Value node retrieves it downstream.
|
|
17
|
+
|
|
18
|
+
## Tips
|
|
19
|
+
|
|
20
|
+
- Variable names are case-sensitive
|
|
21
|
+
- Use descriptive variable names to keep flows readable
|
|
22
|
+
- Get Value is especially useful for accessing values set in a different branch of the flow
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# If-Then-Else
|
|
2
|
+
|
|
3
|
+
The **If-Then-Else** node evaluates a boolean condition expression and routes the flow to one of two outputs.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **In** (input) — trigger that starts the evaluation
|
|
8
|
+
- **Then** (output) — activated when the condition is **true**
|
|
9
|
+
- **Else** (output) — activated when the condition is **false**
|
|
10
|
+
|
|
11
|
+
## Behavior
|
|
12
|
+
|
|
13
|
+
When the input fires, the node evaluates the configured condition expression against the current flow context. If the expression resolves to a truthy value, the **Then** output is activated. Otherwise, the **Else** output is activated. Exactly one output fires per evaluation.
|
|
14
|
+
|
|
15
|
+
## Configuration
|
|
16
|
+
|
|
17
|
+
Set the condition expression in the node's data properties. The expression is evaluated in the flow context, giving it access to any variables set by upstream Set Value nodes.
|
|
18
|
+
|
|
19
|
+
## Tips
|
|
20
|
+
|
|
21
|
+
- Chain multiple If-Then-Else nodes for complex branching logic
|
|
22
|
+
- Connect the **Else** output to another If-Then-Else to build else-if chains
|
|
23
|
+
- Use descriptive condition expressions to keep the flow self-documenting
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Log Values
|
|
2
|
+
|
|
3
|
+
The **Log Values** node writes incoming data to the console or log output for debugging purposes.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **Values** (input, multi) — accepts one or more connections carrying values to log
|
|
8
|
+
- **Pass** (output) — passes the last received value through unchanged
|
|
9
|
+
|
|
10
|
+
## Properties
|
|
11
|
+
|
|
12
|
+
- **LogLevel** — the severity level for the log entry (e.g. `info`, `warn`, `error`, `trace`)
|
|
13
|
+
- **Format** — an optional format string controlling how values are serialized
|
|
14
|
+
|
|
15
|
+
## Behavior
|
|
16
|
+
|
|
17
|
+
When data arrives at any input connection, the node serializes the value and writes it to the configured log output at the specified log level. The data is then forwarded to the **Pass** output unchanged, so the Log Values node can be inserted inline without disrupting the flow.
|
|
18
|
+
|
|
19
|
+
## Tips
|
|
20
|
+
|
|
21
|
+
- Use multiple input connections to aggregate log output from parallel branches
|
|
22
|
+
- Set the log level to `trace` during development and `warn` in production flows
|
|
23
|
+
- Insert between any two nodes for quick inline debugging
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Comment
|
|
2
|
+
|
|
3
|
+
The **Comment** node is a floating annotation for documenting flow logic. It has no input or output ports and does not participate in data flow execution.
|
|
4
|
+
|
|
5
|
+
## Usage
|
|
6
|
+
|
|
7
|
+
Drop a Comment node anywhere on the canvas to add context, explain design decisions, or leave notes for collaborators. The note text is stored in the node's `Data.NoteText` property and displayed directly in the node body.
|
|
8
|
+
|
|
9
|
+
## Properties
|
|
10
|
+
|
|
11
|
+
- **NoteText** — the annotation content displayed in the node body
|
|
12
|
+
|
|
13
|
+
## Tips
|
|
14
|
+
|
|
15
|
+
- Use comments to explain complex branching logic or non-obvious configuration choices
|
|
16
|
+
- Comment nodes can be freely repositioned without affecting connections
|
|
17
|
+
- Group related comments near the nodes they describe
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
# Data Preview
|
|
2
|
+
|
|
3
|
+
The **Data Preview** node displays a tabular summary of the data flowing through it. Use it as an inline debugger to inspect field names, types, and current values without interrupting the flow.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **Data** (input) — the data object to inspect
|
|
8
|
+
- **Pass** (output) — passes the data through unchanged
|
|
9
|
+
|
|
10
|
+
## Behavior
|
|
11
|
+
|
|
12
|
+
The preview renders a compact table inside the node body showing each field's name, inferred data type, and current value. The node is pass-through: data enters on the left and exits on the right without modification.
|
|
13
|
+
|
|
14
|
+
## Tips
|
|
15
|
+
|
|
16
|
+
- Insert a Data Preview between two nodes to inspect intermediate state
|
|
17
|
+
- The preview updates whenever new data arrives at the input port
|
|
18
|
+
- Useful during development for verifying data transformations
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Set Value
|
|
2
|
+
|
|
3
|
+
The **Set Value** node assigns a value to a named variable in the flow context.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **In** (input) — trigger to perform the assignment
|
|
8
|
+
- **Out** (output) — fires after the value has been set
|
|
9
|
+
|
|
10
|
+
## Properties
|
|
11
|
+
|
|
12
|
+
- **Variable Name** — the key under which the value will be stored
|
|
13
|
+
- **Value Expression** — the expression to evaluate and assign
|
|
14
|
+
|
|
15
|
+
## Behavior
|
|
16
|
+
|
|
17
|
+
When triggered, the node evaluates the **Value Expression** and stores the result under the configured **Variable Name** in the flow context. Downstream nodes can read this value using a **Get Value** node with the same variable name.
|
|
18
|
+
|
|
19
|
+
## Configuration
|
|
20
|
+
|
|
21
|
+
Open the properties panel to configure the variable name and value expression using the built-in form editor.
|
|
22
|
+
|
|
23
|
+
## Tips
|
|
24
|
+
|
|
25
|
+
- Variable names are case-sensitive — use consistent naming conventions
|
|
26
|
+
- Value expressions have access to the current flow context
|
|
27
|
+
- Use Set Value at the beginning of a flow to initialize default variables
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Sparkline
|
|
2
|
+
|
|
3
|
+
The **Sparkline** node renders a live sparkline chart visualizing numeric throughput data directly in the node body.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **Values** (input) — a numeric array or stream of values to plot
|
|
8
|
+
- **Stats** (output) — emits computed statistics (min, max, mean) for the data set
|
|
9
|
+
|
|
10
|
+
## Behavior
|
|
11
|
+
|
|
12
|
+
The node draws a compact line chart inside the node body using a canvas renderer. As new numeric data arrives at the input, the chart updates to reflect the latest values. The filled area under the line and an endpoint dot provide visual emphasis on the current value.
|
|
13
|
+
|
|
14
|
+
## Appearance
|
|
15
|
+
|
|
16
|
+
The chart uses the node's theme color for the line and fill area. The last data point is highlighted with a dot. The sparkline scales automatically to fit the available body area.
|
|
17
|
+
|
|
18
|
+
## Tips
|
|
19
|
+
|
|
20
|
+
- Connect to any node that produces a numeric array for instant visualization
|
|
21
|
+
- Use alongside a Data Preview node for combined visual and tabular inspection
|
|
22
|
+
- The Stats output is useful for feeding threshold values into an If-Then-Else node
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Status Monitor
|
|
2
|
+
|
|
3
|
+
The **Status Monitor** node monitors the health status of upstream services and reports availability.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **Check** (input, multi) — accepts connections from one or more services to monitor
|
|
8
|
+
- **Healthy** (output) — fires when all monitored services report healthy
|
|
9
|
+
- **Degraded** (output) — fires when one or more services report degraded status
|
|
10
|
+
|
|
11
|
+
## Behavior
|
|
12
|
+
|
|
13
|
+
The node body displays a visual health grid showing the status of each monitored service with colored indicators. Green indicates a healthy service; yellow indicates degraded performance. When all services are healthy, the **Healthy** output is activated. If any service reports degraded status, the **Degraded** output fires instead.
|
|
14
|
+
|
|
15
|
+
## Appearance
|
|
16
|
+
|
|
17
|
+
The node body renders SVG status circles labeled with service names (e.g. API, DB, Cache, Queue). Port labels appear on hover for a cleaner default appearance.
|
|
18
|
+
|
|
19
|
+
## Tips
|
|
20
|
+
|
|
21
|
+
- Connect multiple services to the **Check** input to build a comprehensive health dashboard
|
|
22
|
+
- Route the **Degraded** output to notification or alerting nodes
|
|
23
|
+
- Combine with an Each node to check a dynamic list of service endpoints
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Switch
|
|
2
|
+
|
|
3
|
+
The **Switch** node routes execution to one of multiple outputs based on a matching value, similar to a switch/case statement in programming.
|
|
4
|
+
|
|
5
|
+
## Ports
|
|
6
|
+
|
|
7
|
+
- **In** (input) — the value to match against cases
|
|
8
|
+
- **Case A** (output) — fires when the input matches case A
|
|
9
|
+
- **Case B** (output) — fires when the input matches case B
|
|
10
|
+
- **Default** (output) — fires when the input does not match any defined case
|
|
11
|
+
|
|
12
|
+
## Behavior
|
|
13
|
+
|
|
14
|
+
When a value arrives at the input, the node compares it against each configured case. The first matching case's output is activated. If no case matches, the **Default** output fires. Only one output is activated per evaluation.
|
|
15
|
+
|
|
16
|
+
## Configuration
|
|
17
|
+
|
|
18
|
+
Define case match values in the node's data properties. Each case corresponds to one of the named outputs.
|
|
19
|
+
|
|
20
|
+
## Tips
|
|
21
|
+
|
|
22
|
+
- Add more output ports by extending the card definition for additional cases
|
|
23
|
+
- Use the **Default** output as a catch-all for unexpected values
|
|
24
|
+
- Chain a Switch after an If-Then-Else for multi-level routing logic
|
|
25
|
+
- Case matching is based on strict equality
|