@memberjunction/ng-task-graph-editor 0.0.0 → 6.1.0-edge.2
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/LICENSE +7 -0
- package/dist/lib/task-graph-canvas-adapter.d.ts +195 -0
- package/dist/lib/task-graph-canvas-adapter.d.ts.map +1 -0
- package/dist/lib/task-graph-canvas-adapter.js +380 -0
- package/dist/lib/task-graph-canvas-adapter.js.map +1 -0
- package/dist/lib/task-graph-editor-events.d.ts +137 -0
- package/dist/lib/task-graph-editor-events.d.ts.map +1 -0
- package/dist/lib/task-graph-editor-events.js +180 -0
- package/dist/lib/task-graph-editor-events.js.map +1 -0
- package/dist/lib/task-graph-editor.component.d.ts +230 -0
- package/dist/lib/task-graph-editor.component.d.ts.map +1 -0
- package/dist/lib/task-graph-editor.component.js +597 -0
- package/dist/lib/task-graph-editor.component.js.map +1 -0
- package/dist/lib/task-graph-editor.module.d.ts +14 -0
- package/dist/lib/task-graph-editor.module.d.ts.map +1 -0
- package/dist/lib/task-graph-editor.module.js +24 -0
- package/dist/lib/task-graph-editor.module.js.map +1 -0
- package/dist/lib/task-graph-properties-panel.component.d.ts +97 -0
- package/dist/lib/task-graph-properties-panel.component.d.ts.map +1 -0
- package/dist/lib/task-graph-properties-panel.component.js +357 -0
- package/dist/lib/task-graph-properties-panel.component.js.map +1 -0
- package/dist/lib/task-graph-run-view.component.d.ts +113 -0
- package/dist/lib/task-graph-run-view.component.d.ts.map +1 -0
- package/dist/lib/task-graph-run-view.component.js +289 -0
- package/dist/lib/task-graph-run-view.component.js.map +1 -0
- package/dist/lib/task-graph-runtime-source.d.ts +55 -0
- package/dist/lib/task-graph-runtime-source.d.ts.map +1 -0
- package/dist/lib/task-graph-runtime-source.js +66 -0
- package/dist/lib/task-graph-runtime-source.js.map +1 -0
- package/dist/public-api.d.ts +8 -0
- package/dist/public-api.d.ts.map +1 -0
- package/dist/public-api.js +16 -0
- package/dist/public-api.js.map +1 -0
- package/package.json +53 -7
- package/README.md +0 -45
package/LICENSE
ADDED
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
ISC License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2023 MemberJunction
|
|
4
|
+
|
|
5
|
+
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
|
|
6
|
+
|
|
7
|
+
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
|
@@ -0,0 +1,195 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* @fileoverview Projects a `TaskGraphSpec` onto the generic canvas shapes, and back.
|
|
3
|
+
*
|
|
4
|
+
* **Kept pure and separate from the component on purpose.** Everything interesting about rendering a
|
|
5
|
+
* task graph — which node is an entry point, which edge is conditional, how a runtime status maps to
|
|
6
|
+
* a visual one, whether removing a node orphans an edge — is decidable from data alone. Putting it
|
|
7
|
+
* in a component would make it reachable only through a TestBed, and the resulting tests would be
|
|
8
|
+
* about Angular rather than about graphs.
|
|
9
|
+
*
|
|
10
|
+
* **The direction flip, again.** A `TaskGraphSpec` edge points *backwards* (`dependsOn`: "I wait for
|
|
11
|
+
* X"); a canvas connection points *forwards* (source → target). Same edge, opposite authoring
|
|
12
|
+
* convention — the graph is written by whoever knows the prerequisites, the canvas drawn by whoever
|
|
13
|
+
* follows the arrows. This is the second place in the program that inversion appears (Save as
|
|
14
|
+
* Workflow is the first), which is why it is stated rather than left implicit.
|
|
15
|
+
*
|
|
16
|
+
* @module @memberjunction/ng-task-graph-editor
|
|
17
|
+
*/
|
|
18
|
+
import { type TaskGraphSpec, type TaskGraphSpecNode, type TaskGraphDependency } from '@memberjunction/ai-core-plus';
|
|
19
|
+
import type { FlowConnection, FlowNode, FlowNodeStatus, FlowNodeTypeConfig, FlowPosition } from '@memberjunction/ng-flow-editor';
|
|
20
|
+
/**
|
|
21
|
+
* The shapes this canvas can DRAW.
|
|
22
|
+
*
|
|
23
|
+
* Three of the spec's seven `kind`s, and the choice is the canvas's: these are the shapes a person
|
|
24
|
+
* authors. `Prompt`, `ForEach`, `While` and `External` are expressible in the spec but have no
|
|
25
|
+
* authoring affordance here — a palette entry that cannot be configured would be worse than none.
|
|
26
|
+
*
|
|
27
|
+
* **Drawing and RENDERING are different questions**, which this type used to conflate. A run's
|
|
28
|
+
* graph is displayed on the same canvas, and it contains kinds nobody can draw — so mapping them
|
|
29
|
+
* all to `AgentTask` made a fully-configured ForEach render as "AGENT STEP · No agent chosen yet",
|
|
30
|
+
* which is not merely imprecise: it says the step is broken. See {@link TaskGraphRenderType}.
|
|
31
|
+
*/
|
|
32
|
+
export type TaskGraphNodeType = 'AgentTask' | 'ActionTask' | 'HumanTask';
|
|
33
|
+
/**
|
|
34
|
+
* The shapes this canvas can SHOW — a superset of what it can draw.
|
|
35
|
+
*
|
|
36
|
+
* Display-only kinds exist because a task graph is rendered in two places: the editor, where a
|
|
37
|
+
* person builds one, and a run view, where one that already ran is shown. The second must be able
|
|
38
|
+
* to depict every kind the dispatcher can execute, whether or not the palette offers it.
|
|
39
|
+
*/
|
|
40
|
+
export type TaskGraphRenderType = TaskGraphNodeType | 'PromptTask' | 'ForEachTask' | 'WhileTask' | 'ExternalTask';
|
|
41
|
+
/** A palette entry, pinned to one of the three authorable shapes. */
|
|
42
|
+
export type TaskGraphNodeTypeConfig = FlowNodeTypeConfig & {
|
|
43
|
+
Type: TaskGraphNodeType;
|
|
44
|
+
};
|
|
45
|
+
/**
|
|
46
|
+
* Whether a shape is one a person can actually author here.
|
|
47
|
+
*
|
|
48
|
+
* The authoring paths — the palette, `NewTaskFromNodeType`, the properties panel — only handle the
|
|
49
|
+
* three drawable shapes. Rendering handles more. This is the seam between the two, stated as a type
|
|
50
|
+
* guard so the compiler enforces it rather than a cast pretending the distinction does not exist.
|
|
51
|
+
*/
|
|
52
|
+
export declare function IsAuthorableNodeType(type: TaskGraphRenderType): type is TaskGraphNodeType;
|
|
53
|
+
/** A rendering entry — every shape the canvas can depict, authorable or not. */
|
|
54
|
+
export type TaskGraphRenderTypeConfig = FlowNodeTypeConfig & {
|
|
55
|
+
Type: TaskGraphRenderType;
|
|
56
|
+
};
|
|
57
|
+
/** What the palette offers — one entry per assignment shape the spec supports. */
|
|
58
|
+
export declare const TASK_GRAPH_NODE_TYPES: readonly TaskGraphNodeTypeConfig[];
|
|
59
|
+
/**
|
|
60
|
+
* Everything the canvas can DEPICT: the palette, plus the kinds that only ever arrive from a run.
|
|
61
|
+
*
|
|
62
|
+
* Deliberately a superset rather than an extension of the palette — adding these to
|
|
63
|
+
* `TASK_GRAPH_NODE_TYPES` would put un-configurable entries in the authoring toolbox.
|
|
64
|
+
*/
|
|
65
|
+
export declare const TASK_GRAPH_RENDER_TYPES: readonly TaskGraphRenderTypeConfig[];
|
|
66
|
+
/**
|
|
67
|
+
* The config for a node type, or null when the type is not one of ours.
|
|
68
|
+
*
|
|
69
|
+
* Searches the RENDER set, so a run's ForEach resolves to its own icon and label instead of
|
|
70
|
+
* silently falling back to the agent shape.
|
|
71
|
+
*/
|
|
72
|
+
export declare function GetNodeTypeConfig(type: string): TaskGraphRenderTypeConfig | null;
|
|
73
|
+
/** Live per-task state for the runtime overlay, keyed by `tempId`. */
|
|
74
|
+
export type TaskGraphRuntimeStatus = Record<string, TaskGraphRuntimeState>;
|
|
75
|
+
/** What a task is doing right now, in the durable engine's own vocabulary. */
|
|
76
|
+
export type TaskGraphRuntimeState = 'Pending' | 'In Progress' | 'Complete' | 'Failed' | 'Blocked' | 'Cancelled' | 'Deferred';
|
|
77
|
+
/**
|
|
78
|
+
* Maps a durable task state onto the canvas's visual vocabulary.
|
|
79
|
+
*
|
|
80
|
+
* Two mappings are worth explaining. `Blocked` renders as a **warning**, not an error: nothing went
|
|
81
|
+
* wrong, the graph simply cannot reach it — showing it as a failure would send someone hunting for a
|
|
82
|
+
* bug that does not exist. `Deferred` renders as `pending` because, to the person watching, waiting
|
|
83
|
+
* on a schedule and waiting on a prerequisite look and mean the same thing.
|
|
84
|
+
*/
|
|
85
|
+
export declare function RuntimeStateToNodeStatus(state: TaskGraphRuntimeState | undefined): FlowNodeStatus;
|
|
86
|
+
/**
|
|
87
|
+
* True when the node is a person's step.
|
|
88
|
+
*
|
|
89
|
+
* One field decides it now: spec v2 gives every node exactly one `kind`, so "is this a person's
|
|
90
|
+
* step" stopped being an inference over three optional flags and became a comparison.
|
|
91
|
+
*/
|
|
92
|
+
export declare function IsHumanTask(node: TaskGraphSpecNode): boolean;
|
|
93
|
+
/**
|
|
94
|
+
* Which of the three shapes a node is, for rendering.
|
|
95
|
+
*
|
|
96
|
+
* An unassigned node (just added, nothing picked yet) reads as an agent step: it is the commonest
|
|
97
|
+
* intent, and the validator is already telling the author, in words, that it needs an assignee.
|
|
98
|
+
* Guessing "person" instead — which is what the old `!agentName` rule did — put a step in the
|
|
99
|
+
* graph that claimed to be waiting on someone when nobody had said so.
|
|
100
|
+
*/
|
|
101
|
+
export declare function GetTaskNodeType(node: TaskGraphSpecNode): TaskGraphRenderType;
|
|
102
|
+
/**
|
|
103
|
+
* Builds the task a palette entry stands for.
|
|
104
|
+
*
|
|
105
|
+
* Pure, and here rather than in the component, because "what does clicking *Person Step* actually
|
|
106
|
+
* put in the graph" is a fact about the spec — testable without a TestBed, and the one place the
|
|
107
|
+
* assignment xor is honoured on creation.
|
|
108
|
+
*
|
|
109
|
+
* `defaultAgentName` / `defaultActionName` are what the host has to offer. When it has nothing, the
|
|
110
|
+
* step is created unassigned on purpose: inventing an agent name that may not exist would produce a
|
|
111
|
+
* graph that passes the canvas and fails at submission, whereas an unassigned step is reported
|
|
112
|
+
* immediately by the same validator the engine runs.
|
|
113
|
+
*/
|
|
114
|
+
export declare function NewTaskFromNodeType(spec: TaskGraphSpec, type: TaskGraphNodeType, defaults?: {
|
|
115
|
+
agentName?: string;
|
|
116
|
+
actionName?: string;
|
|
117
|
+
}): TaskGraphSpecNode;
|
|
118
|
+
/** Entry points: nodes nothing else has to finish first. Same rule the traversal engine uses. */
|
|
119
|
+
export declare function GetEntryTempIds(spec: TaskGraphSpec): string[];
|
|
120
|
+
/** Every dependency of a node, in normalized object form. */
|
|
121
|
+
export declare function GetDependencies(node: TaskGraphSpecNode): TaskGraphDependency[];
|
|
122
|
+
/** The `tempId`s that depend on `tempId` — i.e. what breaks if it is removed. */
|
|
123
|
+
export declare function GetDependents(spec: TaskGraphSpec, tempId: string): string[];
|
|
124
|
+
/**
|
|
125
|
+
* Projects the spec onto canvas nodes.
|
|
126
|
+
*
|
|
127
|
+
* Positions are left at the origin: layout is the canvas's job (Dagre), and a spec carries no
|
|
128
|
+
* geometry precisely because a task graph is a *logical* structure. An agent that emitted one never
|
|
129
|
+
* had an opinion about where the boxes go.
|
|
130
|
+
*/
|
|
131
|
+
/**
|
|
132
|
+
* Projects the spec onto canvas nodes.
|
|
133
|
+
*
|
|
134
|
+
* `positions` carries geometry the spec cannot hold. `TaskGraphSpec` is an execution contract with
|
|
135
|
+
* no layout field, so without a caller-held map every re-projection would return every node to the
|
|
136
|
+
* origin — which is what previously forced a full re-arrange (and a viewport re-zoom) after every
|
|
137
|
+
* single edit. Unknown ids fall back to the origin, which is also the correct starting state for a
|
|
138
|
+
* graph that has never been laid out.
|
|
139
|
+
*/
|
|
140
|
+
export declare function SpecToNodes(spec: TaskGraphSpec, runtime?: TaskGraphRuntimeStatus, positions?: ReadonlyMap<string, FlowPosition>): FlowNode[];
|
|
141
|
+
/**
|
|
142
|
+
* The one line under a node's name: who or what runs it.
|
|
143
|
+
*
|
|
144
|
+
* An unassigned step says so rather than showing nothing — a blank subtitle looks like a step that
|
|
145
|
+
* is fine, and this one is the reason the validation banner is complaining.
|
|
146
|
+
*/
|
|
147
|
+
export declare function TaskSubtitle(task: TaskGraphSpecNode, type?: TaskGraphRenderType): string;
|
|
148
|
+
/**
|
|
149
|
+
* Projects the spec's dependencies onto canvas connections, reversing their direction.
|
|
150
|
+
*
|
|
151
|
+
* A conditional edge is drawn dashed and labeled with its condition, because the difference between
|
|
152
|
+
* "always" and "only sometimes" is the single most consequential thing about an edge and the one a
|
|
153
|
+
* reader is most likely to miss when scanning a diagram.
|
|
154
|
+
*
|
|
155
|
+
* Edges naming a task that is not in the graph are skipped rather than drawn dangling — the
|
|
156
|
+
* validator reports them as `UnknownDependency`, and rendering a connection to nowhere would be a
|
|
157
|
+
* second, worse way of saying the same thing.
|
|
158
|
+
*/
|
|
159
|
+
export declare function SpecToConnections(spec: TaskGraphSpec): FlowConnection[];
|
|
160
|
+
/**
|
|
161
|
+
* Adds a dependency to the spec, returning a NEW spec.
|
|
162
|
+
*
|
|
163
|
+
* Immutable because the component emits the result to a host that may keep it, diff it, or reject
|
|
164
|
+
* it; mutating the input would let a canceled edit leak into the host's copy anyway. A duplicate
|
|
165
|
+
* edge is a no-op rather than an error — dragging the same connection twice is a slip, not a
|
|
166
|
+
* request to corrupt the graph.
|
|
167
|
+
*/
|
|
168
|
+
export declare function AddDependency(spec: TaskGraphSpec, fromTempId: string, toTempId: string, condition?: string): TaskGraphSpec;
|
|
169
|
+
/** Removes a dependency, returning a NEW spec. */
|
|
170
|
+
export declare function RemoveDependency(spec: TaskGraphSpec, fromTempId: string, toTempId: string): TaskGraphSpec;
|
|
171
|
+
/**
|
|
172
|
+
* Removes a task AND every edge into it, returning a NEW spec.
|
|
173
|
+
*
|
|
174
|
+
* Severing the inbound edges is not a convenience — leaving them would produce a graph whose
|
|
175
|
+
* `dependsOn` names a task that no longer exists, which the validator rejects as
|
|
176
|
+
* `UnknownDependency`. Deleting a box on a canvas should not make the graph invalid.
|
|
177
|
+
*/
|
|
178
|
+
export declare function RemoveTask(spec: TaskGraphSpec, tempId: string): TaskGraphSpec;
|
|
179
|
+
/** Adds a task, returning a NEW spec. */
|
|
180
|
+
export declare function AddTask(spec: TaskGraphSpec, task: TaskGraphSpecNode): TaskGraphSpec;
|
|
181
|
+
/** Replaces a task in place by `tempId`, returning a NEW spec. */
|
|
182
|
+
export declare function UpdateTask(spec: TaskGraphSpec, tempId: string, next: TaskGraphSpecNode): TaskGraphSpec;
|
|
183
|
+
/**
|
|
184
|
+
* Would adding `from → to` create a cycle?
|
|
185
|
+
*
|
|
186
|
+
* Answered before the edge exists, so the canvas can refuse it rather than create an invalid graph
|
|
187
|
+
* and report it afterwards. A self-edge is the degenerate case and is caught first.
|
|
188
|
+
*
|
|
189
|
+
* Iterative rather than recursive: the graph may come from an LLM, and a deeply-chained spec should
|
|
190
|
+
* produce a refusal, not a stack overflow.
|
|
191
|
+
*/
|
|
192
|
+
export declare function WouldCreateCycle(spec: TaskGraphSpec, fromTempId: string, toTempId: string): boolean;
|
|
193
|
+
/** A unique `tempId` for a newly added task, stable and readable. */
|
|
194
|
+
export declare function NextTempId(spec: TaskGraphSpec, prefix?: string): string;
|
|
195
|
+
//# sourceMappingURL=task-graph-canvas-adapter.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"task-graph-canvas-adapter.d.ts","sourceRoot":"","sources":["../../src/lib/task-graph-canvas-adapter.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AACH,OAAO,EAKH,KAAK,aAAa,EAClB,KAAK,iBAAiB,EACtB,KAAK,mBAAmB,EAC3B,MAAM,8BAA8B,CAAC;AACtC,OAAO,KAAK,EAAE,cAAc,EAAE,QAAQ,EAAE,cAAc,EAAE,kBAAkB,EAAE,YAAY,EAAE,MAAM,gCAAgC,CAAC;AAEjI;;;;;;;;;;;GAWG;AACH,MAAM,MAAM,iBAAiB,GAAG,WAAW,GAAG,YAAY,GAAG,WAAW,CAAC;AAEzE;;;;;;GAMG;AACH,MAAM,MAAM,mBAAmB,GAAG,iBAAiB,GAAG,YAAY,GAAG,aAAa,GAAG,WAAW,GAAG,cAAc,CAAC;AAElH,qEAAqE;AACrE,MAAM,MAAM,uBAAuB,GAAG,kBAAkB,GAAG;IAAE,IAAI,EAAE,iBAAiB,CAAA;CAAE,CAAC;AAEvF;;;;;;GAMG;AACH,wBAAgB,oBAAoB,CAAC,IAAI,EAAE,mBAAmB,GAAG,IAAI,IAAI,iBAAiB,CAEzF;AAED,gFAAgF;AAChF,MAAM,MAAM,yBAAyB,GAAG,kBAAkB,GAAG;IAAE,IAAI,EAAE,mBAAmB,CAAA;CAAE,CAAC;AAO3F,kFAAkF;AAClF,eAAO,MAAM,qBAAqB,EAAE,SAAS,uBAAuB,EAyBnE,CAAC;AAEF;;;;;GAKG;AACH,eAAO,MAAM,uBAAuB,EAAE,SAAS,yBAAyB,EAMvE,CAAC;AAEF;;;;;GAKG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,MAAM,GAAG,yBAAyB,GAAG,IAAI,CAEhF;AAED,sEAAsE;AACtE,MAAM,MAAM,sBAAsB,GAAG,MAAM,CAAC,MAAM,EAAE,qBAAqB,CAAC,CAAC;AAE3E,8EAA8E;AAC9E,MAAM,MAAM,qBAAqB,GAC3B,SAAS,GACT,aAAa,GACb,UAAU,GACV,QAAQ,GACR,SAAS,GACT,WAAW,GACX,UAAU,CAAC;AAEjB;;;;;;;GAOG;AACH,wBAAgB,wBAAwB,CAAC,KAAK,EAAE,qBAAqB,GAAG,SAAS,GAAG,cAAc,CAWjG;AAED;;;;;GAKG;AACH,wBAAgB,WAAW,CAAC,IAAI,EAAE,iBAAiB,GAAG,OAAO,CAE5D;AAED;;;;;;;GAOG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,iBAAiB,GAAG,mBAAmB,CAY5E;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,mBAAmB,CAC/B,IAAI,EAAE,aAAa,EACnB,IAAI,EAAE,iBAAiB,EACvB,QAAQ,GAAE;IAAE,SAAS,CAAC,EAAE,MAAM,CAAC;IAAC,UAAU,CAAC,EAAE,MAAM,CAAA;CAAO,GAC3D,iBAAiB,CAenB;AASD,iGAAiG;AACjG,wBAAgB,eAAe,CAAC,IAAI,EAAE,aAAa,GAAG,MAAM,EAAE,CAE7D;AAED,6DAA6D;AAC7D,wBAAgB,eAAe,CAAC,IAAI,EAAE,iBAAiB,GAAG,mBAAmB,EAAE,CAE9E;AAED,iFAAiF;AACjF,wBAAgB,aAAa,CAAC,IAAI,EAAE,aAAa,EAAE,MAAM,EAAE,MAAM,GAAG,MAAM,EAAE,CAI3E;AAOD;;;;;;GAMG;AACH;;;;;;;;GAQG;AACH,wBAAgB,WAAW,CACvB,IAAI,EAAE,aAAa,EACnB,OAAO,CAAC,EAAE,sBAAsB,EAChC,SAAS,CAAC,EAAE,WAAW,CAAC,MAAM,EAAE,YAAY,CAAC,GAC9C,QAAQ,EAAE,CAuBZ;AAED;;;;;GAKG;AACH,wBAAgB,YAAY,CAAC,IAAI,EAAE,iBAAiB,EAAE,IAAI,GAAE,mBAA2C,GAAG,MAAM,CAc/G;AAWD;;;;;;;;;;GAUG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,aAAa,GAAG,cAAc,EAAE,CA0BvE;AAED;;;;;;;GAOG;AACH,wBAAgB,aAAa,CAAC,IAAI,EAAE,aAAa,EAAE,UAAU,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,EAAE,SAAS,CAAC,EAAE,MAAM,GAAG,aAAa,CAa1H;AAED,kDAAkD;AAClD,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,aAAa,EAAE,UAAU,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,aAAa,CASzG;AAED;;;;;;GAMG;AACH,wBAAgB,UAAU,CAAC,IAAI,EAAE,aAAa,EAAE,MAAM,EAAE,MAAM,GAAG,aAAa,CAO7E;AAED,yCAAyC;AACzC,wBAAgB,OAAO,CAAC,IAAI,EAAE,aAAa,EAAE,IAAI,EAAE,iBAAiB,GAAG,aAAa,CAEnF;AAED,kEAAkE;AAClE,wBAAgB,UAAU,CAAC,IAAI,EAAE,aAAa,EAAE,MAAM,EAAE,MAAM,EAAE,IAAI,EAAE,iBAAiB,GAAG,aAAa,CAEtG;AAED;;;;;;;;GAQG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,aAAa,EAAE,UAAU,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,CAmBnG;AAED,qEAAqE;AACrE,wBAAgB,UAAU,CAAC,IAAI,EAAE,aAAa,EAAE,MAAM,SAAS,GAAG,MAAM,CAKvE"}
|
|
@@ -0,0 +1,380 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* @fileoverview Projects a `TaskGraphSpec` onto the generic canvas shapes, and back.
|
|
3
|
+
*
|
|
4
|
+
* **Kept pure and separate from the component on purpose.** Everything interesting about rendering a
|
|
5
|
+
* task graph — which node is an entry point, which edge is conditional, how a runtime status maps to
|
|
6
|
+
* a visual one, whether removing a node orphans an edge — is decidable from data alone. Putting it
|
|
7
|
+
* in a component would make it reachable only through a TestBed, and the resulting tests would be
|
|
8
|
+
* about Angular rather than about graphs.
|
|
9
|
+
*
|
|
10
|
+
* **The direction flip, again.** A `TaskGraphSpec` edge points *backwards* (`dependsOn`: "I wait for
|
|
11
|
+
* X"); a canvas connection points *forwards* (source → target). Same edge, opposite authoring
|
|
12
|
+
* convention — the graph is written by whoever knows the prerequisites, the canvas drawn by whoever
|
|
13
|
+
* follows the arrows. This is the second place in the program that inversion appears (Save as
|
|
14
|
+
* Workflow is the first), which is why it is stated rather than left implicit.
|
|
15
|
+
*
|
|
16
|
+
* @module @memberjunction/ng-task-graph-editor
|
|
17
|
+
*/
|
|
18
|
+
import { ConfigOf, NormalizeDependency, TaskNode, } from '@memberjunction/ai-core-plus';
|
|
19
|
+
/**
|
|
20
|
+
* Whether a shape is one a person can actually author here.
|
|
21
|
+
*
|
|
22
|
+
* The authoring paths — the palette, `NewTaskFromNodeType`, the properties panel — only handle the
|
|
23
|
+
* three drawable shapes. Rendering handles more. This is the seam between the two, stated as a type
|
|
24
|
+
* guard so the compiler enforces it rather than a cast pretending the distinction does not exist.
|
|
25
|
+
*/
|
|
26
|
+
export function IsAuthorableNodeType(type) {
|
|
27
|
+
return type === 'AgentTask' || type === 'ActionTask' || type === 'HumanTask';
|
|
28
|
+
}
|
|
29
|
+
const TASK_GRAPH_PORTS = [
|
|
30
|
+
{ ID: 'in', Direction: 'input', Side: 'top', Multiple: true },
|
|
31
|
+
{ ID: 'out', Direction: 'output', Side: 'bottom', Multiple: true },
|
|
32
|
+
];
|
|
33
|
+
/** What the palette offers — one entry per assignment shape the spec supports. */
|
|
34
|
+
export const TASK_GRAPH_NODE_TYPES = [
|
|
35
|
+
{
|
|
36
|
+
Type: 'AgentTask',
|
|
37
|
+
Label: 'Agent Step',
|
|
38
|
+
Icon: 'fa-robot',
|
|
39
|
+
Color: '#4A6FA5',
|
|
40
|
+
Category: 'Steps',
|
|
41
|
+
DefaultPorts: TASK_GRAPH_PORTS,
|
|
42
|
+
},
|
|
43
|
+
{
|
|
44
|
+
Type: 'ActionTask',
|
|
45
|
+
Label: 'Action Step',
|
|
46
|
+
Icon: 'fa-bolt',
|
|
47
|
+
Color: '#3B82F6',
|
|
48
|
+
Category: 'Steps',
|
|
49
|
+
DefaultPorts: TASK_GRAPH_PORTS,
|
|
50
|
+
},
|
|
51
|
+
{
|
|
52
|
+
Type: 'HumanTask',
|
|
53
|
+
Label: 'Person Step',
|
|
54
|
+
Icon: 'fa-user-check',
|
|
55
|
+
Color: '#7B1FA2',
|
|
56
|
+
Category: 'Steps',
|
|
57
|
+
DefaultPorts: TASK_GRAPH_PORTS,
|
|
58
|
+
},
|
|
59
|
+
];
|
|
60
|
+
/**
|
|
61
|
+
* Everything the canvas can DEPICT: the palette, plus the kinds that only ever arrive from a run.
|
|
62
|
+
*
|
|
63
|
+
* Deliberately a superset rather than an extension of the palette — adding these to
|
|
64
|
+
* `TASK_GRAPH_NODE_TYPES` would put un-configurable entries in the authoring toolbox.
|
|
65
|
+
*/
|
|
66
|
+
export const TASK_GRAPH_RENDER_TYPES = [
|
|
67
|
+
...TASK_GRAPH_NODE_TYPES,
|
|
68
|
+
{ Type: 'PromptTask', Label: 'Prompt Step', Icon: 'fa-comment-dots', Color: '#8B5CF6', Category: 'Steps', DefaultPorts: TASK_GRAPH_PORTS },
|
|
69
|
+
{ Type: 'ForEachTask', Label: 'For Each Step', Icon: 'fa-repeat', Color: '#D97706', Category: 'Steps', DefaultPorts: TASK_GRAPH_PORTS },
|
|
70
|
+
{ Type: 'WhileTask', Label: 'While Step', Icon: 'fa-rotate', Color: '#D97706', Category: 'Steps', DefaultPorts: TASK_GRAPH_PORTS },
|
|
71
|
+
{ Type: 'ExternalTask', Label: 'External Step', Icon: 'fa-arrow-up-right-from-square', Color: '#0891B2', Category: 'Steps', DefaultPorts: TASK_GRAPH_PORTS },
|
|
72
|
+
];
|
|
73
|
+
/**
|
|
74
|
+
* The config for a node type, or null when the type is not one of ours.
|
|
75
|
+
*
|
|
76
|
+
* Searches the RENDER set, so a run's ForEach resolves to its own icon and label instead of
|
|
77
|
+
* silently falling back to the agent shape.
|
|
78
|
+
*/
|
|
79
|
+
export function GetNodeTypeConfig(type) {
|
|
80
|
+
return TASK_GRAPH_RENDER_TYPES.find((c) => c.Type === type) ?? null;
|
|
81
|
+
}
|
|
82
|
+
/**
|
|
83
|
+
* Maps a durable task state onto the canvas's visual vocabulary.
|
|
84
|
+
*
|
|
85
|
+
* Two mappings are worth explaining. `Blocked` renders as a **warning**, not an error: nothing went
|
|
86
|
+
* wrong, the graph simply cannot reach it — showing it as a failure would send someone hunting for a
|
|
87
|
+
* bug that does not exist. `Deferred` renders as `pending` because, to the person watching, waiting
|
|
88
|
+
* on a schedule and waiting on a prerequisite look and mean the same thing.
|
|
89
|
+
*/
|
|
90
|
+
export function RuntimeStateToNodeStatus(state) {
|
|
91
|
+
switch (state) {
|
|
92
|
+
case 'In Progress': return 'running';
|
|
93
|
+
case 'Complete': return 'success';
|
|
94
|
+
case 'Failed': return 'error';
|
|
95
|
+
case 'Blocked': return 'warning';
|
|
96
|
+
case 'Cancelled': return 'disabled';
|
|
97
|
+
case 'Deferred': return 'pending';
|
|
98
|
+
case 'Pending': return 'pending';
|
|
99
|
+
default: return 'default';
|
|
100
|
+
}
|
|
101
|
+
}
|
|
102
|
+
/**
|
|
103
|
+
* True when the node is a person's step.
|
|
104
|
+
*
|
|
105
|
+
* One field decides it now: spec v2 gives every node exactly one `kind`, so "is this a person's
|
|
106
|
+
* step" stopped being an inference over three optional flags and became a comparison.
|
|
107
|
+
*/
|
|
108
|
+
export function IsHumanTask(node) {
|
|
109
|
+
return node.kind === 'Human';
|
|
110
|
+
}
|
|
111
|
+
/**
|
|
112
|
+
* Which of the three shapes a node is, for rendering.
|
|
113
|
+
*
|
|
114
|
+
* An unassigned node (just added, nothing picked yet) reads as an agent step: it is the commonest
|
|
115
|
+
* intent, and the validator is already telling the author, in words, that it needs an assignee.
|
|
116
|
+
* Guessing "person" instead — which is what the old `!agentName` rule did — put a step in the
|
|
117
|
+
* graph that claimed to be waiting on someone when nobody had said so.
|
|
118
|
+
*/
|
|
119
|
+
export function GetTaskNodeType(node) {
|
|
120
|
+
switch (node.kind) {
|
|
121
|
+
case 'Human': return 'HumanTask';
|
|
122
|
+
case 'Action': return 'ActionTask';
|
|
123
|
+
case 'Prompt': return 'PromptTask';
|
|
124
|
+
case 'ForEach': return 'ForEachTask';
|
|
125
|
+
case 'While': return 'WhileTask';
|
|
126
|
+
case 'External': return 'ExternalTask';
|
|
127
|
+
// An unassigned node — just added, nothing picked — reads as an agent step: the commonest
|
|
128
|
+
// intent, and the validator is already saying in words that it needs an assignee.
|
|
129
|
+
default: return 'AgentTask';
|
|
130
|
+
}
|
|
131
|
+
}
|
|
132
|
+
/**
|
|
133
|
+
* Builds the task a palette entry stands for.
|
|
134
|
+
*
|
|
135
|
+
* Pure, and here rather than in the component, because "what does clicking *Person Step* actually
|
|
136
|
+
* put in the graph" is a fact about the spec — testable without a TestBed, and the one place the
|
|
137
|
+
* assignment xor is honoured on creation.
|
|
138
|
+
*
|
|
139
|
+
* `defaultAgentName` / `defaultActionName` are what the host has to offer. When it has nothing, the
|
|
140
|
+
* step is created unassigned on purpose: inventing an agent name that may not exist would produce a
|
|
141
|
+
* graph that passes the canvas and fails at submission, whereas an unassigned step is reported
|
|
142
|
+
* immediately by the same validator the engine runs.
|
|
143
|
+
*/
|
|
144
|
+
export function NewTaskFromNodeType(spec, type, defaults = {}) {
|
|
145
|
+
const base = {
|
|
146
|
+
tempId: NextTempId(spec),
|
|
147
|
+
name: NEW_TASK_NAMES[type],
|
|
148
|
+
description: '',
|
|
149
|
+
dependsOn: [],
|
|
150
|
+
};
|
|
151
|
+
switch (type) {
|
|
152
|
+
case 'HumanTask': return TaskNode.Human(base);
|
|
153
|
+
// A step created before the host has any names to offer is created with an empty one on
|
|
154
|
+
// purpose: the validator reports it immediately, whereas inventing a name would produce a
|
|
155
|
+
// graph that passes here and fails at submission.
|
|
156
|
+
case 'ActionTask': return TaskNode.Action(base, { actionName: defaults.actionName ?? '' });
|
|
157
|
+
default: return TaskNode.Agent(base, { agentName: defaults.agentName ?? '' });
|
|
158
|
+
}
|
|
159
|
+
}
|
|
160
|
+
/** Default step names, so a new box says what it is before the author renames it. */
|
|
161
|
+
const NEW_TASK_NAMES = {
|
|
162
|
+
AgentTask: 'New agent step',
|
|
163
|
+
ActionTask: 'New action step',
|
|
164
|
+
HumanTask: 'New person step',
|
|
165
|
+
};
|
|
166
|
+
/** Entry points: nodes nothing else has to finish first. Same rule the traversal engine uses. */
|
|
167
|
+
export function GetEntryTempIds(spec) {
|
|
168
|
+
return (spec.tasks ?? []).filter((t) => (t.dependsOn ?? []).length === 0).map((t) => t.tempId);
|
|
169
|
+
}
|
|
170
|
+
/** Every dependency of a node, in normalized object form. */
|
|
171
|
+
export function GetDependencies(node) {
|
|
172
|
+
return (node.dependsOn ?? []).map(NormalizeDependency);
|
|
173
|
+
}
|
|
174
|
+
/** The `tempId`s that depend on `tempId` — i.e. what breaks if it is removed. */
|
|
175
|
+
export function GetDependents(spec, tempId) {
|
|
176
|
+
return (spec.tasks ?? [])
|
|
177
|
+
.filter((t) => GetDependencies(t).some((d) => d.tempId === tempId))
|
|
178
|
+
.map((t) => t.tempId);
|
|
179
|
+
}
|
|
180
|
+
/** Deterministic id for a canvas edge, so re-renders don't churn selection. */
|
|
181
|
+
function edgeId(fromTempId, toTempId) {
|
|
182
|
+
return `${fromTempId}->${toTempId}`;
|
|
183
|
+
}
|
|
184
|
+
/**
|
|
185
|
+
* Projects the spec onto canvas nodes.
|
|
186
|
+
*
|
|
187
|
+
* Positions are left at the origin: layout is the canvas's job (Dagre), and a spec carries no
|
|
188
|
+
* geometry precisely because a task graph is a *logical* structure. An agent that emitted one never
|
|
189
|
+
* had an opinion about where the boxes go.
|
|
190
|
+
*/
|
|
191
|
+
/**
|
|
192
|
+
* Projects the spec onto canvas nodes.
|
|
193
|
+
*
|
|
194
|
+
* `positions` carries geometry the spec cannot hold. `TaskGraphSpec` is an execution contract with
|
|
195
|
+
* no layout field, so without a caller-held map every re-projection would return every node to the
|
|
196
|
+
* origin — which is what previously forced a full re-arrange (and a viewport re-zoom) after every
|
|
197
|
+
* single edit. Unknown ids fall back to the origin, which is also the correct starting state for a
|
|
198
|
+
* graph that has never been laid out.
|
|
199
|
+
*/
|
|
200
|
+
export function SpecToNodes(spec, runtime, positions) {
|
|
201
|
+
const entryIds = new Set(GetEntryTempIds(spec));
|
|
202
|
+
return (spec.tasks ?? []).map((task) => {
|
|
203
|
+
const type = GetTaskNodeType(task);
|
|
204
|
+
const known = positions?.get(task.tempId);
|
|
205
|
+
return {
|
|
206
|
+
ID: task.tempId,
|
|
207
|
+
Type: type,
|
|
208
|
+
Label: task.name,
|
|
209
|
+
Subtitle: TaskSubtitle(task, type),
|
|
210
|
+
Icon: GetNodeTypeConfig(type)?.Icon ?? 'fa-circle-nodes',
|
|
211
|
+
Status: RuntimeStateToNodeStatus(runtime?.[task.tempId]),
|
|
212
|
+
StatusMessage: task.description,
|
|
213
|
+
IsStartNode: entryIds.has(task.tempId),
|
|
214
|
+
Position: known ? { ...known } : { X: 0, Y: 0 },
|
|
215
|
+
Ports: [
|
|
216
|
+
{ ID: 'in', Direction: 'input', Side: 'top', Multiple: true },
|
|
217
|
+
{ ID: 'out', Direction: 'output', Side: 'bottom', Multiple: true },
|
|
218
|
+
],
|
|
219
|
+
Data: { TempId: task.tempId },
|
|
220
|
+
};
|
|
221
|
+
});
|
|
222
|
+
}
|
|
223
|
+
/**
|
|
224
|
+
* The one line under a node's name: who or what runs it.
|
|
225
|
+
*
|
|
226
|
+
* An unassigned step says so rather than showing nothing — a blank subtitle looks like a step that
|
|
227
|
+
* is fine, and this one is the reason the validation banner is complaining.
|
|
228
|
+
*/
|
|
229
|
+
export function TaskSubtitle(task, type = GetTaskNodeType(task)) {
|
|
230
|
+
switch (type) {
|
|
231
|
+
case 'HumanTask': return 'Waiting on a person';
|
|
232
|
+
case 'ActionTask': return ConfigOf(task, 'Action')?.actionName || 'No action chosen yet';
|
|
233
|
+
case 'PromptTask': return ConfigOf(task, 'Prompt')?.promptName || 'No prompt chosen yet';
|
|
234
|
+
// A loop's subtitle is what it REPEATS — the one fact that makes the node readable.
|
|
235
|
+
case 'ForEachTask': return LoopBodyLabel(ConfigOf(task, 'ForEach')) ?? 'Repeats for each item';
|
|
236
|
+
case 'WhileTask': return LoopBodyLabel(ConfigOf(task, 'While')) ?? 'Repeats until its condition is false';
|
|
237
|
+
case 'ExternalTask': return ConfigOf(task, 'External')?.domain || 'Completed by an outside system';
|
|
238
|
+
// Only a genuinely unassigned node reaches this now. It used to catch Prompt, ForEach,
|
|
239
|
+
// While and External too — so a fully-configured loop displayed "No agent chosen yet",
|
|
240
|
+
// which reads as a broken step rather than an unrecognised one.
|
|
241
|
+
default: return ConfigOf(task, 'Agent')?.agentName || 'No agent chosen yet';
|
|
242
|
+
}
|
|
243
|
+
}
|
|
244
|
+
/** What a loop repeats, when it says. */
|
|
245
|
+
function LoopBodyLabel(op) {
|
|
246
|
+
if (!op)
|
|
247
|
+
return null;
|
|
248
|
+
const body = op.action?.name ?? op.subAgent?.name ?? op.prompt?.name;
|
|
249
|
+
return body ? `Repeats: ${body}` : null;
|
|
250
|
+
}
|
|
251
|
+
/**
|
|
252
|
+
* Projects the spec's dependencies onto canvas connections, reversing their direction.
|
|
253
|
+
*
|
|
254
|
+
* A conditional edge is drawn dashed and labeled with its condition, because the difference between
|
|
255
|
+
* "always" and "only sometimes" is the single most consequential thing about an edge and the one a
|
|
256
|
+
* reader is most likely to miss when scanning a diagram.
|
|
257
|
+
*
|
|
258
|
+
* Edges naming a task that is not in the graph are skipped rather than drawn dangling — the
|
|
259
|
+
* validator reports them as `UnknownDependency`, and rendering a connection to nowhere would be a
|
|
260
|
+
* second, worse way of saying the same thing.
|
|
261
|
+
*/
|
|
262
|
+
export function SpecToConnections(spec) {
|
|
263
|
+
const known = new Set((spec.tasks ?? []).map((t) => t.tempId));
|
|
264
|
+
const connections = [];
|
|
265
|
+
for (const task of spec.tasks ?? []) {
|
|
266
|
+
for (const dep of GetDependencies(task)) {
|
|
267
|
+
if (!known.has(dep.tempId))
|
|
268
|
+
continue;
|
|
269
|
+
const conditional = !!dep.condition?.trim();
|
|
270
|
+
connections.push({
|
|
271
|
+
ID: edgeId(dep.tempId, task.tempId),
|
|
272
|
+
// Reversed: dependsOn points back at the prerequisite, the drawn arrow points forward.
|
|
273
|
+
SourceNodeID: dep.tempId,
|
|
274
|
+
SourcePortID: 'out',
|
|
275
|
+
TargetNodeID: task.tempId,
|
|
276
|
+
TargetPortID: 'in',
|
|
277
|
+
Label: conditional ? 'if' : undefined,
|
|
278
|
+
LabelDetail: dep.condition ?? undefined,
|
|
279
|
+
LabelIcon: conditional ? 'fa-code-branch' : undefined,
|
|
280
|
+
Condition: dep.condition ?? undefined,
|
|
281
|
+
Style: conditional ? 'dashed' : 'solid',
|
|
282
|
+
Data: { FromTempId: dep.tempId, ToTempId: task.tempId },
|
|
283
|
+
});
|
|
284
|
+
}
|
|
285
|
+
}
|
|
286
|
+
return connections;
|
|
287
|
+
}
|
|
288
|
+
/**
|
|
289
|
+
* Adds a dependency to the spec, returning a NEW spec.
|
|
290
|
+
*
|
|
291
|
+
* Immutable because the component emits the result to a host that may keep it, diff it, or reject
|
|
292
|
+
* it; mutating the input would let a canceled edit leak into the host's copy anyway. A duplicate
|
|
293
|
+
* edge is a no-op rather than an error — dragging the same connection twice is a slip, not a
|
|
294
|
+
* request to corrupt the graph.
|
|
295
|
+
*/
|
|
296
|
+
export function AddDependency(spec, fromTempId, toTempId, condition) {
|
|
297
|
+
return {
|
|
298
|
+
...spec,
|
|
299
|
+
tasks: (spec.tasks ?? []).map((task) => {
|
|
300
|
+
if (task.tempId !== toTempId)
|
|
301
|
+
return task;
|
|
302
|
+
const existing = GetDependencies(task);
|
|
303
|
+
if (existing.some((d) => d.tempId === fromTempId))
|
|
304
|
+
return task;
|
|
305
|
+
const next = condition?.trim()
|
|
306
|
+
? { tempId: fromTempId, condition }
|
|
307
|
+
: fromTempId;
|
|
308
|
+
return { ...task, dependsOn: [...(task.dependsOn ?? []), next] };
|
|
309
|
+
}),
|
|
310
|
+
};
|
|
311
|
+
}
|
|
312
|
+
/** Removes a dependency, returning a NEW spec. */
|
|
313
|
+
export function RemoveDependency(spec, fromTempId, toTempId) {
|
|
314
|
+
return {
|
|
315
|
+
...spec,
|
|
316
|
+
tasks: (spec.tasks ?? []).map((task) => task.tempId !== toTempId
|
|
317
|
+
? task
|
|
318
|
+
: { ...task, dependsOn: (task.dependsOn ?? []).filter((d) => NormalizeDependency(d).tempId !== fromTempId) }),
|
|
319
|
+
};
|
|
320
|
+
}
|
|
321
|
+
/**
|
|
322
|
+
* Removes a task AND every edge into it, returning a NEW spec.
|
|
323
|
+
*
|
|
324
|
+
* Severing the inbound edges is not a convenience — leaving them would produce a graph whose
|
|
325
|
+
* `dependsOn` names a task that no longer exists, which the validator rejects as
|
|
326
|
+
* `UnknownDependency`. Deleting a box on a canvas should not make the graph invalid.
|
|
327
|
+
*/
|
|
328
|
+
export function RemoveTask(spec, tempId) {
|
|
329
|
+
return {
|
|
330
|
+
...spec,
|
|
331
|
+
tasks: (spec.tasks ?? [])
|
|
332
|
+
.filter((t) => t.tempId !== tempId)
|
|
333
|
+
.map((t) => ({ ...t, dependsOn: (t.dependsOn ?? []).filter((d) => NormalizeDependency(d).tempId !== tempId) })),
|
|
334
|
+
};
|
|
335
|
+
}
|
|
336
|
+
/** Adds a task, returning a NEW spec. */
|
|
337
|
+
export function AddTask(spec, task) {
|
|
338
|
+
return { ...spec, tasks: [...(spec.tasks ?? []), task] };
|
|
339
|
+
}
|
|
340
|
+
/** Replaces a task in place by `tempId`, returning a NEW spec. */
|
|
341
|
+
export function UpdateTask(spec, tempId, next) {
|
|
342
|
+
return { ...spec, tasks: (spec.tasks ?? []).map((t) => (t.tempId === tempId ? next : t)) };
|
|
343
|
+
}
|
|
344
|
+
/**
|
|
345
|
+
* Would adding `from → to` create a cycle?
|
|
346
|
+
*
|
|
347
|
+
* Answered before the edge exists, so the canvas can refuse it rather than create an invalid graph
|
|
348
|
+
* and report it afterwards. A self-edge is the degenerate case and is caught first.
|
|
349
|
+
*
|
|
350
|
+
* Iterative rather than recursive: the graph may come from an LLM, and a deeply-chained spec should
|
|
351
|
+
* produce a refusal, not a stack overflow.
|
|
352
|
+
*/
|
|
353
|
+
export function WouldCreateCycle(spec, fromTempId, toTempId) {
|
|
354
|
+
if (fromTempId === toTempId)
|
|
355
|
+
return true;
|
|
356
|
+
// A cycle appears iff `from` is already reachable from `to` by following dependsOn edges —
|
|
357
|
+
// i.e. `to` already (transitively) waits on `from`.
|
|
358
|
+
const dependenciesOf = new Map((spec.tasks ?? []).map((t) => [t.tempId, GetDependencies(t).map((d) => d.tempId)]));
|
|
359
|
+
const stack = [...(dependenciesOf.get(fromTempId) ?? [])];
|
|
360
|
+
const seen = new Set();
|
|
361
|
+
while (stack.length > 0) {
|
|
362
|
+
const current = stack.pop();
|
|
363
|
+
if (current === toTempId)
|
|
364
|
+
return true;
|
|
365
|
+
if (seen.has(current))
|
|
366
|
+
continue;
|
|
367
|
+
seen.add(current);
|
|
368
|
+
stack.push(...(dependenciesOf.get(current) ?? []));
|
|
369
|
+
}
|
|
370
|
+
return false;
|
|
371
|
+
}
|
|
372
|
+
/** A unique `tempId` for a newly added task, stable and readable. */
|
|
373
|
+
export function NextTempId(spec, prefix = 'task') {
|
|
374
|
+
const taken = new Set((spec.tasks ?? []).map((t) => t.tempId));
|
|
375
|
+
let n = (spec.tasks ?? []).length + 1;
|
|
376
|
+
while (taken.has(`${prefix}${n}`))
|
|
377
|
+
n++;
|
|
378
|
+
return `${prefix}${n}`;
|
|
379
|
+
}
|
|
380
|
+
//# sourceMappingURL=task-graph-canvas-adapter.js.map
|