The lack of any form of
dynamic option indirect definition (?) in subflow input interface is, for me, sometime a big limit.
More useful (from inject node):
My personal 'workaround':
Rule: if a string starts with '@' then it is replaced by the result of eval(substring(1))
Code inside the subflow:
var xvalue = env.get("value").toString().trim();
xvalue = eval(xvalue.substring(1));
xvalue = env.get("value");
Of course it is not perfect, but it works
Any better solution waiting an upgrade of the 'subflow' properties interface?
Not 100% sure what you are doing here?
Do you have an example of what you send in
value? Then what does it
Lastly, why not simply pass values in
The subflow properties are statically evaluated when the flow is started. They cannot be dynamic.
If you want to pass in dynamic values, using the msg you pass in.
@Steve-Mcl, Use case:
global.set("user_defied_config", "foo"); (e.g. using node-red-contib-config, works in 'On Start').
my_subflow( "@global.get('user_defined_config')" ) ( replaced by 'foo' )
my_subflow( "bar" )
@knolleary thanks, clear argument, but for me it is not a case of dynamic evaluation, but of (quasi-static) indirect definition.
Or not? i.e. the unique solution is my workaround? (it allows a dynamic evaluation).
Why not insert some new code into the subflow interface, to also accept [global.] [flow.] [J:expression] [timestamp] ?
Similar limitations are present in many "contrib" nodes, where the programmer too often just uses [text] .
In conclusion, the limits imposed on the subflow, if they are a deliberate choice, are unreasonable and harmful.
see an implementation here
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.