[Feature Request]Allow one-liner JavaScript as well as JSONata

[cymplecy]

JSONata main use in NR is to just perform a little manipulation of data to save having to write a function node

But its syntax is not well understood by most of us (@E1cid is the exception ) whereas even I can google to find a JS function to do most things

So lets add it to options

[TotallyInformation]

I like that idea!

Would need a little care to make sure it didn't introduce some nasty security issues - executing raw code input by a user is always a little fraught

But should be possible.

[jbudd]

Not just one-liners though please, that way lies excessively cryptic code!

[cymplecy]

@jbudd

Not just one-liners though please

And we already have feature request creep!

[E1cid]

Not sure on this one, maybe certain Javascript functions like reduce, map and filter.

Did see this has been requested before.

Change node enhancement idea: Add JavaScript function as a change option

Fresh back from holiday and looking at the change node something dropped into place in my mind about a slight frustration with it. We now have lots of nice options for the change node but I think that an obvious one may be missing. [image] Why can't we have a simple JavaScript Function option that opens a JavaScript editor? The idea being to end the function with return xxxxx that would be the output for the change. Of course, we would also need some variables being made available such as m…

[TotallyInformation]

Seems like others will need to make a stronger case than I did back then.

[marcus-j-davies]

Warning : The following suggestion contains content that some viewers may find offensive/or just dam right silly!

I was thinking out allowed

( it can, and should be ignored)

[knolleary]

One of the reasons I haven't personally pursued it is because of the complexity of keeping it simple.

Would we allow any valid JavaScript? Could it be 100s of semi-colon statements long all in a single line of text? Would it expect to have access to all the standard APIs (node.send()... flow.get()... etc etc) and allow the side-effects they can have?

What semantics would be allowed?

All of these things can be answered, but they need someone to come up the answers and propose something fairly concrete.

[jbudd]

I know you won't like this but I imagine let's call it a Node-red helper app, external to Node-red, to which code snippets and data could be passed.

It could be javascript, csh, powershell, perl, etc.

Node-red would not need to parse the code at all, just pass msg.payload and probably msg.topic.

Define the pathname of permitted helpers in settings.js.

Any node which currently accepts Jsonata could be extended to use helper apps.

[cymplecy]

Well I'd start it off simple - single line with ability to access msg and context properties.

I'm just seeing it as a JSONata replacement - to do the little things that don't warrant a separate function node before or after a switch or change node

[E1cid]

You mad scientist

To join in -
How about calling context functions with ability to send msg to it?
You could then add JS functions in the context vars

maniacal laugh.

[TotallyInformation]

@jbudd

I know you won't like this but I imagine let's call it a Node-red helper app, external to Node-red, to which code snippets and data could be passed.

This can already be done in several ways though both through external services and through an external code module linked into globals. This approach would really add complexity and potentially create tightly coupled systems which isn't a good design pattern.

@cymplecy

Well I'd start it off simple - single line with ability to access msg and context properties.

I agree. Search for and replace anything from a semi-colon onwards in the code and remove it before saving, also limited to a sensible number of characters - 255 should be more than enough. Execute in a node.js VM for safety. Some overhead to that but a lot less than JSONata. Allow setting into a single "thing" as with other options. Attach to a return statement so users don't need to remember that and cannot not use it.

Some additional complexity could be allowed in future releases as utility was proven and requests clarified and it might even get to a point of allowing similar complexity to JSONata eventually complete with an editor but that would be considered over time. Start with a simple MVP.

[krambriw]

@jbudd

let's call it a Node-red helper app, external to Node-red

And I am using Python for that, works pretty good, powerful enough, with MQTT as api

[ralphwetzel]

@TotallyInformation

@cymplecy

Well I'd start it off simple - single line with ability to access msg and context properties.

I agree. Search for and replace anything from a semi-colon onwards in the code and remove it before saving, also limited to a sensible number of characters - 255 should be more than enough. Execute in a node.js VM for safety. Some overhead to that but a lot less than JSONata. Allow setting into a single "thing" as with other options. Attach to a return statement so users don't need to remember that and cannot not use it.

Wouldn't that mean to invest energy & time into a "limited" something that'll soon initiate an "I would like to see this & that feature as well" discussion?

I'd like to propose to

• re-use the existing sandbox of a function node (almost) as it is
• remove just the msg passing ability (send() & done()) ... and perhaps some (very!) few functions more, based on more in-depth considerations
• take the return(ed) value for further processing in the change rules.
• keep the timeout in case someone intends to do heavy async jobs in those functions.
• re-use as well the editor element of the function node
• add a flag in settings.js to enable/disable this feature.

We'll end up with a great & powerful processing tool inside the change node.
Cons? To be discussed...

[cymplecy]

@ralphwetzel

We'll end up with a great & powerful processing tool inside the change node.

Which is not what I'd like
I just want to be able to do the sort of little JSONata things that I currently do but without having to ask @E1cid how to do it first

If I want complex - then even I'm OK with using a function node

i.e in the Blockly node (which is what I use when I want to write functions) there is a simple JS block

to let me do something that there isn't a pre-defined Blockly block can do

and that's all I'm really wanting to use in a change/switch node

#KISS is my motto

[ralphwetzel]

@cymplecy

and that's all I'm really wanting to use in a change/switch node

Very fair.
I'm sure that's 100% possible with the setup I proposed.
You'll never be pushed to go complex...

[TotallyInformation]

@ralphwetzel

Wouldn't that mean to invest energy & time into a "limited" something that'll soon initiate an "I would like to see this & that feature as well" discussion?

Yes, but often best to get something minimalist and solid through the door than having to wait months/years for someone to have the time and energy to implement something complex. Also gives time to get things right. Deliver early, fail fast is a common mantra for complex designs.

@ralphwetzel

I'd like to propose to

All reasonable things to consider for sure.

[ralphwetzel]

@TotallyInformation

Yes, but often best to get something minimalist and solid through the door than having to wait months/years for someone to have the time and energy to implement something complex.

Exactly!
That's why I proposed to re-use something that's already existing and proven for years, rather than investing in a new feature, especially of limited capability.

[ralphwetzel]

@cymplecy

I just want to be able to do the sort of little JSONata things that I currently do but without having to ask @E1cid how to do it first

I've put together an early PoC of how this could look like:

Caution: Currently not at all optimized or (tested to be) stable, just a playground to inspire discussions. Thus e.g. ignore the red borderline!

If of interest, this node (prototype) needs to be installed from GitHub:

npm install https://github.com/ralphwetzel/node-red-change-plus.git

[jbudd]

@TotallyInformation

@jbudd

I know you won't like this but I imagine let's call it a Node-red helper app, external to Node-red, to which code snippets and data could be passed.

This can already be done in several ways though both through external services and through an external code module linked into globals.

Can you explain more about external services and external code module linked into globals?

Here is an example, not javascript but Bash, which I can run via an exec node but I would like to run from a change node or elsewhere.
To meet the requirement for a simple oneliner I have crammed it all into one line

printf "\\n{frequency: %d, temperature: %d}\\n" $(vcgencmd measure_clock arm | sed -E 's/(.*=)(.*)/\2/') $(vcgencmd measure_temp | sed -E 's/(.*=)([0-9]*)(.*)/\2/')

Note that I'm not suggesting Node-red understands or verifies this, just hands it off to a helper app - Bash.

@TotallyInformation

This approach would really add complexity

Nope, it would really add the ability to stitch together Node-red, legacy code and OS utilities while maintaining source code within Node-red.

@TotallyInformation

and potentially create tightly coupled systems which isn't a good design pattern.

Yes that's probably true. Mind you, I am not sure that complex Jsonata should be allowed in a good system design either.