since I urgently needed an equivalent for function nodes which are backed by a separate flow rather than JavaScript code, I wrote node-red-contrib-reusable-flows.
My requirements turned out to be much more difficult to meet than expected, as the Node-RED editor is not yet designed to handle dependencies between several nodes.
It took me more than three days of hacking and experimenting to reach a state I could live with. I'm not proud at all of the resulting code since I had to learn during programming rather than being able to plan first and implement afterwards...
But it seems to work now.
Please consider the current state as "pre-alpha" as it has only been "smoke-tested" yet and still lacks a set of automated tests (which I currently do not know how to implement, though)
Nota bene: I know that some people do not like nodes like those provided by "node-red-contrib-reusable-flows" and prefer to see such functionality to be implemented in Node-RED itself - but I needed it now and could not wait for a new Node-RED version.
Feel free to play with my code and raise issues if needed - any feedback is welcome!
I look at the readme, and I see it lists 4 different very similar concepts. Personally, I would have gone with subflows regardless, but that's not what this topic is about.
You mention in the readme, and in this post that the issue is with their use of caller/callee IDs. I see you're a contributor on the node-red-contrib-components repository. Is it something that can be worked through in the design of the contrib-components library, or is it impossible to combine this in that same set of nodes. I ask this because you describe it as that design concept causing problems, so wouldn't it be preferable to have those problems fixed/evaded initially?
Well, right now, I can't tell you whether the issues of "node-red-contrib-components" are due to its design or its implementation. However, referring to nodes by their unique id already caused some problems.
I've already promised the creator of "node-red-contrib-components" to check if I can reproduce the last problem which finally dealt that package the death blow in my own flows: once upon a sudden (I think I just restarted the Node-RED server) many "component use" nodes emitted messages when a single "component use" node was triggered. That immediately broke all my flows and kickstarted my own development as I cannot wait for these bugs to be fixed.
At first glance, it seems that these requirements will be met by the link call modifications to the link nodes that Nick worked on in the latest live stream. If the feature makes it into the version 2.1 beta, that will be an opportunity to see whether everyone can be happy with the result or if more work is needed.
Thanks to a nice soul who raised a GitHub issue, "node-red-contrib-reusable-flows" are now part of the Node-RED library and can be found alongside the already well-known "node-red-contrib-actionflows" and "node-red-contrib-components".
I just updated the docs to explain the relationship between "reusable flows" and the new "Link Call" nodes (with "Link Out" nodes put into "return" mode) and explain the installation from within the Palette Manager.
A new version has only been assigned in order to enforce an update of the documentation in npm and flows.nodered.org
I'd just like to say, that this looks like a fantastic bit of work and your documentation is superb
Obviously, the new inbuilt link return core feature is going to be the goto technique to use for simple cases but you've created a great facility if we ever need more than that
