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

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 :slight_smile:

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 :slight_smile:

But should be possible.

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

And we already have feature request creep! :slight_smile:

1 Like

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

Did see this has been requested before.

1 Like

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

1 Like

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


I was thinking out allowed :grin:

( it can, and should be ignored)


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.

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.

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

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.


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.

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.


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


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...

1 Like

Which is not what I'd like :slight_smile:
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 :slight_smile:


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

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.

All reasonable things to consider for sure.


Exactly! :+1:
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.

1 Like

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! :wink:

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

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


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 :rofl:

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.

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

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