JSONata in subflow interface

The lack of any form of dynamic option indirect definition (?) in subflow input interface is, for me, sometime a big limit.

Subflow interface:

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();
     if (xvalue.startsWith('@')){
          xvalue = eval(xvalue.substring(1));
          } else 
         xvalue = env.get("value");

Of course it is not perfect, but it works with strings.
Any better solution waiting an upgrade of the 'subflow' properties interface?

Best regards

Not 100% sure what you are doing here?

Do you have an example of what you send in value? Then what does it evaluate to?

Lastly, why not simply pass values in msg.xxx?

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:
in a__flow:
global.set("user_defied_config", "foo"); (e.g. using node-red-contib-config, works in 'On Start').

in b_flow:
my_subflow( "@global.get('user_defined_config')" ) ( replaced by 'foo' )
desirable alternatives:
my_subflow( [global.]user_defined_config)

in c_flow:
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.