Every each time I place a new Debug node to a flow,
I have to double click and
change from "payload" only -> to Whole msg
Click Done
I thing even a beginner should rather see the whole msg, instead of just the "payload".
Even more since "topic" was introduced.
I think it's time to change that policy. It does much more harm than good.
After all, it is a:
Debug
node! Not some half-camouflage tool to show some very limited info.
if accepted:
It is very easy to double clock on the right palette, to show details, and
teaching beginners about the whole msg structure from the first view.
Also preventing possible errors (Last time it took me days to figure out what's going on, and wasted the time of many of You here at the forum too, because I've simply forgot to change that at one Debug node. This forum is full of similar topics.)
But to calm everyone, who thinks that "payload only" behaviour by default is good,
I recommend to add a checkbox to the User-Settings, under "Nodes" section:
[ ] Debug "payload" only by default (default unchecked)
I believe this was originally set to payload, as each debug adds overheads and each complete message adds greater overload.
I agree there is a need to inform new users that there could be more msg properties other than payload and topic.
One possible suggestion, a flag on the debug node (default payload) when extra properties available ( hover for message and possibly clickable to access the config).
What is the reason this cannot be controlled via the editor instead ?
It may be a bit of a stretch but has it been considered to do an overhaul of 'hiding' everything in settings.js, it has become an obscure and messy file to deal with, plus it is not exactly a 'modern' way. I understand that certain things are handled with at startup.
I created the concept of "alias nodes" as a method of setting alternative default values but that got no traction. That's a editor-only solution to having nodes with different default values. It's a non-standard and liable to break solution but it does the job now for v4.x (and 3.x also).
A debug node that uses complete message as default is included in this flow.
Because of time and effort needed to design the UX and implement it. I had a full plate with other work and Dave stepped up to implement the basis of a solution via the settings file.
I opened up User Settings today (after upgrading to 5.0) and was so impressed by how FEW settings there were.
User Settings page is clean, purposeful, and doesn't look like those old Windows applications designed by tinkerers with 20 tabs on a settings dialog box and hundreds of tick boxes to gaze aimlessly at while you forget what setting you were even looking for in the first place.
So on the contrary, I don't think it's "modern" at all to stack a whole load of settings upon settings into a UI.
May I ask how exactly you find it messy and obscure? I'm genuinely interested to hear the answer.
To be fair, there is some truth in this I believe. I've spent quite a bit of time over the years trying to make sense of the file and some time back made some suggestions for improvements to the comments that are built in, some of which were accepted.
My own versions of the file are still somewhat different to the default and I believe there are still possible improvements that could be adopted.
There is an awful lot of "stuff" packed into that file! To find the right setting can take some searching. It actually surprises me that nobody has written a UI for managing it. After all, this is not that uncommon in the UNIX-like communities, a settings file with a UI helper app.
Having said all that, I do still like that it is a single file and I like that Node-RED has a lot of flexibility. Also, the file makes it easier to embed Node-RED into other apps and services. So overall, I think it is the write tool for the job. But for sure a utility to manage its entries would likely be welcomed by many people.
One of the issues re automation is that it is a .js file. JSON would be a lot easier to automate and keep syntactically correct, but doesn’t support comments, which are kind of essential unless it is fully automated, at which point it may as well be in the editor. Also .js does allow extra capabilities that people do make use of so we want to stick with it for now at least, so it would need to be a tool that can handle the vagaries of js, and of course someone needs to actually write and maintain it as the settings evolve.
Of course things like Claude, etc may be able to help you fix things up as well.
Well, most of the file IS a JavaScript object. So it wouldn't be hard to move the core of it to a JSON file. The trick would be to retain a js file as an entry-point to Node-RED.
Right now, it is perfectly possible to load the settings themselves from a JSON file. Indeed, this approach would give a number of potential advantages in exchange for having an additional file to manage. Even that might be optional with the right load process.
The comments could all be moved to a structured documentation page/file.
I am referring to the settings.js file. The interface itself is fine and i was actually promoting to use it. Certain settings you should be able to control via the interface, especially when it controls interface outputs
To find the right setting can take some searching. It actually surprises me that nobody has written a UI for managing it. After all, this is not that uncommon in the UNIX-like communities, a settings file with a UI helper app.