Flippable node wiring direction

Hi All,

Would it be an easy to develop feature to make wiring direction flippable at a certain node? Currently, if you have a number of nodes in multiple rows, then the wiring goes always left to right like:


So after node C, the wiring turns back and goes to the left to be able to connect to D. However, if it was possible to flip the direction of wiring for node D so that the input port is displayed on its right and the output port(s) are displayed on its left, we could have something like this:


Sorry for the schematic flows but I hope you get the jist. Once a wiring is flipped at a node, it'd remain like that for all nodes after it till the wiring is flipped again. This could result in cleaner and more transparently displayed flows I think. What do you think?

Best regards,


I totally agree, we should be able to connect the ports at different positions of a node. I think to avoid confusing between IN and OUT, it will be even better to have an option of an arrow head, which will TELL the node the DIRECTION of flow. Also better to have PORTS at top and bottom as well

1 Like

This has been discussed a few times before and the conclusion has always been this isn't something we want to do.

It would get super confusing if the flows can go in any direction. If you were zoomed in to a part of a flow, you'd have no idea what direction it was running in.

Arrow heads would help (and there is a PR in the works that will add an option to display arrow heads). But I still think switching directions like this would be confusing.


What a pity, I missed those discussions -actually didn't even find them yesterday. I disagree though as I think it'd reduce the number of crossing wires. Nevertheless, I can of course accept your decision.

And link nodes can help detangle flyback wires from your first pic.

1 Like

If arrowheads were on by default, it wouldn't be that confusing. If anything, it might help tidy up a bit.

Link nodes are fine, but sometimes about half of the nodes are links back and forth, and that is also very confusing, not being able to see where the wires go on first glance. Links are still super useful for jumping between tabs or between separate parts of the same flow, but for tidying up, it would be great to have the option.

Another thing that would help a lot to tidy up things would be a small branching node, a dot where you could connect wires and would just forward anything that comes in to all the wires in the output, a bit like an empty function node with only "return (msg)" inside.

On occasion, I've found myself having to add a debug node to see what comes on the INPUT of a certain node. This is usually not an issue, but when you have a node with 40+ wires connected at the input, adding such a node implies duplicating a sh*tload of wires.

In cases like this, the option I usually get is to add an empty function node to gather all the inputs and forward a single wire to the next node. That allows to connect the debug node in between with just one wire. I could also do it with link nodes, but then I have to add two nodes instead of one.

I was thinking of something the size of a deployed link node (the small square) with both input and output, that could be used just to sort out these situations where many wires converge on just one node.

We have a proposal for that: Adding junctions to wires · Discussion #62 · node-red/designs · GitHub

It won't be until 3.0 now and we need to consider how to make it somewhat backward compatible - so flows can be shared with older versions of NR with some way of it working - much like we did when we added Groups.


Ooooh I missed that one. I'm very much looking forward to it, I really need my flows to be nice and neat, and that might be a challenge when they get complex.

Hi, I assume you are refering to the "Adding junctions to wires" that Nick mentioned (and not the "flippable nodes" as the OP requested?)

You can already do this quite easily with an empty change node


Without a junction

Using an empty change node as a junction


I was referring to both.

I currently do the same thing you set there with an empty function node, but I assume it has certain overhead and if you need to add/delete it you have to rewire the whole thing. Junctions would solve that.

As for flipping the node direction, things like this could look much better (and would not be confusing if the wires had arrowheads):

Not any more...




(Thanks, really!)

I think that there might be some backwards-compatibility issues in the designs of nodes here since there are references to left/right which make assumptions about left->right flows. Certainly some careful testing would be needed to make sure that nodes still made sense visually if the in/out direction was swapped.

Also, how would the decision to "go round the corner" be made? I think it would need some measure of user control at least.

I guess I'm in two minds about this. I think that I've adjusted my flows to deal with the left-to-right flows but then maybe my flows aren't as complex as some people's.

I also think that there are laws of diminishing returns on visual based programming tools. In general, if a flow is getting that complex, it would probably be better to invest in collapsing parts of the flow to a subflow (and maybe the node creator) or making use of the link return features to create separate "functions". Either way, breaking the flow into more manageable sections. In extreme cases, I think you would get to a point where a custom node would be beneficial. Just saying that, just because you start with a visual tool, not everything needs to have the same level of visibility necessarily.

1 Like

Absolutely. If a flow is too complex to easily follow then refactor it.

how did you get that dialog? (and I tried CTRL DEL, but it doesn't seem to work for me)

@deputynl that is the Action List. There is an item in the main menu for it, or you can use the short-cut Ctrl-Shift-P (or Cmd-Shift-P on MacOs)

The Delete and reconnect action being demonstrated there is in the 2.2.0-beta.0 release.

1 Like

thanks for both parts of that answer!

That I can only agree with and that's why we introduced using the command object design pattern. However, refactoring comes with retesting :slight_smile: We did not have enough time to refactor/retest everything and still have some bigger spaghettis which could look better if there was some way to make them cleaner without retesting them.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.