Lets go...
Catch nodes, complete nodes, status nodes, even MQTT in nodes could be considered the same.
Not really, it promotes (or at least offers formalised support for) calling reusable flows.
Search is a users friend.
junctions, node.done(), node.path, env vars in a tab, env vars in global flow, etc.
Break eggs, make omelettes (or stay on V1 forever ;))
If a user does import a flow using this feature, they will see TypeError: node.linkcall is not a function. A forum or internet search will lead to the cause. Then they upgrade or use workarounds.
Trust me bro!
Not what I said but...
A way of calling functions (and flows/nodes) has been requested many times on the forum and other places.
The reason/rationale for the introduction of this is to offer a familiar / standardised design pattern that everyone can use (or not) in those times they are inside code execution and want to call out to common reusable code (or flow) routine.
The preference is still always use wires where sensible, but when the wiring logic and overhead becomes too complicated, there is now another option.
Again, I never said I "need this" and as already stated, I already have a working solution, but it is my implementation, using methods that completely bend the rules and is even more opaque than the a formalised feature like node.linkcall is offering.
So here is a more complete flow that demonstrates why I went to the effort of starting a discussion with proposals and then implemented a solution to formalise a better way of making & using utility functions (and flows) from within function code execution.
node-linkcall-demo.json (59.2 KB)
Note again for clarity, I have solved this already (running on Node-RED v4 without node.linkcall) but it is a drag, its brittle, opaque, hard to follow & is my own implementation - so I am genuinely interested to see how others would approach this in a visual/wired way.
