I'd like to be able to add virtual wires between my own custom nodes and have them behave similar to how link-in / link-out pair does it - shows the normally invisible port with a dashed wire when selected, possibly with many wires leading to other tabs, maintain the linkage even on cut/copy/paste/undo, handle message passing between ... the only customization would be the UI editor so that my custom node can decide the list of selectable source/target nodes based on custom criteria (such as the type of the custom node...)
Currently, it appears that all of the link-in / link-out node functionality is hardcoded in the dashboard based on their node.type but it would be nice if custom nodes could somehow specify if the node is to be treated as a link-in or link-out node by the dashboard (sort of, subclass the custom node from either of the built-in nodes).
I'd also like to be able to program any additional custom logic into such node (hence the custom node) such as show my own status, process incoming messages... not be limited to just the link - duh
I know that all this can be done using additional link-in and link-out nodes to the flow, but there are two problems with that for me (as I build large, complex flows): 1) The extra clutter (link nodes and wires leading to them) 2) Link selection UI - my custom nodes could limit the list based on additional criteria such as the node type, name... For example, only show matching nodes with the same name and a specific type...
If possible, it would also be great to be able to add dynamic links, say to all nodes of a given type with specified name ... or whatever the criteria is needed ... similar to the topic-link or an option for link-in / link-out to link by link.name so if I have several links with the same name, they'd be all linked together automatically.
This sort of thing has been discussed before, for example here and here. The general consensus seems to be that the cost in readability/maintainabilty outweighs the benefits. Not that anything stops you from pursuing the idea if you wish. A word of caution is that the mechanisms supporting the link nodes (as well as the status and catch nodes) are buried deep in the runtime and not available to contributed nodes.
I don't see how this would be any different from the current link-in and link-out nodes?
Once I select my own custom IN or OUT node, it would show the virtual wires with dashed lines and possible links to other flows just like the link-in and link-out does right now ...
I'd just like to add the same virtual wiring to custom nodes so that my nodes can control the selection of possible source/target nodes to link to in the editor and to avoid the extra clutter with extra link nodes in the flow as well as limit the number of regular link nodes showing up in their own editor.
Granted, the code to handle these virtual wires is buried deeply in the NR code so it may not be an easy task to support the same functionality for custom nodes ... however, I'm positive that other developers will be grateful if this was possible - see the topic-link node for example or other clever routing, linking nodes people might build where it's very hard, right now, to track what they link to - something you said would be the case with (not without) the virtual wires
If you could give me some pointers where to look for that hard-coded functionality in the NR code, I'll see if I can manage to make it available to custom nodes and if I succeed, I'll submit my proposal for adding it to NR - if you don't mind?
They currently show the links if you select them. And it is still possible to get lost if you aren't careful. I am always careful to sensibly name my link nodes.
OK, so that helps.
But why not just use a link node? Why all this trouble? The advantage of the link nodes is purely to allow you to have tidy flows.
You are going to a lot of potential effort for little reward it seems to me. At least with the link nodes, there are only 2 node types that do this. If you add loads more, I still think that will add lots of complexity and confusion for little gain.
Perhaps some will. But I will certainly be very cautious indeed in adoption.
uibuilder might be considered a node that would benefit from virtual wiring but I actually don't think it would. Because you want to build up nodes around the uibuilder node to handle connects/disconnects, outbound msgs triggering new input, caching and much more. The link nodes are ideal, it wouldn't in any way help to have the links going direct into the uibuilder node.
It is a free world (well bits of it are anyway) and Node-RED is open source. In any case, not up to me, I'm only another developer. Nick is the one mostly in charge of the core.
Not quite the same idea as the gate discussed at the links you've pointed ... if I understood it correctly.
In my case, I still link exactly the same way as link-in and link-out does (and yes, I can just use them), but the main benefit I'd like to introduce is to allow custom node developers gain control over which other nodes they can link to (the list showed by the link editor - right now shows only other link nodes and shows all of them so the list could get huge - custom node can show only matching custom nodes with any kind of additional filtering that makes sense to that node as well as handle wildcard matching).
For example the topic-link could benefit from this idea as it currently has no means to visually show its virtual wires so it's very hard to see where it leads to / from.
In my own nodes, I've added a list of sources/targets in the node editor (built by oneditprepare) but that requires the user to double click the node and open editor to see the other nodes, and if they're not on the current screen - to indicate on hover as the link nodes do - then the user doesn't know where each node is (well, I can show the flow name next to it I suppose but the ability to click on the flow name to show it in the editor is a much better solution already in place for link nodes)...
Even the wildcard matching of the topic-link would work with the current functionality of virtual wires because the editor would add internal links between nodes as they're being added/updated...
Only dynamic links (added at flow init time) would not be showed as they're unknown to the flow editor at the design time, but that's OK, we can live with that limitation
I wanted only to connect gate and gate-control nodes, but once that was done it would obviously allow connecting almost anything with almost anything else.
Sorry, that's beyond my knowledge of the NR core. I will be very interested to see whether you succeed, though. You may well encounter serious reservations about changing the core in such a fundamental way, enabling contributed nodes to affect message flow in less than transparent ways, but, as you say, other developers may like the idea.
When I developed the topic-link node, I indeed considered multiple other options and also looked into how the core link node is implemented.
Basically, the core link node uses the same wire mechanism as normal nodes do. There is code in the runtime that adds the wire property.
This has the advantage that if in the future pluggable message routing will arrive (1.2.0?), it would work with the link nodes, at least in my understanding
I actually had a version of topic-link which made use of this mechanism as well. I can't remember why I decided to go the other way (I guess due to the more dynamic nature, but I am not sure anymore)
I considered having the visual indicator similar to the core link node, but, given the more dynamic nature, I thought it might not be worth the hassle...
EDIT: Here are some of the locations where you can find the wiring of the link nodes in the core
node-red/packages/node_modules/@node-red/runtime/lib/nodes/flows/utils.js in the parseConfig function
This sounds similar to the idea discussed in a recent thread - Restricting connections between custom nodes - and I think the conclusion, and certainly my thought, is that restriction connection types is not really a good idea for several reasons. For example, new nodes might be unable to connect to yours even though it would be valid, or someone might think of a clever use for your node but be unable to link to it.
Can you maybe describe the sort of use-cases where restricting connections would make sense, and not limit future uses of a node?
@molesworth I'm afraid there's a misunderstanding of my proposal.
I didn't intend to LIMIT any connections to/from my custom nodes via regular wires - if they have ports defined anyone can link to them as usual.
What I was describing was the node editing UI which currently (for the link-in / link-out nodes) shows a huge list (in my case) of other link nodes in the workspace. When I have a custom node that makes sense to link only to its matching pairs, it can limit the nodes listed in the UI to be picked for the virtual link. For example, I have a link node that allows you to choose a configuration node and then it shows all its paired custom nodes that use the same configuration node (belong to the same 'logical group'... Linking it to a node from another configuration 'group' wouldn't make sense, but if someone insists on doing so, they can do it using regular wires
Ah, thanks. That makes more sense. I've not spent any time looking at the internals of Node-RED, so I've no idea how you would do this, so I'll leave that to the experts
