Could a pro max admin run a pool to validate with the community if the debug clamp (pending copyright/trademark/patent) feature for wires instead of debug nodes is a desirable enhancement?
There is a story of me once in a stand-up at a startup I was working at that in this standup an idea was being discussed and I thought it was a good idea. So it came to give points to the amount of effort required to implement. The circle was approx 20 people and started on my left, so I would be the last to give a number. Most people where somewhere between 2 and 4 - days. It took about 20 mins to go around.
When they got to me, I just pointed out that I just deployed the new feature (with tests). So that my estimation would be zero. I was the only one allowed to be sitting in front my screen during such meetings - it seemed that I paid enough attention. Fun times.
Either way, I'm just working on the clamp feature - it's not too much effort, hopefully will have screen animation in a sec.
1 Like
first non-released version - needs tuning but the idea is clear. Not quite what I imagined but squint a bit and looks like 180m euros!
2 Likes
Can you add a right click context menu to let us (un)clamp a wire? Can you also color wires that are currently clamped? A visual feature to let users see which wires are being probed will help people to know which parts of the flow are important when debugging it
If you add AI auto clamping, Im sure this will be valued 180m euros
I'm done doing things that will not be added.
One of the original issues with this message tracing (as pointed by ...) is that it risks flooding the editor with messages, thus freezing the editor. Since the user needs to be certain what they are doing, I've added a certain amount of button-clicking so that the user is certain they want to be doing this.
As much as I'm a fan of context menus, I thing right-click, then message trace and your editor is frozen isn't a good idea. [Edit: this isn't meant personally this is meant for me it isn't a good idea.]
Then only create stuff (as packages) that you want to use and that you use everyday. Itching scratches or scratching itches that you have are the best way to create stuff that others also will use - even if it's two people and their pets.
As I pointed on in the readme (scroll down) this clamp idea is definitely yours and if you want to create a package that solely does message tracing, then others will use it. This tracing/debug topic pops up so often and yet there isn't yet an "official" solution, so there is a space for pushing ideas out there.
I hope you don't mind me implementing your idea but I didn't want to a) wait for the discussion around the UI/Features b) create something that folks can try and get a feel for c) have something that I can use and d) it was super quick to do.
This whole message tracing has been talked about for years, yet there hasn't been anything "official" (alone in that thread there are two unofficial, unpublished attempts). Hence my stepping out and "just doing it"(TM) - f2k it, having an POC or unpublished plugin just because folks have the feeling it goes against the "node red isn't a dashboard" idea is silly. Node-RED can be and should be a dashboard because that's what folks want and that's where Node-RED has developed towards.
After all these are plugins and not "I want this feature in core" attempts. I don't care whether this ever hits core, who cares, I can just install a plugin and have better insights into what my flows are doing. I want the insights, not a discussion around whether this should be in core or whether the UI is good or not.
And so what if there are 5, 10 or 100 packages that all offer message tracing - great, then each one does it slightly differently - I don't have to install them, nor does anyone else.
Nick does point out that this stuff should go into the debugger package so perhaps begin there.
Not at all! I actually love to see my ideas coming to life. The only thing that would really make me hate someone is if the person invites me to a meeting with my boss, and start pitching the idea I shared with him, during his onboarding, saying "my idea is". Motherfucker did that while smirking at me. Some people are just evil.
I will try adding my idea to the core but only after it is approved by the owner of node-red. Last time I spent some time doing something I thought it was useful - retrieving data from set and map using custom jsonata functions $set $map - since I would no longer need to use an extra function node just to fetch data from set and map, the idea was not accepted. The argument against it, if I remember correctly, was that jsonata does not support these two "data structures". However, this argument shouldn't have been enought, since there are already custom functions, such as the $env, that behaves almost like retrieving data from a map of strings, and which is also not part of jsonata's spec. Anyway, if people want to work with set and map, they must learn how to do it in Javascript and use an extra node 
1 Like
What does the JSONata.org documentation say about sets? Perhaps there would be a better place to pitch the idea.
But also an interesting question: should node packages be able to extend JSONata functionality? I would see it as ok but it might well be much work...
What Nick meant was the debugger package which is separate from the core. That hasn't been updated in four years! So it definitely needs some TLC ...
It would be a lot simpler to get approval there then to get stuff into core.
Nick's reason for refusal is that he doesn't want to add extras; which are not natively supported by JSONata.
But wait, aren't all node packages adding functionality that isn't natively supported by Node-RED?
Also as @AllanOricil says, there are already non-standard JSONata functionality provided by Node-RED.
I can understand wanting to avoid confusion and keeping JSONata limited to a focus set of functionality, especially as the editor is so well built and also has a test functionality. The JSONata integration is super tight and extending JSONata by third party would require updating all of that ...
They are message related; allow to use msg in the expression.
also $flowContext ... but I'm being pedantic. I understand the point and have to say that I actually agree because of the super tight integration: the JSONata editor is fabulous --> each function documented, a tester to test code and validation so that no broken JSONata is deployed to the server.
Adding new stuff would require much work, not to mention opening it up to third-party extensions via node packages - what a nightmare!
Having said all that, I'm happily extending JSONata for Erlang-Red --> GitHub - gorenje/erlang-red-jsonata: Erlang parser for JSONata transformation language --> I just love the human ability to say one thing and then do the exact opposite 
cognitive dissonance for the f2king win!
I also talk about this in my third year retrospective that something like JSONata is essential to a visual low code environment.
1 Like
Well, if I needed to use a function node, I would remove the change node. 
Indeed, I do often collapse a set of individual nodes into a well documented function node. I love Node-RED's ability to act as a quick prototyping tool but as complexity builds, I find it often easier to gather the logic into a single function node. So fewer rather than more nodes.
But that is just me - after all, I'm fairly familiar with JavaScript. 
As always with Node-RED, we have choices which is great.
1 Like
This thread is getting rather long.
The original question "Should debug nodes be capable of passing the message forward?" has been fairly comprehensively answered (No but some other approach is welcome).
Perhaps the ongoing work re debug code for wires deserves to be in a thread of its own, and this thread closed?
1 Like
Just to avoid misunderstanding, I don't hold any bad feelings anymore. I confess that seeing my PR rejected infuriated me, but Im trying to learn to let it go, specially after what happened in my life. I never spent time learning and developing EQ, and now that I know it is more important than anything, I started to learn. That is why I started reading "how to make friends and influence people". My comment's intent is to make clear I will follow the repo contribution guide strictly, to avoid spending time. Before implementing changes I will wait for approval.
3 Likes
