I've recently been trying to make a flow work with parameters (instead of writing a function) but I can't use Change nodes this way
The switch node alllows for JSONata and $env
but not the change node
Does it make sense to have it in the target field? That implies that you want to have a dynamic setting for the target property?
It is available in the value field.
Thats exactly what I'm after
I want to make the set parameter variable
If you look at the switch node example - I'm wanting to switch on flow.xxxxx.state.
So the JSONata lets me assemble that using msg.payload.description to hold xxxxx
You can do that if your top level flow item is an object (which is better for management anyhow IMO (since you can clean up by simply deleting the top level object)
[{"id":"740355cdbad61e1e","type":"inject","z":"8a88fee08ad63069","name":"{\"description\": \"a\", \"state\": \"on\"}","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"description\": \"a\", \"state\": \"on\"}","payloadType":"json","x":470,"y":60,"wires":[["8498cb3e0ed1216c"]]},{"id":"8498cb3e0ed1216c","type":"change","z":"8a88fee08ad63069","name":"","rules":[{"t":"set","p":"states[msg.payload.description].state","pt":"flow","to":"payload.state","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":850,"y":120,"wires":[[]]},{"id":"cb764fec26a035c6","type":"inject","z":"8a88fee08ad63069","name":"{\"description\": \"a\", \"state\": \"off\"}","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"description\": \"a\", \"state\": \"off\"}","payloadType":"json","x":470,"y":100,"wires":[["8498cb3e0ed1216c"]]},{"id":"ea9c9c96636852bd","type":"inject","z":"8a88fee08ad63069","name":"{\"description\": \"b\", \"state\": \"on\"}","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"description\": \"b\", \"state\": \"on\"}","payloadType":"json","x":470,"y":140,"wires":[["8498cb3e0ed1216c"]]},{"id":"0cdaafd274c2cf8d","type":"inject","z":"8a88fee08ad63069","name":"{\"description\": \"b\", \"state\": \"off\"}","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"description\": \"b\", \"state\": \"off\"}","payloadType":"json","x":470,"y":180,"wires":[["8498cb3e0ed1216c"]]}]
2 Likes
I foresee lots of people getting into trouble with that though unless some additional validation were done. Because JSONata can output any structure not just a single string.
Well - you want to see what mischief people can do with a function node! 
I know - I've done it!
But the point is more that people with limited coding knowledge may use the suggested feature, with function nodes, you are already in the weeds. A matter of perception I know, but still - just sayin.
The difference is:
For JavaScript, there are over 17 million folk who can help you out
According to the survey, the size of the JavaScript programming language community is roughly 17.4 million software developers as of 2022, making it the most popular programming language in the world.
Where as JSONata doesnt even figure on any of the charts! (insignificant)
Its syntax is (forgive me) awful, and (IMO) really hard to grasp. Last but not lease, an order of magnitude slower to execute (sometimes 1000+% slower - I can post proof if need be).
I guess, in short, I am saying there is little logic in avoiding a function node when there is not a core or contrib node available to do a task.
PS: Simon, I have not forgotten your distain for Function nodes 
So close!!!!
I didn't think about using []notation
But unfortunately - it doesn't allow the [] as first part
I could probably workaround that by changing all my flow state context names to state.xxxxx
But it'd be nicer in future to have option of using [] without need for prefix
See 
As you've said - I'm a low-code evangelist
I don't like using JSONata even - if the [] worked 100% - that is a much cleaner better solution
And how would I do that dear Henry?
3 ways.
- Via the editor
- a change node
delete flow.states - a function node (not even gonna bother telling you how tho)
That can clean up ALL your states in one easy go - as opposed to having many individual flow entries to delete.
I think you've forgotten that I'm trying to do this programmatically using msg.description to hold the flow context name in question
and without resorting to 3.
Is there a fundemental reason that we can't use
flow.[msg.payload.description].state
or could a little tweak be applied inside NR to allow its use?
Not at all. Just have an upper level object to hold all your stuff. There is no difference after that - just that you gain the ability to use [] and the ability to easily clean up. There are other advantages too (I wont go into)
The point was it is possible without JSONata or this feature request.
What is not possible is accessing top level flow/global values dynamically.
No other reason than current implementation.
for anyone following along, yes, I realise that flow.[msg.payload.description].state is invalid - but that is mealy an implementation detail.
2 Likes
To be clear - it is a reasonable request IMO
2 Likes
I hear you
I've changed my pattern in this project (its my Cheap Yellow Display project) to use it
2 Likes
flow. msg.
the upper level adds the dot.
So the syntax is therefore wrong when you add [...]
If the dot could be omitted it would work.
