Hello, I've done a node to try to get subflow linking, the idea is to be used inside subflows to give like a subflow to cast messages or to get inputs into subflows from other subflows.
The ideia is to be as light as possible, and to have as little impact as possible in the system! Since all new node creates a new instance, the broadcast of the messages is handled by the config node, and basically each config is a new link.
The user can opt by cloning a message, and this can be selected in the config (clone all messages of the link) or in the output (only clone messages in that output). The idea is to only clone outputs when needed, to avoid cross node changes to the message.
Normally I don't like to reference people in posts, but I think @knolleary feedback could be very useful in this situation, since this is something that never was added to nodered core.
The basic idea of Node-RED is that messages flow along wires and are visible so that it is easy to trace the flow. These nodes create invisible paths so are not in that spirit, so unlikely to be part of the core.
Hello, thank you for the replay, I don't mean it to be part of the core, but I would like some expert opinion on the idea of solution, and code. Something like this, I think, it's very useful and can power the subflows to another type of use cases! I know that I always looked ate solutions to this lack of functionality, and now decided to try to make a node to help in this!
If you have one of you inputs inside a subflow, and you have 100 instances of the subflow in your flows do they all get the messages sent to the input?
I noticed now that you where asking about inputs... The input node is just like a normal link input node, but I can set it inside a subflow and link it to a output node in a different subflow... or add a input in the main flow and a output in subflow...
If a input casts a message to a output that is inside a subflow, all instances of that subflow will recive that message.
In the other hand, if a input is inside a subflow, all messages that enter all instances of that subflow will cast a message that will arrive in all output nodes that are linked.
Notice that you can have multiple outputs to one input, but each will only be linked by a link... Making that to one output node only can receive messages from one input link (this I can change, but for now the link is 1:n, you can't have one output receiving messages from more that one input)
I made a test, to chek if my link node wasn't making some delays, and the results are again good, I used the same test method, a input node casting to 30 output nodes a 1920x1080 image. Then a mesured the time before the input and after the output. This are the results
The Node in The subflow is a bit more slow, but I don't think it's that relevant. The delay might be related with the config node that it's used as a router, but the main idea is to use the config node to manage the links, to avoid having each instance of subflows create new objects with routing data
