Response Patching (following the documentation) does not work about msw HOT 9 CLOSED

from msw.

Hey, @hauptrolle. Could you please open a new issue regarding this server-side behavior in NextJS? I'd kindly ask you to provide a minimal reproduction repository so we can look into it and solve it. Looking forward to that!

from msw.

@kettanaito Thank you for your fast response. I was able to create a reproducible demo and opened an issue :)
#361 Feel free to have a look!

from msw.

Hello, @skipdavis1117. I'm sorry for such experience, there's clearly something off. I'll put down a test for the response patching feature and investigate the possible cause of the issue you're experiencing. Please stay tuned for updates.

from msw.

@skipdavis1117 Hello, can you post the mock code and the startup configuration of the program or keep screenshots of the browser or more detailed information?

from msw.

The main cause for this issue is that the req argument that response resolver provides is not 1-1 compatible with the RequestInit type that window.fetch() expects. This may lead to all sort of quirks, potentially including this issue.

There is also one detail to keep in mind: any requests performed from the client-side are processed via MSW. That includes the window.fetch(req) you may want to perform as a part of your response resolver to get an original response. In case you are mocking the same URL you would like to hit as a part of response resolver, it would throw MSW into an infinite loop. See:

composeMocks(
  rest.get('https://api.github.com/users/:username', async (req, res) => {
    const original = await fetch(req.url, req)
  })
)

Requesting https://api.github.com/users/octocat matches the request handler in the schema, so MSW attempts to mock the response. As a part of mocking you perform an actual fetch() to the same URI. That request is again matched against the mocked schema, and MSW attempts to mock it.

In order to prevent this loop I suggest two things:

1. In order to perform a request bypassed by MSW you should use a newly introduced ctx.fetch() utility. This way such requests are evident and allow MSW to distinguish between mock/non-mock scenario.
2. Properly set a custom flag on the dispatched request using ctx.fetch() under the hood, so that mockServiceWorker.js would check for the flag and bypass such requests.

At the moment I'm thinking of what such flag can be and how to set it on the request object to preserve request semantics. I've tried using a custom header, but then it may result into preflight request violations from CORS policy. I'd appreciate any feedback on this.

from msw.

The implementation is released in 0.9.0.

Resolution

Please see the updated Response patching recipe in the documentation.

In order to use response patching please perform a request to the actual resource via ctx.fetch() utility function. Here's a tested example of response patching in action:

https://github.com/open-draft/msw/blob/39e2e3fc0f1120496ed9337a01834fd4e51be50f/test/rest-api/response-patching.mocks.ts#L3-L31

Why ctx.fetch() over window.fetch()?

Using ctx.fetch() implicitly sets a special header on the request that, whenever present, tells MSW to bypass this request and actually perform it. You can still use regular fetch(), but requests performed with it will be subjected to mocking.

@skipdavis1117, could you please update to 0.9.0 and let me know if following the example in the docs works for you? Thanks.

from msw.

@skipdavis1117, warms my heart to hear that! Thank you and hope that MSW keeps up with your team's expectations. Looking forward to hear some feedback post usage.

from msw.

Thank you so much for that example! I already implemented MSW in our Nextjs project.

But I have one question: When adding response patching, I always get a Request with GET/HEAD method cannot have body error. But only on the server-side of Nextjs. Any ideas why this is happening? For client-side requests, everything works fine...

from msw.