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.

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 msg, context, etc, the same as for the JSONata option.

For many uses where you need to do something dynamic, currently, the only options are to resort to a function node or try to grapple with JSONata in a change node. The suggested change would enable people to make simple dynamic changes without either of those.

Thoughts?

1 Like

The problem is you end up with two different places to put JavaScript code, and the requirements/capabilities are very different between the two.

For example, we would not allow calling node.send() from the Change node. Nor would we want the code to cause other side effects, such as calling flow/global.set(). You wouldn't be able to import other modules etc.

My concern is that leads to lots of confused users who are given some example code to try, then try using it in the wrong place and it not working because it was meant to be used in the other place.

Good points of course. Perhaps the most important being the one about side-effects. Not providing the RED or node objects would help but blocking the context/flow/global .set functions might be more complex.

I think though (without having tested) that node.js's vm enclosure could be used to provide sufficient isolation to prevent side-effects?

As for confusion between a function node and a JS change option. I get that it could be somewhat of a thing. But I'm not sure that it would be a big issue? A different UI in the change node would help I think so that there are clear visual differences.

I do believe that this would be a valuable addition to the change node and would certainly reduce the number of function nodes in use and in many cases, avoid the complex forum discussions that can happen when we advise people without much JS experience to use a function nodes just for a simple msg variable adjustment.

Perhaps some experimentation needed to see whether the idea is viable.

1 Like

Personally I don't see the complexity being "Use a Function node with this code...". The code itself is where the complexity would be, and being able to put that code in the Change node doesn't really affect that.

In fact, I think it risks making those discussions more complex as people share JS snippets in the forum and user's don't necessarily know if it was intended for a function node or change node.

1 Like