If this is the case, how much extra processing / memory does this consume?
Would it be more economical if the debug node had an output and could optionally be inserted in a wire as the junction node can?
As well as (potentially) being more efficient, this offers less visual clutter in flow diagrams.
A new right click, insert option to insert a debug node (initially with label hidden) would speed up inserting debugs and complement the existing right click, delete & reconnect to delete.
Note that the debug node has the turn on/off switch - pass the message through regardless of this and the normal enable/disable config option - block the message if it disabled.
A promising new node log-io had this inline mode ([Announce] node-red-log-io - #21 by Steve-Mcl) but the author removed it as they were unsure of its value. I explained how it is a benefit for larger payloads (to avoid cloning) and the author is considering adding it back in.
Of course it's been considered before! Thanks for the link.
I was considering the visual provision of both switch and output connector (nexus?).
It certainly does not look very elegant for the wire to visibly run through the switch, though it does perhaps emphasise that this nexus is wired up.
An alternative i considered was for a new node type, basically the same appearance as a junction except for the colour (just as all nodes have their characteristic colour).
Either have the colour reflect the debug/passthrough settings or use a normal status indicator below the node.
To be honest, I'd settle for an intermediate where the debug node gets an extra flag. If set, it looses the switch and gains an output. I think this would cover the vast majority of cases since you can already effectively turn off output by not selecting the option in the settings.
That would surely be a quick and easy change and would be fully backwards compatible as the new setting would not be the default.
Mostly I agree as it's visually much better... (hate the button plus link on top... uurgh) - but then it would be always on sending to the log with no way to turn off apart from unwiring.
I also like the idea of a new type of debug node - as per @jbudd - junction like node - (lets call it a test point ) - it could have an option to only write to the debug log when hovered over... (like a probe in an elec circuit).
I'm not saying hover should be the only mode of operation - click on and click off also a totally valid configuration. But yeah - most of the work I do does not require many inject nodes - lots of streams of live data instead.
Also click on/off would require saving of state - so would trigger the deploy button (may not need to deploy but) - whereas hover would be stateless and not flag a deploy.
This topic has come up many times. I do agree an improved debug node - of some sort - would be beneficial. Being able to 'attach' a debug probe at any point in the flow. I think it may be some new UX capability, rather than the "normal" node UX.
The current model of debug node doesn't avoid the cloning overhead; the button on the node just mutes it rather than disables it, so the node still has to receive its copy of the message even if it then does nothing with it.
Not getting your drift with that ? Why does it need to be right click ? (bad for touch screen) . Why not just click on/off like existing button... just in this (test point) case the whole (small dot) is the switch/hover target.
If I click a wire while editing and it's currently "live" with 1000 messages a second the editor would get swamped... and wires don't have properties so it would would a global setting... all wires or no wires .
) - it could have an option to only write to the debug log when hovered over... (like a probe in an elec circuit).
