Sure if you use the wrong function.
$floor($random() * 100)
Sure if you use the wrong function.
$floor($random() * 100)
To be honest... while I see the benefits and flexibility about this feature, I'd be careful.
It is just yet another way of doing something, that could already be achieved by using the function
node.
Once people start putting more than a one-liner in there, things get messy and unmaintainable, can have unclear side-effects, etc...
Simply allowing for complex expressions in a single field of a change
node kind of defeats the benefits of Node-RED as a visual programming tool. Simply put: The presence of a function
node makes that fact visually clear to me, I know, there's a piece of (complex) Javascript in there. On the other hand, a single field in a change
node doesn't.
A tale from my own experience (a long time before Node-RED): I once integrated a simple expression language into a Java application to allow some user flexibility without the need to touch the code every time. The "creativity" of my colleagues for misusing such things was (and is) endless in that regard, once you gave them the necessary means. You couldn't imagine the (evil) things they created with it...
Just my gut feeling about this...
That's human creativity in action!
Leaving off any bias, this leads to the story of the knifes. People have to learn which end hurts - either by being teached (not just told!) or by personal experience. Yet as we all know, despite this latent danger, we're still using knives - and are occasionally extremely proud when they are laser sharp.
Additionally - e.g. if you're in a production environment - there's always the option to switch off this feature. Alternatively, it might be an idea to opt in
this functionality - as it's already the case with a number of others.
Agreed. Still it might be an efficient way to do things - and it's already done:
BTW, this shows up in the editor as
To quote Scotty from Star Trek: "How many times da I have to tell ya...the right tool for the right job!"
I should add, I'm not a big fan JSONata either. Yes, it's powerful for accessing/transforming your data, but complex and time consuming if you don't use it regularly. So the function node using plain JS is my go-to tool in these cases.
And it faces the same issue regarding one-liners vs. complex expressions. Not ideal for creating maintainable and comprehensible flows.
I'm seeing a lot of interesting ideas here, as well as some that are definitely not "node-red" style compatible. Plenty of things being suggested could be done with existing nodes/subflow/link nodes and be just as, if not more tidy. I would, however, really like to be able to use object prototypes from the change node. setting msg.payload to msg.payload.toUpperCase() is a great example. I know this can be done in a template node, but if you're doing a small chain of changes to one property, doing it in one change node is nice. My $0.04 (accounting for inflation)
Been thinking about things and now agree with @TotallyInformation that good idea to have this in inject as well as switch and change nodes
If it makes it into the typed input as a standard piece like JSONata, then it should become available everywhere that uses typed input with a simple change to add the new type to the list of available ones.
So the main thing is to get it into core, updates to nodes - while nice to have all the core ones updated together - don't all need to happen at once if resources aren't free to make the changes.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.