I know it has been mentioned before - and probably will be mentioned again.
I am sure I have complained about how it works with the commands: SET CHANGE DELETE MOVE
Not wanting to make it more complicated, but I just realised a suggestion on how it is shown.
SET is used to set things. Yeah, fairly understandable. But I was thrown just now while doing something.
When working in function nodes you can context.set( ), flow.set( ) and global.set( )
These are used to set those variables.
If you are doing the opposite, it is get rather than set.
So, in the change node it is (can be) confusing.
I am wanting to flow.get("something") and save that to the ...... msg.payload.
But the selection is set.
It may be nicer if there could be a get option so the order the names are shown remains the same. This was another thing which was brought up in previous discussions, as set and move work differently.
Do I need to elaborate more on this idea, or is it already dead in the water?
As discussed in the past the node (change) *pushes the data from the bottom field to the top one.
So: flow.name is moved to msg.payload.
It all falls apart when you move. Then it is from the top to the bottom field.
I know brainy people can see around this.
But adding a get option would (maybe) increase that it always goes in a certain direction with the two fields.
Bottom to top would be better I think. It shows you who is getting changed then from where.
set and get would help with the understanding of what is happening too.....
I think I just shot myself in the foot. My inability to explain things.
But as I said, while I was working on a recent problem I got into a bit of a mess wondering how the msg.payload was changed when none of the change nodes had a get in them.
then the get would look like it applies to the msg,payload - when in fact it would be doing a msg.payload = flow.get("foobar"); which doesn't line up with @Trying_to_learn mental model ... so i think we'll leave it there for now.
The original one (without the red X's) bit me.
As it is/was it is settingmsg.payload from flow.name.
The new way would be getfrom.
So the directionality would remain.
The problem I have is (again) if I am doing that task from a javascript level.
It is flow.get (ignoring the flow part).
But using the change node: irrespective of which way the data is going it is always set.
I am sorry. I was just not thinking straight (or in the right mindset - maybe) and it stuck out to/for me that there is this disparity in how things are done.
I don't believe I have actually expressed this aspect before. (Ok, maybe I did.) So I thought I would mention it and see if while discussing it that things would fall into place.
I'm not sure that has happened. But I don't want to argue for the sake of arguing. That's just silly.
definitely time for a break... !
