I'm asking this, because in many cases it is misleading that only a small part of the whole msg is visible at the right side. Especially since "topic" was introduced.
This was discussed recently and, if I remember correctly, it was decided that there would be an enhancement, though I don't remember exactly what was decided.
I always manually set to "Complete Message", it's an "annoying" always process. In 5 years I think there were maybe 2% of cases in which I only wanted to debug msg.payload and even then I probably decided to switch to the whole message.
BUT, in the beginning, having it as msg.payload by default, helped a lot in teaching me the importance of the payload property. It is basically "the main thing", especially in regards to the default nodes and in travels between servers.
I think a beginner should work with the payload first, and then realize there's the msg layer, and payload is part of it, and so on. I know it sounds very "obvious" and "they should know that already" probably.
Maybe make a setting "debug whole message by default", for advanced users.
manipulating the settings file is not user friendly at all.
I need to install it to 50+ PC. Changing those always is a pain in the ...
I think if v5 node.js minimum is not backported to v20, I wound be able to switch to v5, because the last version that still runs on Win7-32bit is Node.js v20.
< OFF >
Don't you feel You contradict yourself "a little bit"?
My experience when I started to use NR:
IMHO my English is not bad. (I even learned a semester as "English + programmer teacher")
yet, I did not know that "payload" word, had to look up.
I guess msg.data had been too easy + logical + international ...
and I always forgot it, when I had to type it in a function...
It always confused me, because I did not see the whole msg structure.
Even yesterday I did a mistake by sending out a trigger to a 2th output via: node.send([null, {}]); instead of node.send([null, {"payload": true}]); and had to debug for 3 hours... (Because I have "tried" it in an inject node: and it seemed to work! = changed "true" to empty obj. But actually the inject sets "payload" by default, what I forgot to check.)
Usually I work 6-12 weeks with NR + JS, than put it aside for 12-24 month. When I get back, I've already forgot almost everything and have to start over learning NR again.
It is often valuable to see the entire message object, but in general I prefer each debug output to occupy as little browser space as possible so I can see more payloads.
I sympathise with your reluctance to edit each device to make it default to showing the entire message, but not so much that I'd be happy to edit my own 50+ devices' settings file to revert to msg.payload!
Edit - I guess any change in default behaviour is only going to affect new debug nodes, so I don't need to edit my settings files.
Incidentally, I understand that your Node-red devices are distributed around customers' sites.
Would it be better to have a customised debug handler to pass debug messages to your HQ servers - by MQTT maybe?
We won’t officially support v20 but it may still work, as I’m not (yet) aware of any v24 only features we are using, but they will no doubt creep in sooner than you would like. Also your request to change the debug default would only ever make it into v5 ( or 6) so if you really want that then you would have to change anyway…
As Colin has said, managing that number should probably be using automation if you aren't already. With automation, ensuring that all of them have the right (mostly common) settings should be easy.
Changes to settings.js are needed periodically anyway due to Node-RED updates. And surely there will be other periodic changes needed across the estate?
No. Node-RED 5 will refuse to run on anything prior to 22. There are simply too many security issues with old versions of dependencies that we had to move up the baseline.
Indeed, not to mention the fact that automating a settings file is far more straightforward than changing an option in a UI.
More to the point, user settings in the UI are minimal right now, imagine if every possible little customisation were a setting. It would bloat immediately, and you'd then have to introduce a settings search -> yuk!
No, User Settings are absolutely not for this kind of thing in my opinion. But it's a fine idea for settings.js
The other thinking was that if you are working with a team then settings allows you to set up a “house style” that you can all work to. ( as per themes, context, function editor config, etc ), and is easy to pre-configure or copy/deploy around using automation rather than every user have to setup their own on every browser.
Don't you feel You contradict yourself "a little bit"?
