Specification

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

Task resolution

Builtin functions

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[0] … 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
  • isFunction
  • Math.cos
  • 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 // is ignored.
• dflow.fun
• dflow.isDflowFun
• dflow.validate

Additional functions

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[0] … arguments[N], reserver keys like this and return are not allowed.
• cannot start with a dot, ampersand or at sign: names @foo, &bar, .quz, .quuz= and .quuuz() for an additional function are not allowed.

Arrow functions and new

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 new Date and it will return a date.

Note that the evaluation is performed on compile time.

Info

This section is a draft

context

Context tells if the graph should run client side or server side. Values can be

• client
• server

If not specified, it is assumed to be universal a.k.a. isomorphic.