Expanding on the Comment node--Creating a node that can be resized?

Use-case: Building a Section node that a flow user can re-size and always is the "bottom-most" node layer of the Node-RED canvas.

Users would use this node for demarcating a specific area of interest for the original Flow designer and other succeeding flow designers. This is similar to the comment node

It doesn't appear that node resizing is something immediately supported, nor within the vanilla Style Guide.

Has anyone else considered this? Any best practices for accomplishing this use-case?

Along similar lines, did anything ever happen with this?

1 Like

There have been a number of discussions/suggestions around having additional drawing tools in the editor. Worth having a search for those so we don't have to retread the same points.

I think there is a place for some sort of tooling in this area, and there are lots of possibilities. But with the focus on getting to version 1.0 at the moment, it isn't something I'm working on right now.

@Bobo nothing immediate has happened with the work @shrickus did. But it is certainly something to consider once we get past 1.0 along with all the other possible approaches

2 Likes

Hey @knolleary, thanks for the response! If we were to "roll our own" and build out the functionality to support this, do you have a sense of what the Level of Effort would look like?

I am assuming you are very familiar with the underlying code base so I'll take that into account, but would be super helpful to get your insight :+1:

Anything is possible. It depends if you want to hack it into the editor or collaborate on a more considered approach that is extensible for others beyond just your use case.

The hardest part, which I don't see you being able to do from your node's own code, is the layering - having your node below all others. You cannot control what layer nodes are drawn in - so you'd need to modify the editor to ensure your node is put on a new layer under the existing node layer. That then makes this a bespoke version of the editor for your use case.

As I said in my original reply, I'm focussed on 1.0. One of the breaking changes it introduces is a complete rework of all of the CSS styles and DOM element IDs throughout the editor. Any nodes that have hacked their appearance in the editor (such as the Image Viewer node) will be broken in 1.0. This is why we have never supported nodes hacking their appearance - we knew we wanted to make these changes and didn't want to have our hands tied.

Equally, once we have got to v1.0 and these changes made, we can begin to consider what extension points we could/should expose in the editor and what other drawing tools/layout options we could provide. If we can support some of these things through an abstraction API without nodes having to hack the dom, it gives us more flexibility to change the internals without breaking these nodes in the future.

Being able to group nodes is something I've looked at before - in fact there are some remnants of those experiments in the code today. The UX was hard to get right and ultimately wasn't worth the effort at the time. But it is something I'd like to eventually revisit.

Having more people interested in working on this would help. The problem is that people often just want to solve their own specific scenario and don't want to invest time in the more abstract design work. And that's why it doesn't happen until I have the time to do it.

1 Like