bitfocus
action subscriptions are not tracking variable changes as feedback callbacks are
Is this a bug in companion itself or a module?
- [X] I believe this to be a bug in companion
Is there an existing issue for this?
- [X] I have searched the existing issues
Describe the bug
Recently, feedback callbacks started tracking variable changes, and using the new context parameter in the callback, you can use context.parseVariablesInString() with great results!
Even more recently, action callbacks and subscriptions added the context parameter to allow the same functionality. However, for this to work, the subscription needs to be called whenever a variable used changes, as it does with the feedback callback.
Steps To Reproduce
Create an action with a subscription Use a variable for a parameter of the action Subscribe gets called once when the action is created or a non-variable parameter is changed Change the variable's value Action.subscribe is not called
Expected Behavior
Just like feedback.callback(), action.subscribe() needs to be called whenever a variable used in an action parameter's value changes.
Environment (please complete the following information)
- OS:
- Browser:
- Companion Version: 3.0.0+5764-beta
Additional context
No response
It needs some thought on the cost of enabling it for everything, or if it should be opt in (per action or property). Mainly worried about the cost if the variables are updating 10 times a second, or something
The new feedback checking is 'opt in' in that only feedbacks parsing variables will be checked more often
the context parameter was added to allow us to do this at some point, and for consistency in the api
but do we want to be calling resubscribe 10 times a second (possibly slowed by some internal debounces or something) because a variable in value option of the action is changing that often, even though the subscribe call makes no reference to it?
there is also the question of if subscribe can parse variables, does unsubscribe behave sensibly?
- variable has value of 5
- call subscribe on the action, it runs parseVariables and gets back 5
- variable changes to 6
- call unsubscribe, it runs parseVariables and gets back 6
- call subscribe, it runs parseVariables and gets back 6
it makes sense to do this for feedbacks because they are supposed to live react to values, and if it parsed a value then it is highly likely to have its result based on that value.
perhaps the easy solution here is to be tracking what variables were parsed in the subscribe calls, (like we are doing for feedback callback), so that it can be called again upon the change of just the ones that it was interested in.
the same would need to be done for feedbacks, which is not impossible but will start to get fiddly to ensure everything is tracked in the correct list and the flow is correct (but there are unit tests for the current code, so it may not be too horrible)
For sure it only makes sense to track the variables that are being referenced in the .subscribe() or .callback() events.
I thought that's what was being done via the context parameter.
For sure it only makes sense to track the variables that are being referenced in the
.subscribe()or.callback()events. I thought that's what was being done via thecontextparameter.
For the feedback callback it is, the other callbacks are currently not doing the tracking.
But it was the purpose of the context parameter, to allow us to do this tracking