Adding junctions to wires

[knolleary]

This is an often requested feature that we have historically pushed back on. I recently stumbled over an approach that could work and wanted to get it written down and out of my head.

The wires between nodes are routed using a set of bezier curves and some custom code that tries to shape those curves to make 'nice' paths.

There are cases where a user wants to be able to manually route a wire - usually to help improve the clarify of the flow and reduce instances of wires crossing over other nodes.

Another scenario is where a user has one node wired to lots of other nodes, and wants to simplify the wiring:

The main objection we've had to doing this is that wires don't exist in the flow file as an object with properties - they exist as simple references of what any given node's outputs are connected to.

The standard approach is to add a no-op node (such as a Change node with no rules, or even install the contrib-noop node that exists solely to solve this issue). That works and has been a good enough answer so far, but is a bit of a hack - the flow has the overhead of processing that node, even if it does nothing other than pass on the message.

---

Blender, the 3D graphics program, has a nodes system under the covers. One of the things it allows you to do is to add a 'reroute' point on a wire:

(That also shows a handy way of adding a reroute that is shared across multiple wires)

That point can then be moved around freely.

---

Introducing a Junction type node

What if the reroute blob was a special type of node - a junction (need to check uniqueness etc of that name... other better names may exist). They can then exist in the flow file alongside all of the other nodes.

Let's say we have two nodes, A and B.

[A] --- [B]

In the flow file, node A has a wires property containing "B".

We then add a junction to the wire. This exists as a new node in the flow file:

[A] -\
      \
       \- (C) --- [B]

Node A is now wired to C and C is wired to B.

There's nothing particular revolutionary here - the key thing will be how the editor and runtime handle this special type of node.

In the runtime, when a flow is starting, before the nodes are created, their wiring will be remapped as if the junction nodes don't exist. As far as Node A is concerned, it is only connected to Node B - it never knows about the junction. This removes the overhead of the existing solutions to this problem.

In the editor, the special node type can be visually distinct from 'normal' nodes. There's plenty of UI design work to be done here. For example, whether it becomes a blob like the blender example, or a compact node that still has a distinct input and output.

---

Anyway - just getting this out of my head so I can forget about it for now.

[TotallyInformation]

I must admit that I don't like adding nodes just to get a better visual layout.

The blender approach seems interesting though the example you give highlights an issue of how neat the result would be. I think that the resulting point would need to be draggable in its own right so that the visual layout could be manually adjusted.

Also, what happens when you need to reset things? That would need a solution as well.

[dceejay]

interesting. I guess visually it could end up being just the size of an existing connection point (so you could grab and move it) - which would then preserve the way "our" wires curve.
I think deletion needs some thought - should the nodes rewire/heal automatically - and indeed could/should this be an option for all nodes, as we have drag to insert but no drag out/delete and heal.

[TotallyInformation]

I think that, ideally, yes, the wires would need to heal automatically so some processing would be needed pre-deletion that removes all the connected wires and re-adds them back to the source/destination nodes. A little fiddly but shouldn't be too hard to work out I don't think?

[vkuehn]

That looks interesting ! The proposed solution(s) looks really fancy.
Thought all manual will fail once a node is dragged in the editor. Maybe it could be possible to always calculate the nearest common free editor space for more than two wires.closer than x. as in here

[dceejay]

I would tend to think not a visible one (maybe on hover?) - but hey it's all just an idea at present.

[knolleary]

It isn't intended to be anything more than a junction in the wire - no editable properties. Not going to over complicate it

[TotallyInformation]

I remember that there have been many requests for labels on wires - this might be an easy patial solution. And if basing on a node, then the properties side should be simple. Anyway, just a thought.

[vkuehn]

I see you point in not over complicating things. If you don't mind I would like to mention mxgraph lib where that (close junktions with manual drag points) seem to be solved already. Not sure how easy it would be used with node red.

[dceejay]

with manual drag points then you have to store those points somewhere... currently the wires do not have properties, and changing that would break the existing flow format and all flows... by using a "node-like" object on the wire we can re-use the existing node/flow paradigm without breakage. (hopefully)

[Just-another-pleb]

Hi, I came here after the discussion about Wire tie downs.

As I said in that other thread, I am still on the fence about the idea.

But looking at things said above, I'd like to submit some thoughts.

There is a node already available which I use a lot called fan
https://flows.nodered.org/node/node-red-contrib-fan

This is a very handy node and has a couple of (also) handy features.
1 - You can make it the 1x1 size, rather than the usual size. This makes it handy to do things like illustrated above.
2 - You can add a name to it. This is also handy as you can name the connection,
Example:

This is a good example where the fan node is handy, rather than having a bunch of wires crossing the screen/tab.
At the end where the fan node is, you can identify what the connection is to help you understand from where the wire comes.

Although the tiny example is also good if you only need the anchor point.

I'd better stop here as that is all I can contribute.

[knolleary]

It is worth pointing out that a Change node with its default rule removed, or a Function node does exactly the same job and removes the need to install a non-core node to do such a simple task.

There are also now multiple other contrib nodes that do nothing more than this.

[Just-another-pleb]

I agree with what you say.

I was only offering this as a thought.
But what about overheads with using either of the two nodes you mentioned?

A function node would need - at a minimum - would have to have the ability to look at the message and if it needs parsing.
The fan node wouldn't have any of that code in them.

Out of interest, what are the other contrib nodes. Though I don't think I would go through and replace if for them.

[knolleary]

@Just-another-pleb please try to use the 'reply' box to keep this conversation in one thread, rather than added new comments to the end.

You are right the Function node will have a slight overhead. But a Change node with no rules in will have minimal overhead - you'd be hard pushed to noticed.

As for other nodes:

• https://flows.nodered.org/node/node-red-contrib-noop - has been in the library for 5 years
• https://flows.nodered.org/node/node-red-contrib-nooperation - despite the very similarly named noop node being around for so long, this one was published last month for some reason

And there are others that I don't recall the name of

[Just-another-pleb]

Thanks.

Weird I never saw them.

[bakman2]

Would this solution allow for 2 of those junctions on the wire ?
I like the elegance in unreal engine blueprints.

[knolleary]

As the Junctions are just nodes in the flow that get draw differently to everything else, then yes, you can have as many as you'd like.

[mjbnz]

Would the junction nodes allow for bi-directional messages? this would allow for wiring that travels backwards within a flow to be neatly managed without needing to deal with always having the input on the left hand side of the node.

(alternatively, a second type of junction node that has input on the right, and output on the left would work too)

[dceejay]

no there are no plans for this.

[awSteve]

I like the idea of colored wires. I would like the colors to follow through the link nodes. Maybe this could be included in version 3.0 if the wires get properties?

[dceejay]

There are no plans for wires themselves to have properties as that would break the flow file format and all existing flows.

[prof7bit]

I often have the situation of wires running backwards. Then I am trying to avoid them crossing nodes. If the junction nodes would allow wires to enter from any side (left, top, right, bottom) it would be much easier to route wires across the flow, even around multiple corners like in a circuit diagram, in a very intuitive way. In the screenshot below, if the junctions could be entered from the right or from the top it would be possible to route the wire in a much nicer way:

[knolleary]

I agree the 'running backwards' case isn't well served by junctions today.

The problem was finding a way that worked well in all cases. How does the junction know it should be 'backwards'? Do you end up with input and output wires on the same side of the junction? How does a user know the direction of a wire in that case without any other visual indication? When you start dragging a wire from a junction, how does it know what direction the wire should be running in?

My point being it isn't as simple as just allowing wires to enter from any side.. there's a lot of consequences to deal with.

And this isn't me saying 'no' to the idea - it would be good to keep improving the junction UX.

[Just-another-pleb]

Not to confuse this but just an option of which I thought:
This depends on how a node works on the GUI side of things.

It was suggested that the inputs to this new junction node allow the wires to go in at the top or bottom, and so on.

Would an option be that you put the junction where needed and the wires conform to it and look nicer.

Then: you move the junction node and the in and out positions move as needed for best fit.
So if the wires are going backwards (right to left of the screen) the in is on the right and the out is on the left.

I have no idea if this would be easy but it is something that may make it nicer.

[Djarid]

Maybe I'm just too used to NiFi but wouldn't a better paradigm than input connectors on the left and output connectors on the right but a source -> destination model? Dragging from the source node to the destination node is both intuitive and solves the problem of defining where the input node should be placed... it can simply be signified using an arrow and can be positioned on any face.

[Just-another-pleb]

Well, yes and no. (Sorry)

I agree that it is usual to go from source to destination. But.. ;)

Sometimes you go from destination to source too.

Many times I have a problem and sometimes it is better working backwards from the solution to the start. I say start rather than source as source in this case is not the right term I believe.

This happens when I don't have a clear idea of how to get from the source and I find it easier to work backwards from what I want (the destination) and then think what it needs as it's input (relative source) and keep working like that until I get to the bigger source.

Just saying.

[mazonglei]

Junction nodes I think are very helpful for elegant wiring, but my linux architecture is mips and I can't install node.js above 12.x, so I can only install the 2.x version of nodered, is there any way to port to 2.x to make it usable?