When creating a subflow and editing the properties, you can configure the type of input it can have. The choices are Input, credential, select, checkbox and spinner config node. So, I select Input as the type.
However, when using the subflow, I want to populate the value using a context variable, the choices for input are only string, number, boolean, JSON, buffer and envi_variable.
Why are context (flow and global) available as choices? What this means is that I need to go through the extra step of placing a change node before calling this subflow, just to retreive the global or flow value and set an environment variable. I should be able to just be able to use the glowbal or flow values directly. Am I missing something?
Ideally, when using a subflow, you should be able to use context values and jsonata expressions in addition to the other input types.
Is there a way to do this? Am I just missing something?
OK, that makes more sense on how things work now. I hope that this can change in the future. It would be nice to be able to use context variables and Jsonata inside a subflow via the settings page for the subflow.
It's just that if you only need one value passed in as a message property, you might as well have everything configured that way and forego any properties as you don't want to split the methods for setting data in the node. It would be confusing to have to set some properties in the properties page and send others in as a message property.
It would be much cleaner to add context and Jsonata expression support to the options page. Then everything you need could be set there.
I am wondering if you can set environment variables using a function node rather than a change node from outside the subflow. It looks like Node.js supports this with a process.env.MY_VARIABLE = 'my_value' call. This would only work if NodeRed reads environment variables at the time of use rather than at initialization. Otherwise it won't work.
I'll test this out but for now, I think I'll have to switch entirely over to passing in configuration options as flow properties and not use the properties page at all.
If you want to use different context variable names for each instance of the subflow then you can pass in the context variable name as a string and then use that when you get the variable in the subflow.
