Probably only Flexdash users have seen this, but @tve has added a 'help' button' to the node properties header of the Flexdash nodes, which if clicked, selects & opens the relevant help tab in the sidebar.
Perhaps this should be recognised as good practice for developers, as it makes help very visible to users (and those of us that can never remember the keyboard shortcuts!).
I'm not the only person capable of doing it. Node-RED is open source. Anyone could contribute the change for the benefit of everyone rather than just their own node.
There are plenty of examples of "I think X could be better, so I've published my own version rather than help improve X". But after 10 years of working on this, I'm fairly used to seeing it happen. Plenty of missed opportunities to help move things forward.
I'm finding that it is very difficult to get a real discussion of new feature proposals here and most of the time it's impossible to get to an actionable conclusion. For example, after several tries WRT introducing a notification into the flow editor when all nodes have been loaded I have given up. I have now dealt enough with the async loading that I can show that there's no clean work-around. All I can do is shrug my shoulders and add some more hacks.
The help button took me 5 minutes to put in. It has the benefit of working now for all versions of NR supported by FlexDash. A pull request is comparatively a lot of work, has a completely uncertain outcome, and would only take effect in the long term after a release is cut and users upgrade. If such a feature is released in the core it'll take me another 5 minutes to add a if (RED.version < 3.x.x) predicate so there aren't two buttons.
BTW, you could also take one of the following attitudes:
"great that they're trying it out on their nodes, this way we can see whether it gains traction and then decide whether to add the feature to the core"
"oh, people really seem to want this, sounds like a good thing to add to the core"
"hmm, maybe if I point those guys to the source code section in the core where this could be added I can convince one to create a pull request"
Sorry for being the usual contrarian here. I like the end result of what Node-RED does and I've spent many hours trying to enhance it. I am thankful for all the effort you have spent building and maintaining it. I also very well understand the limitations around being able to accept feature requests. However, I do not find it fair for you to paint us as selfish and disrespectful for not making a pull request to the core for this button.
You know, this is a good point: total work would have been minimized!
It would take one member of the core team just a couple of seconds to locate where to insert the code, they already have everything checked out and a test set-up going, they already know the commands to do a test build of the runtime + flow editor, they don't need to go through the whole pull request dance (IIRC), they don't need to keep the branch open for days waiting for feedback, etc. For someone else to climb this mountain takes far longer (not saying it can't be done, it's just the reality of a large codebase.)
Do you have another discussion open about this somewhere? I am just curious if it is related to something I recently came across in the editor trying to run code in the onpaletteadd function and realizing that RED.nodes.eachConfig can never find my config node because it is too soon to check. I am still trying to determine if that is a bug or just the expected behavior. Regardless, I have a pretty clean workaround for it by adding RED.events.on('runtime-state', handleRuntimeState) in the onpalleteadd function. After the first time it detects obj.state === 'start', I remove the event listener.
Good idea. I will use that technique to not include my help button.