Custom packages
In Codeflow, it is easy to create custom packages and publish it to the package repository. The Codeflow designer comes with a built-in, publish dialog to upload custom packages to the repository.
Flows as modules
A flow can be packaged and published as a module. The start
and end
step of a flow becomes the input and output schema of a module. The below image shows a custom package expanded in the file tree.
Custom package codeflow/handlebars installed and opened in the file tree.
Publishing a package
To publish flows, the entire project should be published. The package will include all the files under the project, except the excluded directories like node_modules
, .packages
etc. However only the selected flows would be visible as modules in the package. The designer uses a wizard to select flows that should be made visible to the end user.
Below steps describe how to publish a package:
- To publish a project as a package, right click on the root of the file panel and choose publish package. It will open up a wizard similar to the below image. Fill the fields and click next, it will open up the module selector dialog.
- In this dialog, select only the flows that should be visible to the end user. Currently only the top level flows are available for publishing. Select the flows and click next.
- It will open the dependency section. Dependency section lists both native Node.js dependencies as well as Codeflow package dependencies. This section is for reference only. If there are any missing or extra packages, cancel the dialog and restart the publishing process after manually installing/removing the dependency packages. If the dependencies are OK, click next.
- The final screen shows the overview of the package. Click publish to publish the package, and the package should be published.
Native modules
There may be often requirements for a module to have more than just an input and output schema. For example, certain modules, like the executeFlow
module in the core package, would require to dynamically update the output schema based on the flow file chosen in the input. Fo such use cases, users can write modules in a custom JSON format and save it with .act extension.
Native modules are written in JavaScript with extra metadata to describe the input/output schemas, description and other metadata. Most of the built-in modules are native modules and they provide the building blocks for other flows. start
, end
, execute Flow
, iterate
etc are examples of native modules.
For e.g. below is the actual implementation of the log module under the console package. As you can see, it delegates to the console.log method available in native JavaScript.
The module is specified as a JSON file (log.act)
//log.act
{
"source": "log.js",
"method": "execute",
"input-schema": {
"type": "object",
"properties": {
"message": {
"type": "any",
"description": "A message that should be printed to the stdout."
}
}
},
"meta": {
"name": "Log"
"description": "Outputs a message to the stdout"
}
}
And the actual source is specified in a JavaScript file (log.js)
//log.js
module.exports.execute = function(input, callback) {
if (input && input.text) {
console.log(input.text)
}
callback()
}
And this is how the log module appears in the designer:
Input panel for the log module when rendered in the designer.
Native modules are also published the same way as above. The designer recognizes both .act
and .flw
as modules while publishing.