It's not uncommon to have nodes connected many-to-many. Visually this is a bit of a mess, so I have created a subflow, which I called X, that just has one input and one output joined together like this...
Then I can tidy things up like this...
It's still pretty ugly, but you get the idea - all of these inputs go to all of those outputs. This could also be done with an "empty" node (eg.
function), but then you'd want to name it as a reminder it was empty. It would be nicer and tidier if there was a small link-like node built-in that provided this convenience.
The example I've used is a bit trivial with 2 inputs and 2 outputs, but I have others where there's nodes joined all over the place.
the most efficient way to achieve this with the existing palette is a Change node with its default rule removed. You can also modify the node's appearance to hide its label to make it visually distinct - much like the Link node's default appearance.
We've discussed the idea of a
no-op type node before - it has never quite managed to tip the balance of value it brings vs the cost of adding another node to the palette vs the various existing ways the problem can be solved.
Damn you, that's not a bad solution. I've being foiled again!
You could even change the default icon, for example using
fa-link so you know exactly what's the purpose of this "join" node ...
I'm curious, is the subflow method slower than a change node ?
Well the code path is two calls longer, but they are just jumps so should not be noticeable on a pipelined processor.
Actually, given the way subflows work, an empty subflow will appear as just a single node in the runtime, so will be imperceptibly faster because it doesn't have to check for any rules like the Change node does.
The main difference will be the memory usage; subflows have a larger footprint.