0 Design: Subflow Instance properties

Hiroyasu Nishiyama edited this page 2018-09-09 12:50:10 +09:00

This is a work in progress. Do not start implementing anything without discussing with @knolleary first

This feature will allow individual instances of a subflow to be customised. This increases the reusability of subflows.

For example, a subflow that makes an HTTP Request and processes the response in some common way. Each instance of the subflow may want to call a slightly different HTTP URL.

This design needs to cover:

• how a subflow identifies what properties can be customised
• how the nodes within the subflow can use the customised properties
• how an subflow instance node provides custom values to those properities

This will also feed into Design: Subflow Node modules.

---

Following a post on the forum here's a copy of my response there. These points need expanding out in the design.

• Subflow instance properties are evaluated when the instance is created in the runtime. They cannot be set by passed in messages. They cannot change without the subflow instance being redeployed. This is because they are used to configure nodes within the subflow - and nodes cannot have their configuration dynamically changed at runtime. For example, the address of the MQTT Broker to connect to.
• This means the instance properties can only be set by any of the static types in the TypedInput list of supported types - including environment variables. That excludes msg, flow and global.
• Subflow instance properties appear as environment variables to the nodes within the subflow. This means, as you can today, a node's property can be set to the value ${FOO} for it to be substituted with the value of FOO.
• We have already added in git (#dev branch) the ability to get env var values in a Function node - using env.get("FOO"). That will allow Function nodes to programmatically access subflow instance properties.
• A Change node (using the Env Var TypedInput type) can be used to attach any of these properties to a msg object passing through the flow if that is required.

(HN): In the teleconference held on Aug. 30th, I proposed extension of Function node (and Dashboard Template(ui_template) node) which adds interface for defining parameter input UI (details can be found here).
Nick-san suggested to think about integrating this proposal to Subflow Instance Property described here.
Following is summary of my proposal on Function node extension and thoughts on its application to Subflow Instance Properties.

Our use cases are as follows:

1. In our environment, flow developers and flow users exists and they are different person in many cases. The flow developer has JavaScript programming skill, but the flow user does not. The flow user basically perform nodes connection and parameter settings of nodes using Node-RED editor.
   In order to customize node functionalities of Function nodes with same logic, we are required to change JavaScript codes directly in current Node-RED implementation. This code change is difficult for novice flow users. So, providing parameter settings UI for each Function node instances is desirable.
2. We have another problem even if flow developer and flow user is a same person. When the user want to change a logic (e.g. for fixing a bug) in Function nodes containing same JavaScript code, the user needs to change codes in Function nodes and apply changes to each node. This is troublesome and error prone. If we can separately define parameter values, we can simply copy new JavaScript code to Function nodes.
3. If we provide a feature for generating independent node from Function node, we can use parameters input UI as its settings UI.

Our proposal for Function node extension was as follows:

• add a tab for defining parameters input UI and a tab for inputting parameters with defined UI,
• UI definition consists of horizontal input items and their labels for ease of UI layout,
• following parameters can be specified for inputting parameters:
  • one of types that can be specified for TypedInput,
  • selection fo types that can be specified for TypedInput (types can be selected on input parameter fields),
  • menu item selection,
  • checkbox,
  • no input (only shows label)
• inputted data and related fields informations (types, labels, ...) can be accessed as Function node's property.
• checkbox is provided to hide JavaScript editor and UI editor tab.

As Nick-san suggested, the proposal for Function node can also applied to Subflow Instance Property.
I think it will resolve the problems for our use cases. But I have some concerns:

1. Subflow instance properties are proposed to be accessed similar to access for an environment variable.
   My concern is how to deal with non-string data such as JSON.
   I think property input should support TypedInput-style input type selection.
   • Proposal 1: env.get("FOO") can return non-string type data, and env.getInputType("FOO") returns type of input field (if any).
2. If applying to subflow, I think that we sometimes needs to change parameter values of a node in subflow that can not specify environment variable (without input filed). Such case includes menu, checkbox, or other complex input items.
   • Proposal 1: make internal options of a node to be accessed as an corresponding environment variable (for complex input items such as TLS configuration or widget size setting, we need to extend property input mechanism with custom JavaScript?),
3. I think that we need a mechanism for specifying a field type if existing node in a subflow uses TypedInput field,
   • Proposal 1: If a type is associated with environment variable of Subflow Instance property, specify the type to typr of TypedInput filed,
4. Even if we want to create parameter settings UI for a Function node, we need to create subflow that contains single Function node. This seems cumbersome in some cases.
   • Proposal 1: add parameter definition UI for Function node,
   • Proposal 2: allow some shortcut for creating & modifying a subflow instance property with only Function node.

• Design Notes
• Tech Interchange Meetings