DEV workflow editor

Folder structure

WorkflowEditor
├── ParametersEngine
    ├── parameters
        ├── DesignEditor
        ├── DesignBlockModel.js
        ├── DesignBlocksModel.js
        ├── DoDesignModel.js
        └── index.js
    └── AbstractParameterModel.js
    └── ParametersEngine.js
├── sidebars
    ├── BlockSidebar
    ├── WorkflowSidebar
    └── DraggableBlockTypesListSidebar.js
├── WorkflowGraphEditor
    ├── factories
    ├── models
    ├── widgets
    └── WorkflowGraphEditor.js
├── WorkflowEditor.js
└── WorkflowEditorContainer.js

The workflow editor is composed of three sections: a sidebar on the left, the graph editor on the center and a sidebar on the right. The sidebar on the right contains blocks that can be dragged on the graph editor. The sidebar on the right contains workflow properties or block properties (if one is selected).

NOTE: unlike the rest of the application, all the components in this directory don't work as usual React components: they use props and state, but they don't get updated. Instead, there are Model classes that hold the state. The WorkflowEditor component handles the logic to update React when a model changes (calling the forceUpdate method). This approach is used because the library used for the graph editor uses this pattern to allow customization.

Dynamic loading

All the type of blocks and their parameters are dynamically loaded. The definition of each block is defined in the BlockType resource. Definitions of BlockTypes are called BlockTypeDefinitions.

Example of a BlockTypeDefinition:

{
  "name": "lambda",
  "ports": [ ... ],
  "displayName": "λ",
  "parameterDefinitions": [
    {
      "name": "toCache",
      "displayName": "Cache result",
      "description": "Should the result be cached?",
      "default": true,
      "required": true,
      "type": "boolean"
    },
    {
      "name": "code",
      "displayName": "Code",
      "description": "Code to execute",
      "default": "return input.length;",
      "required": true,
      "type": "code"
    }
  ]
}

Adding a block to the graph

When a block type is dragged in the editor, a new Block. The name of the BlockTypeDefinition becomes the type of the new block. The DefaultBlockNodeModel will take care of the creation of an id.

Parameters, serialization and deserialization

Each block has some parameters. These parameters are also defined in the BlockTypeDefinition. When the block is retrieved from the server the parameters of a block are inside a map that associates the parameter name with its value. When the block is deserialized, this map gets mapped to a map of ParametersModel, which contains also the parameter definition (default value, type, etc...)

Components

Below you can find a brief description of the different components, ordered like they are used in the application.

WorkflowEditorContainer.js

Blocks listed in the left sidebar and block type definitions used across the editor are dynamically loaded from the server. This component takes care of loading them (using the BlockTypesService) and renders the WorkflowEditor when they are fetched.

WorkflowEditor.js

This component contains the three different sections of the editor and coordinates the communication between them. This component also contains the reference to the WorkflowGraphModel and causes the update of the view through the call to forceUpdate.

sidebars/DraggableBlockTypesListSidebar.js

Shows the list of block types. Every block type corrisponds to a div that can be dragged away.

WorkflowGraphEditor

This folder contains the actual graph editor, which is based on react-diagrams. This library defines different entities:

• Node
• Port: object that can have link to connect the port to other ports
• Link: connection between ports
• Graph

Eache entity has a corrisponding Model, Factory and Widget class:

• ...Model: contains the data and the logic to update the view
• ...Widget: React component used to render the entity
• ...Factory: instantiates the Model and Widget for the corrisponding entity

The project extends the following entities:

• DefaultBlockNodeModel: extends DefaultNodeModel to add parameters and workflow run status;
• DefaultBlockNodeFactory;
• DoBlockNodeModel: extends DefaultBlockNodeModel to use the DoBlockRunAdapter;
• DoBlockNodeFactory;
• BlockPortModel: extends DefaultPortModel to block the user from creating recursive dependencies between the blocks;
• BlockPortFactory;
• WorkflowGraphModel: extends DefaultWorkflowGraphModel;
• WorkflowEngine: extends DefaultWorkflowEngine to register our factories;

sidebars/WorkflowSidebar

This components contains the controls to edit properties of the workflow. It uses the RunControls component to show the state of the latest run.

sidebars/BlockSidebar

This component shows the controls to edit properties of the selected block.

parameters

This folder contains the definition of the parameter models and widgets. A parameter model contains a parameter value and its definition. The widget is responsible to render a HTML control that the user can use to change the value.

Parameters are serialized, deserialized and rendered by the ParametersEngine.