fix(setupWorker): resolve the "start" promise after the worker has activated #1146
Conversation
kettanaito
commented
Mar 6, 2022
•
kettanaito
commented
- Fixes "setupWorker" Promise may resolve before the worker is activated #1145
- May be related to Initial load request interception #1051, Early request not intercepted in Firefox for most recent msw version #1090
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit fd3ab7d:
|
| // (i.e. when reloading the page after a successful activation). | ||
| if (pendingInstance) { | ||
| await new Promise<void>((resolve) => { | ||
| pendingInstance.addEventListener('statechange', () => { |
There was a problem hiding this comment.
both registration.installing.addEventListener and registration.waiting.addEventListener can listen to the same event 'statechange'?
There was a problem hiding this comment.
@Aprillion yes. Those properties return a worker instance in a different state. But it's the same worker instance as the activated worker, having the same event listeners. This is how you know if a state transitions into another state.
|
🎉 This PR is included in version 0.39.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
