A graph is a collection of tasks and pipes that can be stored in JSON format.
Every task refers to a function which output can be piped as an argument to another task.
A graph has the following properties
- task: collection of function names.
- pipe: connections from the output of a task to an input of another task.
- data: (optional) persistence object.
- func: (optional) collection of subgraphs.
- view: (ignored) object containing information used by flow-view to render a graphic representation of the graph.
- info: (to be defined) meta data, like author, version and, above all, doc which is a dflow graph itself. See info draft
dflow provides few builtin functions and injects the following ones
return: a task that accepts one argument and behaves like a Return statement.
arguments: task that returns the arguments of dflowFun.
arguments[N]: tasks that return the arguments[i] of dflowFun.
this: refers the dflowFun function.
this.graph: contains the graph itself.
this.graph.data: returns the graph data content.
@foo: set/get graph.data.foo JSON data.
&bar: returns bar function.
- dot-operator-like functions
.quz: returns an attribute reader function.
.quuz=: returns an attribute writer function.
.quuuz(): returns a dot-operator-like function.
- any task found in global context, for example
process.version: will resolve to a function that returns it
/subgraph: returns a function compiled from subgraph that is an entry in func collection.
'string': a quoted string will resolve to a function that returns that string.
123: any number or float will resolve to a function that returns that number.
// comment: every task starting with
You can pass a second optional argument to
dflow.fun() containing a collection
of additional functions that will be used in the task resolution.
In order to avoid conflicts with injected functions, the optional collection of additionalFunctions must contain function names validated by the following rules:
- cannot be the name of an injected function:
arguments[N], reserver keys like
returnare not allowed.
- cannot start with a dot, ampersand or at sign: names
.quuuz()for an additional function are not allowed.
Arrow functions and
If a task string does not match with some of the builtin functions above and
neither some addition function provided, but it contains an arrow
the dflow engine will try to eval it.
Yes, I know, eval is evil but think about using an arrow function.
By adding this feature to the specification, you can create a task like
x => x * 2.
I admit I failed to resist the eval temptation, in deed there is also another
type of tasks that uses it. If a task starts with the four characters *new *, i.e.
new plus a space, it is evaluated. Yes, you can write
and it will return a date.
Note that the evaluation is performed on compile time.
This section is a draft
Context tells if the graph should run client side or server side. Values can be
If not specified, it is assumed to be universal a.k.a. isomorphic.