Suggestion about `change` node. Re-think

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:

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?

1 Like

How would it read in the config ?
Get. flow.something ...
I can’t see a simple phrasing that works compared to Set ... to... and move... to...


To me it should say Get not set.

If I was coding in JavaScript it code would be:

msg.payload = flow.get("name");

As discussed in the past the node (change) *pushes the data from the bottom field to the top one.
So: 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.

It is intended to read as:

Set [top option] to the value of [bottom option]

If they were flipped around, you would no longer be able to start the sentence with "set".

1 Like

and if it was flipped and labelled to say

Get [ msg.payload ] from  [ flow.foobar ]

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.

Well, not really.

get msg.payload (from) works.

And from the picture (screen shot) it would still work.


I am more confused now.

Yes, new picture.

The original one (without the red X's) bit me.
As it is/was it is setting msg.payload from

The new way would be get from.
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.

I'd better stop now.

Thanks @dceejay and @dceejay.
Sorry for the confusion.

:slight_smile: definitely time for a break... !

1 Like



(I can't believe I've been coming here for 2 years! And the google group before that!)

You'd have thought that in that time I would have learnt something. :wink:

1 Like

Hey Andrew - if you shift to using @BartButenaers Blockly node, then you can have the best of both worlds :slight_smile:


Removes all ambiguity :slight_smile:

1 Like

Yeah, I've seen it and read about it.

It is something I may get done one day.

I'm just not confident enough just yet to do it.