Hey Guys! o)
It seems we can use env vars to set node-properties, like described here:
[https://github.com/node-red/node-red/wiki/Design%3A-Using-environment-variables]
Nice, but ENV vars only? Wot? o)
Aren't global/flow context vars and message objects the first class citizens in node-red?
In my flows I'd like to configure node settings in one place, like email-hostnames, mqtt-prefixes, ip-addresses, filesystem-paths etc. Right now I need to pick dozens of nodes and edit them manually after deploying the flow in another environment, this is error prone and arrg. o). I came across the "contrib-config" node linked below, it manages to get the "central editing" done, but now we still have many nodes which do not support input messages for configuration (some are starting points of sequences, some just don't look at "msg.server" e.g. (like the email-out node).
Solution?
Wouldn't it possible to support a placeholder syntax for input fields in the node editor to inject context and/or message variables as well (like its possible for ENV vars already)?
- ${global:foo}
- ${flow:bar}
- ${msg.foobar}
- ..basically any sane syntax will do! o)
Example:
For "Server" text input field in the email-out node I'd simply enter ${msg.myhostname}, if I want the email server to be set via incoming message or I use ${global:mysettings.email.hostname} if I want to use some value from my "central point of configuration"-object.
Advantages:
- dynamic input for nodes which do not accept input message at all (mqtt-in etc.) or for which setting an important property via message is not supported (like msg.server for the email-out node).
- less clutter in sequences/flows
(many function/change nodes only setup the upcoming node, no real flow-functionality added) - avoid node forks
(I had to fork the "watch" node to allow dynamic folder input e.g., I really don't wanna do that for the email-, mqtt-, http-nodes etc. again, since nobody will ever update them.)
ENV var disadvantages:
- they cannot be edited/maintained in the node-red editor easily
- they do not export with the flows
- they do not handle flow restarts/resets well
- creating/changing them dynamically within a flow is questionable and creates extra clutter
(if all you want is to use them with the placeholder syntax)
Below is the link to the node-red-contrib-config node I mentioned above. Setting up and resetting global/flow objects and variables right before a flow starts is easily done with that, so half the solution is already there.
[https://flows.nodered.org/node/node-red-contrib-config]
Thank you for your attention! o)
tb19
