Feature Request: Allow link call to set it's own context for flow variables

Hi NodeRed devs!

I have been an avid user of NodeRed over the past few years, but fairly silent on the community. I have built fairly complex flows and today I bumped into an issue that could be solved fairly easily with a new feature.

I have a methodology where I reuse flows using link calls, in some cases I reference link in nodes from another flow, as this allows me to have a single definition of a flow across multiple flows which I think is the whole purpose of the link in node.

A really useful feature would be to have a checkbox on a link call node configuration to use the flow variables in the flow that it is called in, so any subsequent calls in the child flow/nodes to flow.get would instead look at the parent "calling flow" variables.

I hope this makes sense, I am happy to answer any questions on this but I think it would allow us to create flows that are more reusable and configurable.

J

I think I understand the request however my (quick) answer would be no - that is not possible. The nodes use their parent/owner ID to determine which context store to use and off the top of my head, I am not certain how that could be intercepted. Not saying it is impossible but I dont see a clear path to how it would be cleanly implemented at the core so as to work transparently with all existing and future (CORE and contrib) nodes and subflows and subflow instances etc.

IMO - the better solution is build your subroutines with the PURE principle in mind - i.e. pass the variables to operate on inside of the msg objects properties, do the necessary work on those in the subroutine, pass the answers back out in the msg object. If necessary, update the flow context from the outputted result. This avoids those nasty timing issues you get when there is any asynchronicity and 2 or more inflight messages change the context mid flow & affect each others result.

The benefit of pure functions are not always obvious but when you hit a bug due to side effects from internal state, async variable access issues, or come to port your code, you will wish they were pure.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.