IDEA - extend `function` nodes in `On Message` tab with a Test tab similar as we have for JSONata

The nice thing about JSONata is that we can test our expression via the Test tab (see screenshot below).
It would be cool to have the same feature for the node-red function nodes.

The idea is then that you can feed in an example message to the function node and that it will show its output in the Result window. I would not do this immediately as is done for JSONata but only after a button is clicked

I understand that function nodes can have side effects but I would mainly use this for function nodes that are pure functions.

Maybe there are other easy ways to test a function node that I am not aware. Then I am happy to hear about it.

... and yes, I am planning to use function nodes as my JSONata expression seems not very performant. :cry:

1 Like

That's an Interesting idea, but I see two difficulties. Presumably, the "example message" is exactly what the node input would see, but to be useful, the "result" needs to be something other than simply the output message. It would have to be captured at some point in the code, i.e., a breakpoint. Second, the result could depend on parameters that are not supplied by the input message, so there should be a way to control them.

I use a lot of node.warn() statements to inspect things along the way, and when that fails I sometimes add a temporary second output and use node.send([null,testMsg]) to send partial results for inspection. It can also help to inject messages with special flags (for example, msg.topic = 'test') and process them differently than normal messages.

The key thing with the JSONata tester is we're able to run JSONata expressions in the browser directly. But that does mean it will refuse to run if you try using the $global/flowContext or $moment functions that we add to the runtime version but are not available in the browser.

There is a limitless number of side-effects a Function could have beyond just generating a message to send. From the built-in APIs we have interacting with context, logging, accessing env vars. You then have the use of 3rd party modules that have been added to the function code. All of that makes it impractical, if not impossible, to do something similar to the JSONata approach and to evaluate the code in the browser locally.

That means have a mechanism to push code to the runtime, without deploying it, and to eval it without it causing any side effects to your actively running flows. That would be pretty hard to get right. And if we limit it to say 'no side-effects' then you're actually limiting to quite a small subset of functions people write. So you end up with a significant piece of UI in the editor that cannot be used in lots of cases. That doesn't make for a good user experience - teasing functionality they cannot use.

1 Like

Thanks for the extensive response and I follow your reasoning.
It is also clear now why $global/flowContext and $moment function can not be tested in JSONata tester.