Allow continuous display of virtual wires and labels from link nodes

Core Development Feature Requests
1

This suggestion comes out of a recent discussion Increase canvas size? (supersize flows!) about enlarging the editor workspace. An obvious approach when a flow becomes becomes too large for a single tab is to spread it across several tabs, with the broken wires replaced by pairs of link nodes. The down side is that this makes it difficult to understand at a single glance exactly where the messages flow and what processing is being done, especially when a large number of tabs are used. A small change that might help would be to optionally allow the virtual wires and labels of the link nodes to remain visible at all times, instead of only when the link node is selected. This trivial flow was used to generate images of how this might look.

[{"id":"5125d0cf.aae6","type":"tab","label":"tab1","disabled":false,"info":""},{"id":"c47ef665.68e348","type":"tab","label":"tab2","disabled":false,"info":""},{"id":"9cbc0c12.c30328","type":"inject","z":"5125d0cf.aae6","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":200,"y":120,"wires":[["7c0960de.f5b688"]]},{"id":"7c0960de.f5b688","type":"link out","z":"5125d0cf.aae6","name":"tab1 out","links":["7da3d3ff.12229c"],"x":295,"y":120,"wires":[]},{"id":"761cf44d.f42344","type":"debug","z":"5125d0cf.aae6","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":790,"y":120,"wires":[]},{"id":"4d5d13a8.2cc58c","type":"link in","z":"5125d0cf.aae6","name":"tab1 in","links":["23d9cb29.b4fd14"],"x":685,"y":120,"wires":[["761cf44d.f42344"]]},{"id":"3537377d.264558","type":"comment","z":"5125d0cf.aae6","name":"tab2","info":"","x":490,"y":120,"wires":[]},{"id":"ae5be28e.81fda","type":"link out","z":"c47ef665.68e348","name":"tab2 out","links":["f14f9d2.719436"],"x":555,"y":80,"wires":[]},{"id":"76a5e4f9.c2e844","type":"link in","z":"c47ef665.68e348","name":"tab2 in","links":["219a086f.da9a58"],"x":315,"y":80,"wires":[["8eb0e933.205728"]]},{"id":"8eb0e933.205728","type":"function","z":"c47ef665.68e348","name":"tab2","func":"\nreturn msg;","outputs":1,"noerr":0,"x":430,"y":80,"wires":[["ae5be28e.81fda"]]}]

tab1
tab1.jpg6666Ă—500 195 KB

tab2
tab2.jpg6666Ă—500 124 KB

Clicking on the wire or label would take the user directly to the connected node, without having to first select the link node. This feature could make it a bit easier to visualize and navigate large flows in the editor.

2 Likes
2

I'm all for choice but I would argue setting the link to show its label and setting it to something descriptive is more compact and meaningful than telling you what tab it goes to.

1 Like
3

Mind you, I do wish you could set a link nodes colour. I think that would help quickly visualise related link nodes on a tab.

4

Nothing would stop you doing that as well.

My suggestion would also make it a bit quicker to navigate from tab to tab.

5

It's certainly an option. I dream of setting this via the settings file...

6

Or individually for each link node in the "Appearance" tab of the edit dialog. Or by a mouse click on the grey portion of the link label…

pointer
pointer2704Ă—498 94.7 KB

7

The idea of link nodes is to declutter the display - having them leave permanent clutter seems counter-intuitive to me, when a single click reveals all the relevant info - and clicking any of the off page links take you to the other end of that link. The appearance section of the link node will let show the local name label permanently (default is opposite of most nodes that allow you to hide their names), and of course you can change icons if you want to identify them further.
image

5 Likes
8

I agree in general, but clutter could be a matter of scale. The post I was responding to described having 30 or more tabs, each requiring a workspace of 5000 x 5000 px (or larger?). He probably needs to improve navigation, and having the destination label visible and going there on one click might be worth the extra real estate.

I didn't expect much enthusiasm for the idea, but I thought I'd toss it out there.

9

If the flow is that large then by the time you have scrolled across it, I don't think one extra mouse click is too arduous :slight_smile:

3 Likes
10

Regarding my example of >30 tabs:

We use tabs to group related flows per module of the manufacturing line. Depending on the project's size, it is further split up into one or multiple tabs per request type (checkin, checkout).

The flows, however, are rather independent, no link nodes required, at least between the module tabs. They just register an input node with our PLC broker, perform custom data handling and send the reply.

Until now, navigating and visualizing link node wires has not been an issue and works well with the current implementation.

I could imagine your proposal might be useful for larger interconnected tabs. But it should be easy to be enabled/disabled, maybe by keyboard shortcut or the new command box in v1.0.

11

IM(not so)HO, needing more canvas space is a code smell. Maybe NR is not the right tool for the job, or the flows should be separated into multiple NR instances (for example) by domain. Even at home I have several NR docker containers: Home Assistant; presence detection; backups; pseudo-DMZ; UI; others I can't remember. They communicate via HTTP and/or MQTT. It's more of a micro-services model rather than monolith. It means smaller independent changes that are less likely to break each other.

12

We are already using multiple instances for different parts of the system. Complex features are even put into stand-alone services (no Node-RED).

The different parts are communicating mainly via WAMP or web services.

The canvas size problem exists with one specific instance only; the one that communicates with the PLCs.
There is nothing smelly about the code, that part really just scales with the complexity of the physical project. :grinning:

Although runtime performance is not an issue, it could be further split up into logical groups of instances.

1 Like
13

@michaelblight Could you post about original issue on the original thread please :slight_smile:

1 Like
14

Fair call, but to me it goes to the heart of why a feature like this is being suggested. I've made my own feature requests only to find it's not going to happen and there's a compromise that ends up being a better solution. And I appreciate the lack of feature bloat in NR.

1 Like
15

I went ahead and rebuilt from source with 15000 x 15000 as the canvas - perfect and doesn't seem to have an impact (here's to more NR adoption).

16

In terms of the link nodes, they have improved quite a lot over the past few versions but aren't quite there yet for some people.

The "last push" is to be able to look at a flow and work out the connections between the link nodes without having to do anything with your mouse and without having to manually name the nodes

I don't think we are going to get this in near future but no harm in asking from time to time :slight_smile:

And like I say, they are MUCH better than they used be :slight_smile:

3 Likes