Is there a way to comment out some nodes as we could comment some part of code to check the difference and for debugging ?
just remove any wires to their input.
I’m palying with this node
[{"id":"9407a47e.069a38","type":"ui_template","z":"aa8f5fa1.bc60d8","group":"c519da4c.f6bf9","name":"Logo / Clock","order":0,"width":0,"height":0,"format":"<script id=\"clockScript1\" type=\"text/javascript\">\n var clockInterval;\n $(function () {\n if (clockInterval) return;\n\n //add logo\n var div1 = $('<div/>');\n var logo = new Image();\n\n logo.src = '/logo.png'\n logo.height = 45;\n div1[0].style.margin = '10px auto';\n\n div1.append(logo);\n\n //add clock\n var div2 = $('<div/>');\n var p = $('<p/>');\n\n div2.append(p);\n div2[0].style.margin = '5px';\n\n function displayTime() {\n p.text(new Date().toLocaleString());\n }\n \n clockInterval = setInterval(displayTime, 1000);\n\n //add to toolbar when it's available\n var addToToolbarTimer;\n \n function addToToolbar() {\n var toolbar = $('.md-toolbar-tools');\n \n if(!toolbar.length) return;\n \n toolbar.append(div1);\n toolbar.append(div2);\n clearInterval(addToToolbarTimer);\n }\n addToToolbarTimer = setInterval(addToToolbar, 100);\n });\n</script>","storeOutMessages":true,"fwdInMessages":true,"templateScope":"global","x":341,"y":81,"wires":[[]]},{"id":"c519da4c.f6bf9","type":"ui_group","z":"","name":"Default","tab":"c63bab3.e433ad8","order":1,"disp":false,"width":"24","collapse":false},{"id":"c63bab3.e433ad8","type":"ui_tab","z":"","name":"Home","icon":"dashboard"}]there is no wires but it’s seems to be still active !
Removing the wires will stop a node receiving messages, but some nodes will have side-effects just being present in the workspace - such as the ui_template node.
The only way to remove it from having any effect is to delete it. There is no way to disable individual nodes.
An alternative is to add a new tab, edit its properties to disable it, then move any nodes you want to temporarily disable to that tab - so you still have it around, but its on a disabled tab.
1 Like
@knolleary
Yes, that’s what I did till now, despite not very fast ad easy.
I find it amazingly idiotic that you can't disable. One simple checkbox would do it, then it is greyed out:
What would you want to happen on the outputs of a disabled node when it is passed a message?
Absolutely nothing. Drop the message.
Adding a "checkbox" does nothing, code has to be written to actually implement it, then again I wonder what benefit such a feature has.
Free tip: work on your communication skills for a more productive conversation.
4 Likes
So you have to double click node, find and click checkbox to disable, click done to close dialogue, click deploy. Compared with click wire, click delete key, click deploy. Seems like more effort not less. And assumes all nodes (including all contrib ones) are rewritten to include such a checkbox,
I have often wished there was a "comment out" / "link out" / "disable node" feature but never managed to get my head around how it would work.
Lets face it it, deleting wires is a not ideal.
What I do sometimes is use a flow or global var & a function node added into the path of the item i want "linked out". What happens in the below is when "linked out", the msg is prevented from reaching "Destructive operations"...
Idea...
What about a simple toggle node that permitted you to enable/disable a wire? Perhaps it could have 2 outputs to further assist debugging (by permitting a user to route a message down a TEST PATH)?
Yes I know it wouldn't handle things that have an affect by simply being in the flow but for msg routing problems / simple trials, something simple like this - built in (not a contrib) would be pretty useful?
You mean like this ? https://cookbook.nodered.org/basic/route-on-context
No. I mean like an inline switch. Specifically designed for aiding troubleshooting.
Like my example without the inject part or flow var.
Imagine a node that you placed inline with nodes that had a toggle switch. I.e. you click the node to toggle it
It's just a suggestion but I have wished for something like this many times.
all good thoughts and ideas. Keep them coming.
Is it really not possible to include the ability to disable a node for ANY node, just like the new switch that allows to hide/show ANY node's caption ?
Regarding what to do with the message, it could be either dropped (blocking state) or passed on without running the this.on('input', function() ... ) that is common for all nodes AFAIK (ghost state).
Indeed, it would be nice to disable a wire/node temporarily (e.g. for troubleshooting/testing) without having to change/deploy the flow.
- Disabling a node (without deploy) could be hard to implement, since that node is already started (and isn't aware that it has been disabled). E.g. when my node-red-contrib-msg-resend node is disabled, it will just keep resending older messages (that have arrived before you disabled my node).
- Disabling a wire might perhaps be little difficult to implement at the moment, because a wire has no properties. Perhaps possible in the future, when the wires become pluggable?
P.S. The 'idiots' in the above screenshot, is that a new nickname for the entire Node-RED community?
@tilleul - hmm actually yes it could - on the appearance tab, as that is generated by the core not the user.
Passing a message on without doing anything would not make sense in most applications as the following node would then receive input it wasn't expecting. If this was implemented I would expect it to be a drop/block when disabled.
I was aware of this (i think @knolleary mentioned it in a similar thread) & is partly the reason I suggested an inline (clickable) switch. It may not be a "node disable" or the "best solution" but at a guess, it would satisfy most needs.
How it would operate and mix with other "toggle wire" nodes (e.g. create a group of them for one click switches several? or if they are controllable by msg etc) would be in the finer details.
Not every node in a flow processes all or the same data, so it would be useful to have 3 states (active, disabled, pass-through)
1 Like
I agree but sometimes it could have some kind of interest. It all depends if you like regrouping stuff to do in one node (for ex: one big "change" node with 10 rules or 10 one-rule "change" nodes ?).
But there's another argument against a "ghost status" for nodes: what if the node has several outputs, where is the message going ?
