Intercept requests with query parameters

[AndrianStoikov]

Hello,

I was considering using msw for our test setup. However, due to specifics in our nginx configuration all our requests are of the form ?resource_name. Looking through the docs and doing my own experiments it didn't seem to have an easy way to catch those requests such as rest.get('?resource', ...) and I had to manually write if statements for all requests. Am I missing something and is there a way to achieve what I am trying to do?

Best,
Andrian

[kettanaito]

Hey, @AndrianStoikov. That's a great question.

Since you're writing a server-side behavior with MSW, we disregard request query parameters during request matching. We do so because query parameters are additional information to the request but not request identifier like the request URL/path. You can still access the query parameters so they are not ignored in that manner.

Due to the constrains of your setup, I don't think it's viable to perform conditional checks for the query parameters in all handlers every time. I would recommend creating a custom request handler in your case where you'd abstract that check.

Custom request handler

function toResource(queryParams, resolver) {
  return [
    // Here I'm assuming that all requests happen to the same static
    // endpoint, and you want to base your request matching off the query params.
    staticEndpoint,
    (req, res, ctx) => {
      const matches = Object.entries(queryParams).every(([name, value]) => {
        return req.url.searchParams.get(name) === value
      })

      if (matches) {
        return resolver(req, res, ctx)
      }
    }
  ]
}

export const handlers = [
  rest.post(...toResource({ resource: 'customer' }, (req, res, ctx) => {
    return res(ctx.json({ id: 123 }))
  }))
]

You can design whichever query parameter matching logic you want. I went with an object matching above, you can do a plain string if it's only the ?resource parameter value you're interested in.

Would this abstraction work for your case?

[AndrianStoikov]

Hi @kettanaito,

This seems like a solution. Thank you for the great answer! I have to find some time to test the setup again. I’ll mark the question as answered.

[AndrianStoikov]

Hi @kettanaito,

These days I am experimenting with msw. This solution works perfect for us. Thank you one more time!

[kettanaito]

Just a fair note of warning that you don't really have to design additional steps just to access query parameters. I'd treat this use case as a rather edge case because most of the requests you work with comply with the RESTful paradigm, representing resources in the request path vs query parameters.

[kellyrmilligan]

what about list requests with different filters?

[holylander]

thanks a lot @kettanaito & @AndrianStoikov, your approach help me a lot to build this fetch interceptor handler constructor.
I noticed that all I had to do was to not return the handler, if conditions were not met ( full url match )

const fetchInterceptionHandler=(targetUrl, responseStatus, method, response) =>
    rest[method](targetUrl, (interceptedRequest, fakeResponse, ctx) => {

      if (
        targetUrl === interceptedRequest.url.href
      ) {
        return fakeResponse(
              ctx.status(responseStatus),
              ctx.json(response)
            );
      }
    });

[kettanaito]

Even better, be explicit about the "conditions not met" scenario by returning req.passthrough():

if (targetUrl === interceptedRequest.url.href) {
  return fakeResponse(...)
}

+return interceptedRequest.passthrough()

This instructs MSW that in this handler you're intentionally says to passthrough the request. It makes quite a difference for the tooling to know that you haven't simply forgotten to handle the request by returning undefined.

[holylander]

thats true! I saw that it the docs... didnt include it since my project msw version is a bit old, but will update the syntax once we get package latest version ;) thankss

[kettanaito]

Yeah, it's definitely worth updating and using explicit req.passthrough(). We retain this API even with the upcoming Fetch API support (see #1464), it will only be accessed differently. No need to worry about that at the moment.

[kmiwa007]

Thanks for posting this @kettanaito. Do you think it's possible create a similar abstraction that accesses the request body instead of query params? One thing I'm stuck on is dealing w/ the async nature of accessing req.json() which returns a Promise. Because of this, I have to do create the entire handler in an inline async function rather than in an abstraction.

ex.

  rest.post('/json'), async (req, res, ctx) => {
    const body = await req.json();

    if (body.method ===  'foo') {
      return res(ctx.status(200), ctx.json({ foo: "bar" }));
    }

    return req.passthrough();
  }),

[kettanaito]

Hi, @kmiwa007. You can certainly abstract as much as you want, including the asynchronous reading of the intercepted request bodies. Instead of abstracting the first argument to the handler (the request path), you will be abstracting the second (the response resolver). We have some examples of that in the docs. This is nothing specific to MSW, just JavaScript.

[kellyrmilligan]

FWIW, here's my scenario, and only returning undefined if it doesn 't match seems to be working for me:

• I have 2 calls to the same get enpoint, with different sets of querystring params, to get a list of data back
• I have a small abstraction of get, that just saves boilerplate.
• I am using react query, with retries set at 1 and cache at 0 for the testing environment
• msw 1.3.2

get util:

export const restGet = (
  url: string,
  response: JsonValue,
  options?: RestGetOptions
) =>
  rest.get(`${process.env.REACT_APP_API_BASE_URL}${url}`, (req, res, ctx) => {
    let isSearchMatch = false
    if (options?.searchParams) {
      // determine if the search params match
      const matches = Object.entries(options.searchParams).every(
        ([name, value]) => req.url.searchParams.get(name) === value
      )

      if (matches) {
        isSearchMatch = true
      }
    }
    if (options?.once) {
      if (options?.searchParams && isSearchMatch) {
        return res.once(ctx.status(200), ctx.json(response))
      }
      if (options?.searchParams && !isSearchMatch) {
        return undefined
      }
      return res.once(ctx.status(200), ctx.json(response))
    }

    if (options?.searchParams && isSearchMatch) {
      return res(ctx.status(200), ctx.json(response))
    }
    if (options?.searchParams && !isSearchMatch) {
      return undefined
    }
    return res(ctx.status(200), ctx.json(response))
  })

usage:

server.use(
      restGet(
        "/api/v1/buildings",
        mockResp,
        {
          searchParams: {
            ids: "155",
            filter: "recommended",
          },
        }
      ),
      restGet(
         "/api/v1/buildings",
        mockResp2,
        {
          searchParams: {
            ids: "155",
            page_size: "2000",
          },
        }
      ),
    )

maybe it is better to have 1 resolver in this scenario vs 2?