feat: convert action-triggers computation to async #1310
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
About the Contributor
This pull request is posted on behalf of the BBC
Type of Contribution
This is a: Code improvement
New Behavior
The action-triggers logic is shared between the meteor backend and the webui. This is currently written using sync mongo queries which works in meteor 2, but is not compatible with meteor 3.
This PR reworks it to be using async mongo queries, so that it is ready for meteor 3.
This has become quite a complex task, to figure out how meteor trackers behave when async, and figure out the correct interaction of computations when this happens.
To make this work, the
meteor/tracker
implementation that was copied into the webui has been updated so that it supports async operation.This triggers code is very explicit in passing around a
computation
parameter, partly because async meteor requires this and also because it makes it easier to follow what is reactive and check that it will be using the correct value.the globalTracker.currentComputation
will not be correct after anawait
usage, forcing us to either rebind itTracker.withComputation(computation, async () => { .... })
or by passing the computation to where it is needed ourselves.Perhaps a follow up PR should be taking this a step further, and inside of the webui remove the global
Tracker
object, making it so that we always manually pass around the tracker objects? This would be quite a sprawling change to update every place we are using a tracker the ui.This PR includes the changes from #1308. It is also dependent on #1309, to ensure that the correct reactivity is visible in the settings.
Testing
I have performed some manual testing by checking that the hotkeys are updating in the shelf while playing out a rundown, with a connected input gateway, and in the settings.
I am not confident that I have sufficiently tested every scenario, as I do not know the area well enough to know what should be tested. Any help or pointers in testing this would be appreciated.
Affected areas
Time Frame
Other Information
Status