Subflow Instance Properties is a key item on Roadmap to 1.0.
Top view description: A user can identify properties of nodes within a subflow that should be customisable on a per-subflow-instance basis. (Taken from Trello)
I want to go ahead and implement this feature, with your valuable support.
Defining the custom arguments
Defining the custom arguments names should be allowed as a editable list in the edit (sub)flow template panel.
- How editing this list will effect already existing instances?
I think removing items should drop them also in the subflow instances.
There must be a hard connection between the definition and the instances, probably.
Setting values for the custom arguments
The argument values can be set by different methods:
-
In the subflow instance node's edit panel, the arguments (that were predefined in the template) will be listed while allowing the user to input their values origin. The input boxes probably can be 'TypedInput' as well.
-
Received on run-time as a msg argument matching a custom argument name. (custom argument names might have some blacklisted ones?)
-
Environment variable (flow/global, by it's name being specified).
-
More?
- Each custom argument can be set in it's own method independent by other arguments / instances.
- The method chosen for each argument can be selected in the edit panel of a subflow instance using special types in the TypedInput box.
Using custom arguments values by nodes that belong to a subflow
The argument values can be used by different methods:
- Add all values to the msg object.
- Set all values as flow variables.
- More?
- Only one of the method should be selected by each subflow instance.
Any inputs & thoughts would be much appreciate.
Omer Efrat.
2 Likes
Hi Omer,
there's a lot to cover here. It is fair to say we haven't fully captured all of our thoughts on this item yet, so we need a big level-set before any code is committed. This needs to cover not just the immediate features of subflow instance properties, but also how this fits into the bigger picture.
There is also some related work from @nisiyama that could feed directly into this from a UI perspective. It may be there is already quite a bit of the UI code done - albeit not currently in the context of subflow instance properties.
As this roadmap item isn't the top priority right now, our focus has been elsewhere - so I've only recently (in the last week) added a placeholder Design note for it on our wiki, as is our development process for major items. (edit: given this response goes into far more detail than the Design Note, I'll be copying some of this onto the wiki to capture it in the one place).
As a major item on our roadmap, you'll forgive me if we take this slow given you are a first-time contributor to this project.
Some initial comments:
- 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.
Beyond this item on the roadmap is a follow-on item giving the ability to package a subflow as a redistributable node module. We have the Nodegen project that can do this for Function nodes. The eventual plan is to be able to publish a subflow to npm and have the runtime import it just as any other palette node. There are a number of major steps needed to get there, but a requirement of the Subflow instance properties work is to be able to auto-generate the published node's edit dialog.
Happy to continue this discussion; if you wanted to have a more direct chat on it, then the #dev channel on slack is a good place to start.
Nick
Hello @efratomer,
As @knolleary written, I was considering adding a feature to define UI for defining parameter input screen for Function/[Dashboard]Template node for ease of inputing parameters. @knolleary suggested that it would be better to think about integrating this to Subflow Instance Properties .
Following are figures of current prototype UI definition interface (detailed document can be found here).
As you suggested, it can use TypedInput for inputting values. Menu, checkbox, and label (not input value) are also supported.
I hope this will be useful for you.
3 Likes
Hi @knolleary and @nisiyama,
Thanks for your inputs.
Isn't this a must always? you need to populate this dialog anytime a user double clicks the node, no?
About @nisiyama's UI definition interface, it does look like a good fit.
I think only Edit Parameters tab should be available in the subflow template dialog and Input Parameters tab should only be available in the edit subflow instance dialogs though.
How can we go on from here then?
Hi Omer,
I'm not following discussions on Slack, so I was wondering if you got some kind of agreement meanwhile? This would be an awesome addition to Node-RED, so please keep on contributing!
Thanks for keeping us updated,
Bart
Hi Bart,
Unfortunately, this seems like a main feature down the roadmap as @knolleary mentioned.
I guess they prefer to tackle this in a more suitable time.
Omer.
Hey Omer,
Damn, I hoped you already had implemented 97% of this great feature 
Thanks for your feedback !
Bart
Hi Omer (@efratomer),
I don't know if you still need this functionality, but it seems that @nisiyama has been working hard lately to get this implemented: see pull request.
This new functionality has also been explained very well in the wiki. But I assume (???) this won't be merged anymore in the 0.20.0 version, so we will have be patient...
Wow! That looks amazing. Great job.
