I feel this is dead simpe but my minds gone blank
I want to capture a complete msg object to re-use it for debugging purposes in another flow
So I thought - lets send it to global.whole
And then I thought - em - how do I do that
And then I thought - is this even the right way to do this!
help please
1 Like
I too have been stymied by the TypedInput fields NOT allowing access to "the complete msg object", like the debug node option... in your case, it would be nice to be able to use a change
node to set a global var to be the incoming msg object, or define the whole msg object in an inject node.
In the meantime, I don't see why you cannot do this in a function node:
global.set("whole", msg);
return msg;
... but tbh I have not tried it -- and i'm not sure whether reusing it later with its internal fields intact (e.g. _msgid, req, res) is even a good idea. But hey, I can only load the bullets... you'll have to shoot your own foot. ;*)
4 Likes
Glad to find this posting. At least I only smashed my head into a wall trying things in the change node like:
msg.*
msg.$
msg.$$
{nobody try this stuff - it doesn't work)
for 15 minutes or so before finding this posting.
This is almost as surprising as node.log{"WARNING WORLD: node.log doesn't write to that debug area on the right hand side that you probably thought was the log"}
Thx guys.
. At least I only smashed my head into a wall trying things in the change node like:
msg.*
msg.$
msg.$$
{nobody try this stuff - it doesn't work)
What are you trying to do ?
$
and *
are valid if you use JSONata.
I would like for the simple nodes like Change to support a TypedInput field of "the complete msg object", just like the debug node does.
JSONata is amazing but like REGEX, and to a lesser degree SQL Queries, and even javascript - it takes a much higher level.
My personal goal is to make useful things/applications with tools that I can come back to 3 years later and "remember". JSONata and Regex have proven to me to not be that kind of thing. Relearn, re-remember the tricks.
No rip on those powerful tools - just too powerful for the "every 3 year" visit.
I use the well know JSONata (the stuff that pops up in search right away and copy/paste done).
I would pay a JSONata expert for something I needed solved commercially. I am always impressed by the JSONata blackbelts that can do anything.
I'm just trying to keep it simple wherever possible and stick to the native node functionality - or subflows of native flow functionality - as an experiment in simplicity.
1 Like
I would like for the simple nodes like Change to support a TypedInput field of "the complete msg object", just like the debug node does.
I agree that JSONata needs some regular use to understand complex queries, but to access properties that are outside msg.payload, it is quite simple.
Let's say you have an msg:
{"result":"ok","payload":""}
To access result
in the change node, you can set msg.payload to JSONata and simply put result
in the input field. Or if you want to capture everything into a new property you can use *
1 Like
It was nice to learn that * gives an array of the values of all the properties of the message (since I didn't know that) but its not a solution to getting the whole message since it loses the key names
@jtmoderate876 For completeness sake, it could be added to the bottom of the TypedInput fields, but is the effort worth going to for the rare times its needed?
I think that the problem is that assigning the msg to a a property of the msg creates potentially circular references. JSONata tries to prevent that.
If, however, you assign to a flow variable then you can do it directly:
You could always use a second rule to assign the flow variable back to the msg.
However, a big WARNING is required. Be careful what objects you do this with. For example the output of an http-in node is very large indeed and has may circular references.
Of course, this also works. A function node:
msg.new = RED.util.cloneMessage(msg)
return msg;
Same warning applies.
2 Likes
And now I've learnt that $ returns the whole message object
1 Like
True -- but only for this case, since it's the first symbol in the expression!
In reality, $
represents the "current context"... so if you want to reference the root of the msg
object, you would use $$
instead.
There, now you have learned 2 things! Heh heh... ;*)
2 Likes
And if you need to access what you sent a week last wednesday, send $$$$$$$$$$$$$$$$ Well, maybe one day.
1 Like
Arguing above my pay grade here but ...
... under what circumstance (in Node-RED) would $ not get the whole message object?
If you send me $$$$$$$$$$$ I will send you whatever msg you require
3 Likes
If you are deeper into the msg object hierarchy then $ refers to the parent of your current position. At that point you would need to use $$ to obtain the top level object. $$ always points to the top-level object.
Simples!