I think it devolved into a discussion of putting it in core because folks here think that anything that is useful needs to be in core. Ironically (for confusions sake) I would agree that collapsible groups should be (if they ever happen) be part of core - but, for me, that's the group stuff I was talking about above not your plugin.
+1 on that - it can be a useful thing outside of NR and if it uses internal APIs, then perhaps those APIs should be documented and allowed to be used by third party plugins.
Disclaimer: I'm for a lightweight NR where all nodes are separated out of the core and useful internal APIs are opened for being used by third-party plugins. Why? Because that makes for less debugging and a more stable core NR - see Linux kernel ideas if in doubt or Unix in general.
Large companies are for monolithic solutions since that allows them to control more of the functionality. Plugin based solutions are better for an open source community since contributions can be small and isolated - good for learning and getting involved in bigger features.
This is another thing I don't understand: what's wrong with a discussion? This sentiment comes up again and again until the entire forum is silent and no one wants to say/write anything. Pity really because discussion should really lead to learning and consensus, at least, I had the feeling that was the case here.
You genuinely helped me to understand what you want to achieve and I think it's a good idea but I am unsure about visual confusion. I definitely learnt something through the discussion here - thank you for having the patience to cope with my ignorance!
I see, I do not have enough experience in github or node-red to properly engage into adding anything. I can merely suggest, but further than this i am not qualified.
Im happy with the design feedback, which I am working on. I am also up for discussions, however i wanted to avoid them in this post as I was only looking for feedback to the plugin. Not feedback for when its added to the core or feedback on node-reds async (instead of sync) choices.
I know all of these things as I read the same in other discussions, this is why i answered both these topics in my first post to we wouldnt steer in that direction but just discuss the general concept. Things are getting too technical here which I understand.
I understand the irritation regarding random ideas. I made most plugins for my own project, for those that might want it. However I can understand that the posts I make seem like I want to force these ideas to the NR core. However this was never considered or brought up by me. I will take them down and keep them for me and my collegues to avoid any confusion and to avoid users to use these plugins, as Nick said they might depreciate with the next node-red update.
I dont wish broken plugins for anyone
Thank you for all the information, I will take it with me when working on my projects.
Please don't do that. The discussion and ideas are very useful even if nobody else takes them up. All you need to do is make it clear that they may use non-published internal node-red API's. That is sufficient.
It is discussions like these that generate useful new concepts and move Node-RED forwards.
Certainly the collapsible group idea is a great one and well deserving of a discussion with Nick to see how it can be incorporated best into Node-RED. At least the idea even if not the direct code is great.
I understand that, I should dive deeper in what I can already use from the APIs. However I never stood still that if I stop maintaining the plugin, it might break with a newer version.
I wish to not have any blood on my hands for other projects as I do not know for how many years I will keep it up (regarding the current plugins I have released). I will do my best for any future ideas I have, however the current ones are now not fit to standards and only work for 5.0.1 (and some <=4.0).
EDIT: They are basicly a ticking time bomb by anyone who uses them.
EDIT:EDIT: Well they can always remove the plugin, as all plugins I made are only visual changes. The core remains working for all 5 of them after uninstalling the plugin and restarting node red.
It's fine as long as you've made it clear. It's the ideas that are important and a useful record of what might be possible. If you stop supporting it, just deprecate/archive it on npm and GitHub so that everyone understands.
Just add a comment to the package readme indicating that it may use undocumented Node-RED API's so may stop working in future NR releases. By all means also add links back to the relevant forum discussions so that people can see the context.
We love seeing new ideas here. However, we do sometimes get a little protective of Node-RED as a lot of us are rather passionate about it and have invested a lot of time and effort over the years. Don't let that put you off, we really do appreciate the ideas and effort people put in.
I get that completely. I found the deprecate on npm. I know from an earlier attempt that if you private the npm it gets removed from the node-red flows page.
I didn't personally read responses here as intended to discourage you from raising possible enhancements.
I think there is some ongoing irritation that people ( ) raise issues but don't contribute code changes, so relatively few developers do most of the work.
I've tried the PR route several times and I find it impossible, so perhaps no surprise we are seeing a trend towards developing plugins.
Node-RED is certainly a complex beast and even for experienced Node.js devs it can be challenging for sure.
I know that some work is ongoing to try to modernise some of the core code and, hopefully, expand the JSDoc comments to make it easier to follow what is happening and where. These are things that should make it easier to contribute.
And this is absolutely fine. Not everyone is in a position to submit core PR's. There is absolutely nothing wrong with demonstrating some new features in a plugin or even a node. The main thing is to open the discussion and to make it clear whether you are using undocumented core features,
For sure, you may get some passionate "feedback" from folk about taking one direction or another but this is simply part of the fun of being in the Node-RED community. Nobody can be right about everything and with a platform as complex as Node-RED is under the skin, there are bound to be some conflicting opinions. Thankfully there are very few "fixed" architecture foundations in Node-RED which is why it remains very flexible after 10+ years of active development.
I will update my current plugins to make sure they are using documented core features. Do you happen to have any direction where I can find this api for layout and editor features (none core) stuff.
*Right now im using DOM, JQuery, etc to make the plugins work but I must figure a node-red safe version for this
Well, the docs have the basics for nodes. But I don't think there is much for the sidebar other than the API for creating a sidebar. I tend to use jQuery more than direct DOM for the Editor since that is perhaps a little easier for most things.
UIBUILDER has an Editor plugin but I only use that to load my own custom CSS and common JavaScript (for use in my other nodes) so it only loads once but is available for all my nodes. I do have a node that creates and gets data to and from a sidebar so you might want to take a look at that. It is called uib-sidebar.
https://github.com/TotallyInformation/node-red-contrib-uibuilder/tree/main/nodes/uib-sidebar - the main node definitions.
https://github.com/TotallyInformation/node-red-contrib-uibuilder/blob/main/resources/uib-sidebar.js - the Editor JavaScript code.
And actually, now I've re-checked that 2nd reference, I am reminded that I actually didn't use jQuery there Not sure why, just how I was thinking at the time probably.
Oops, I think I've cross-threads. This one isn't about a sidebar is it!
So, OK, the docs have the main elements for a node's Editor config including the various special widgets. I would generally just use jQuery to manipulate things but use Node-RED's API's for tabs and typed inputs.
You will see that plenty of the UIBUILDER nodes do various non-standard things with the Editor. Also, the common CSS I use deals with some of the oddities that have stayed in the Editor over the years and helps add things like better tooltips and more responsive non-pixel lengths.
How did you define not using documented apis for uibuilder in your readme?
Dont all editor UX plugins not use documented apis since they are not there?
There were many points made about documented and usage of the api, but all my nodes use only UX changes. As far as I read on the documentation page, i dont see any api that my plugins can use.
That is the easy bit, once you know how, but this isn't a subject for this thread.
If you want to try again (and please do) then start a new thread and help will surely be provided.
Without drawing out this thread more than it needs to be, I will admit my responses did come with a slight ulterior motive. You are clearly doing some super interesting work - and successfully implementing some pretty complex things all things considered within the Node-RED code base. I was hoping to tempt you into contributing to the core of the project - whether these specific things, or just contributing in general. If that isn't something that interests you, that is, of course, absolutely fine. I look forward to seeing what else you come up with and what we can learn from it.
I think there may be 2 areas where I've taken some liberties. Using some of the internal event messaging (with carefully selected names so that there is no likelihood of anyone accidentally clashing). And some cheeky extensions to RED.util for function nodes (again with carefully chosen namespace). Because I've chosen the naming carefully and only used what appear to be pretty stable features anyway, I think I'm fairly safe. However, I do keep a close eye on Node-RED development in case I need to urgently change direction.
Other things I've done fall into 2 camps:
Editor node panel formatting and features. All of the HTML for my nodes is wrapped in a div with a specific class attached so any custom formatting is well contained.
Re-organising the code structure for nodes. Runtime especially. This does not affect Node-RED's operation, I've simply re-organised things to make more sense as I see it. The HTML for the Editor side, I've split to make things much easier to manage and code but it all still fits into standard Node-RED. The runtime code I've restructured to clarify the way that Node-RED works with a node's runtime and to make it easier to have common code shared between nodes by using singleton class modules.
So I don't really use any undocumented API's I don't think. Though with code stretching back over 10 years now, it is possible that I did do something somewhere.
Easy to get lost in a thread like this. I wouldn't really expect a plugin that just does a visual collapse/expand of a group to have that much of a core impact. Some of the other ideas you've implemented would seem, at least at first sight, to have a bigger potential impact. However, I didn't spend a lot of time digging deeply.
Still, messing with the visuals of the Editor could still get caught out in future changes. Though it mostly seems to have been pretty stable for a long time.
I changed the visual approach towards @gregorius idea.
Its the same mechanics and same code, however now you edit inside the expanded group, rather than in a seperate tab I stole from the subflows.
Don't mind the low FPS, it runs smooth but I tried to mash it all in 1 GIF.
Since there is no node for this plugin, like my other plugins. Any changes to Node-RED development, a broken or removed plugin will still run the same flow/group code without issues as im only adding visual mechanics here. The underlying core runs as normal NR.
EDIT: Double clicking the junction nodes on the edges allows you to rename them, so when collapsed you can get a sense of what is going in and what is going out.
Looking really good - I really like how you did the group inputs & outputs. I was thinking of some kind of drop down with a numbers but this way is much more dynamic and flexible
Are the inputs on the left and outputs on the right - because you label one left junction node as "cheese out" - I assume that's a label not semantic meaning?
I'd be all for having this in core, for me, a couple questions remain open:
storing in the flows.json - how does that get stored there or are the junctions (which get stored in flows.json) automatically associated with the group (in the editor) based on proximity. That is, because the junctions x & y is on the border of a group, they are "attached" to the group in the editor only but not in the flows.json?
For the collapsing, existing layouts might need to be thought about. Example:
Here the layout depends on a "longish" group because other nodes are placed accordingly. In the top groups, I would probably be using the output ports of the groups instead of having extra junction nodes - something that alters the wiring when collapsed.
In would be interesting to see how this works when the group collapsing is triggered by zooming in/out as well as manually.
This is not critic, just throwing the questions up because I'd like to hear what others think. I really think that you did a great job and it's a really good idea for Node-RED
) raise issues but don't contribute code changes, so relatively few developers do most of the work.
