How to mock third-party resources loaded in the <head>? Wait for the worker to start before document request? #463
-
|
The documentation did a good job of warning me that <!-- not sure if I'm using these attributes correctly, blocking ESM is confusing -->
<script blocking="render" async type="module" src="/mock-third-party-script.js"></script>
<script async type="module" src="https://third-party.com/script.js"></script>where However, I don't understand how to make it work. I could, inject the script after the promise is resolved, but I would like my mock to be unobtrusive, so that I can comment it out or uncomment it as I please. Is there a way to wait for worker to start, and only get the browser to do the intended document request? I looked at the Epic Stack, but they seem to do it at the server level, which wouldn't work for third-party resources AFAIK. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
Hi, @silvenon. I believe you have to get the worker registered first, then once it is, as long as those resources issue a fetch request, you should be able to define a request handler for it in MSW and handle them. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your fast response! That works AFTER the worker has started, but because starting the worker is asynchronous, the browser parsing moves on and my actual third-party script starts loading before it has been mocked. Removing the third-party const worker = setupWorker(
http.get('https://third-party.com/script.js', () => {
// ...
})
)
worker.start().then(() => {
const scriptEl = document.createElement('script')
scriptEl.async = true
scriptEl.type = 'module'
scriptEl.src = 'https://third-party.com/script.js'
document.head.appendChild(scriptEl)
document.head()
})because then the browser starts fetching after the module has been mocked. But I don't want to remove pieces of HTML and re-insert them. I want my mocking to be casual, in a way that makes it easy to plug in and out. The only feature I could think of that could make browser wait might be top-level await, but I'm currently not in ESM, so it's not an option. I'm looking for recommended patterns that gets worker registered before the document starts loading, i.e. something SSR-friendly. |
Beta Was this translation helpful? Give feedback.
-
|
But since the worker activates once, you have this race condition problem only once. As soon as the worker controls your page, it will see those resources on initial page load, and there will be no race condition to interfere. It should be able to handle them then. Is this what's happening? |
Beta Was this translation helpful? Give feedback.
-
|
I think so, yes. But I might want to edit that mock and I will have repeated race condition… Also, my developer tools is set to disable cache when it's open, not sure if that affects registered service workers, probably not. I guess I'll have to accept this tradeoff, there probably isn't a native way to halt execution. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I think this is just one of those limitations of service workers. Handler updates don't require worker updates so you are free to edit your mocking logic and have no race conditions again after the worker has registered the first time. The worker only ever needs to re-register when the worker script itself changes (e.g. you update MSW). |
Beta Was this translation helpful? Give feedback.
Yeah, I think this is just one of those limitations of service workers. Handler updates don't require worker updates so you are free to edit your mocking logic and have no race conditions again after the worker has registered the first time. The worker only ever needs to re-register when the worker script itself changes (e.g. you update MSW).