to be fair - that is indeed (yet another) a subtlety of javascript. If the object is an object it's easy to add/edit/remove properties. If it's a type like a number or string (or boolean) then that can't be assigned extra properties so trying to add them will fail.
and
It got me thinking...
Node-RED nodes "hide" engine room stuff from us users, so maybe the change node should just go - ok - you want to set msg.payload.chatId - I'll just do that (even if means wiping the current payload because its not an object)
Now, from the point of view of a JS programmer - that's just plain wrong but maybe its actually the right thing to do for Node-RED ?
2 Likes
Indeed - not an unreasonable thought....
2 Likes
It has always seemed odd to me that if msg.payload includes a number then in a Change node you can do Move msg.payload To msg.payload.data but not Set msg.payload.data To msg.payload.
... Or just set the inject node to default be a Json object.
I have never played around with Json object before, however it was quit clear how it worked (msg.payload.topic.data.etc). It was also described in the message tutorial. Therefore I thought that when I made and injectnode with the data address msg.payload.somedata and then choose it to be an int, then 'somedata' would just be stored as an int in the Json node and then later I could use the change node.
If it was default set to be a Json object, then I would probably never have thought about changing the variable type. If not set it to default, then at least have the Json format be at the top of the drop down curtain, when it's at the bottom it seems that it is something one would rarely use (at least to me anyway). And lastely there could be a warning in the log, that would also have been nice (however I do understand that this might be difficult in keeping it one-to-one with Javascript)
But this is only nice to haves, I am still pretty stocked about node red.
