How are multiple handler matches supposed to behave?

[RyanClementsHax]

Question

I'm using msw-storybook-addon in a react project and a backend I don't control doesn't do routing the normal way, it does routing via a route query parameter. In order to handle modularity better in the code base, I want to specify a handler for each of the different routes my front end might call.

MSW v0.35.0 works just fine and dandy for my use case by running the request through the list of handlers that match and returns the response of the first one that returns a response. The hesitation I have is that this behavior is undocumented. My question is then, is this behavior intended or an accident of implementation details? I'm wondering if this is a behavior I can safely build on top of.

Environment

Name	Version
msw	0.35.0
browser	Chrome 95.0.4638.54
OS	Windows 10 Pro 20H2

Example setup

// in my story
Base.parameters = {
  msw: [
    rest.get(process.env.REACT_APP_BACKEND_URL, (req, res, ctx) => {
      const route = req.url.searchParams.get("route");
      if (route === "some-first-route") {
        return res(ctx.json({ responseFor: 'first-route' }));
      } else {
        return;
      }
    }),
    rest.get(process.env.REACT_APP_BACKEND_URL, (req, res, ctx) => {
      const route = req.url.searchParams.get("route");
      if (route === "some-second-route") {
        return res(ctx.json({ responseFor: 'second-route' }));
      } else {
        return;
      }
    })
  ]
}

Example request

await axios.get(`/?route=${useFirstRoute ? 'some-first-route' : 'some-second-route'}`)

[kettanaito]

Hey, @RyanClementsHax. Thank you for raising this!

We do have the Request matching section but it indeed misses to mention how the library handles the request handler lookup and what will happen when a request matches multiple handlers.

My question is then, is this behavior intended or an accident of implementation details?

This behavior is not an incident, it was always intended. Allow me to clarify it below.

• When a request matches multiple handlers, MSW will use the first handler that produces a mocked response.

msw/src/utils/getResponse.ts

Lines 50 to 54 in f6fbd6c

	const result = await handler.run(request, resolutionContext)
	if (result === null || result.handler.shouldSkip) {
	return null
	}

• One request handler must handle one resource. This means that creating multiple handlers with the same URL to utilize the lookup logic is not recommended. Instead, include any branching logic into the handler directly:

rest.get(process.env.REACT_APP_BACKEND_URL, (req, res, ctx) => {
  const route = req.url.searchParams.get('route')

  switch (route) {
    case 'first-route': {
      return res(ctx.text('first'))
    }

    case 'second-route': {
      return res(ctx.text('second'))
    }

    default:
      return res(ctx.status(404))
  }
})

You can learn more about Conditional responses.

• Fallback behavior is intended for ambiguous matches. There are situations when a request matches a handler but that handler was not intended to manage that request. This is mainly applicable when working with path parameters and arbitrary paths that may match them.

// List this handler first, so that "/user/me" doesn't match "/user/:id"
// where "me" would be considered the value of the "id" parameter.
rest.get('/user/me', (req, res, ctx) => {
  return res(...)
})

// Handle other, intended requests.
rest.get('/user/:id', (req, res, ctx) => {
  return res(...)
})

With that being said, I recommend you rewrite your handler and put any logic that affects the response in that handler. In the end, collocating logic with the handlers (resources) will make your mocks more evident and easier to browse through.

[RyanClementsHax]

Ah thanks for the clarification. I do recognize that my use case is very odd. I'll just use switch statements. Thanks for the help!

[kettanaito]

Yeah, I think using switch will have the same effect in your case. Please feel free to mark this as an answer. If you feel something else is unclear, don't hesitate to ask. Thanks!