Single instance subflow

Core Development Feature Requests
21

I'm certainly not against it, but for that to happen, Nick has to approve. And with the other proposals I'd like him to look at, I'm giving him a lot of work :sweat_smile:

22

I'm really interesting about the topic because I fully understand the need.
I'm using myself some subflows with a complex mechanism to use it almost as a singleton subflow:

  • lock/unlock mechanism inside the subflow stored in flow/global environment object
  • all input states needed are stored in flow/global environment object
  • if sublow is not locked, lock it and process the flow
  • if subflow is locked, then only stored input to flow/global environment that could be used by the first flow

As an example usage, I got events of presence sensors and lights controls and I need a subflow to manage automatic lights based on presence sensor values that take as input an object with a couple sensor / light. Obviously I want to reuse the same subflow for different couple sensor/light and I wish to reuse the same subflow for new events related to the same couple of sensor/light.

Practically a single instance subflow could be done by adding a subflow option "single instance by node call" that bind the subflow instance to the node id that call the subflow. It means that if the option is checked there is only one subflow that can be use and reuse from the same caller node.
If multi-binding is needed it means there is the need of a subflow instance variable that will be used as subflow instance id.

Both can be only one option if there is a variable that can represent the parent node id.
It would result in a single instance by caller node (using $caller_node_id as value) or a single named instance that can be used by several caller nodes (using an instance name).

2 Likes