As I become more familiar with NR, the number of flows I have is growing. I'm now at the point where a half-dozen of my flows need to send emails. I've been copying/pasting the email node into the new flows, the doing the configuration.
Today, I found out I need to make some email server config changes - and I'll be opening up all the flows, changing each config on the email nodes.
Surely there's a "GOSUB <flow.email_node>" style of functionality in NR.
What's the typical convention? How does one, in proper NR style, call a node on another flow?
Or is it frowned upon? If allowed, would I have a dedicted Flow, say "Email" with only the email node in it?
Use the link nodes (link in/out)
Link nodes creates invisible wireless between themself, and they can travel across different flows.
Have 1 link on the email flow, and place a link per other flow to it, that needs to send it a message.
If you need to return from the email flow (like a type of ack if you will) then extend the link nodes with the use of link call nodes.
Link call nodes, act like a subflow, but allow you to re-use portions of a flow in various areas - all whilst still having 1 instance of the logic behind it all.
But yes, link nodes is what you are looking for, so your need is fully supported.
Cool to see so many great ideas like reusable flows and components. Unfortunately they look old and outdated, some have serious flaws like not supporting "new" features like juntion node (!) or break with export/import I would not take a chance on those today.
Link in/out as mentions can be good in some situations, but feels more like gotos. Recently noticed that they don't mix well with certain command messages used for delay node (and possibly other nodes that also take reset or similar commands). At least use with care in advanced situations.
Link calls also are good at what they can do, but leave much to be wanted for other features when comparing to subflows. They got mandatory timeout which is great if you need it, but useless if you don't. Locked to 1 input and 1 output, if you need multiple outputs you still forced to add duplicate switch after every call. You also need to be real careful with the msg metadata while processing, as it needs to retain the value at input to return back.
I think node red would benefit from taking inspiration from these ideas and make a built-in robust quality solution. Tall order I know, but I am here to dream
I would not take a chance on those today.
