Setup global modifiers for all mocks?

[Geddard]

Hi there!

I've been trying to figure out a nice and maintainable way of setting up some global controls for all my mocks.

The first one that can be a good example would be to add a global delay for all responses, or maybe all get responses.

I can't find any case like this anywhere :/ And i don't want to have to go and add ctx.delay(x) to each mock handler i created... In my head the ideal would be to create either some global handler that adds the delay to all other mocks at some point in the msw lifecycle, or by adding it to .start() or .use()

But i can't find documentation and can't figure it out myself...

Any ideas on how to achieve this?

[kettanaito]

Hey, @Geddard. Thanks for raising this question.

MSW strongly encourages its users to compose, instead of relying on any configuration options. The latter is almost always limiting and won't satisfy each and every use-case, while the composition will.

When it comes to composing MSW logic, you need to figure out on which level you wish to introduce the customization. In your case, you wish to add a fixed response delay to all response resolvers you write. I'd suggest creating a custom response function that encapsulates your delay requirement:

// ./resWithDelay.js
import { createResponseComposition } from 'msw'

export const resWithDelay = createResponseComposition({
  delay: 500
})

Then use the resWithDelay instead of the default res function in your response resolvers:

// ./handlers.js
import { resWithDelay } from './resWithDelay'

export const handlers = [
  rest.get('/user', (req, _, ctx) => {
    return resWithDelay(ctx.json({ firstName: 'John' }))
  })
]

This type of customization scales well and gives you control over the custom logic you wish to have.

In a similar fashion, you can create custom request handlers and context utilities.

[kettanaito]

If I understand your expectations correctly, I think the best solution I can suggest at the moment is to create that mapping between the UI form you give to your testers and the resolver logic in the custom resolver as I've shown above. The workflow may be implemented like this:

1. A user edits the UI form in the modal.
2. Each form input change updates the corresponding URL query parameter. That's also how the options persist.
3. The custom response resolver parametrized the mock's behavior based on the query parameters it parses from the current location.

I'd like to help you achieve your idea, but I don't find the configuration being a solution.

[Geddard]

If I understand your expectations correctly, I think the best solution I can suggest at the moment is to create that mapping between the UI form you give to your testers and the resolver logic in the custom resolver as I've shown above. The workflow may be implemented like this:

1. A user edits the UI form in the modal.
2. Each form input change updates the corresponding URL query parameter. That's also how the options persist.
3. The custom response resolver parametrized the mock's behavior based on the query parameters it parses from the current location.

I'd like to help you achieve your idea, but I don't find the configuration being a solution.

I don't really care about this being a config option or something else, but I think having a global delay could be quite useful.
Like I mentioned, something like the throttle that can be configured in the Network tab, or maybe make this throttle affect msw somehow.
But if there simply there is no way now, then I'll have to settle for updating all my handlers at some point to support a configurable delay.

[Geddard]

Well, what you described above is arguably a different use case, although it can still be achieved without resorting to configuration. If you wish runtime to affect your mocking layer, then I suggest encapsulating your abstraction in a custom response resolver. Roughly, like so:

export function withDelay(handler) {
  return (req, res, ctx) => {
    // Grab the custom "?delay=N" query parameter on the page
    // where the request happens.
    const urlParams = new URLSearchParams(location.search)
    const customDelay = urlParams.get('delay')
    const mockedResponse = handler(req, res, ctx)
    
    // Set the mocked response delay if it hasn't been set already.
    mockedResponse.delay = mockedResponse.delay ?? customDelay

   return mockedResponse
  })
}

rest.get('/user', withDelay((req, res, ctx) => {
  return res(ctx.json({ firstName: 'John' })
})

Yes, it feels like writing your custom setup, because it is. It's your setup and you should be in charge of it. Keeping a declarative abstraction that you explicitly use in your handlers is both evident and powerful.

Hey there again, im trying this approach at the moment, and when i console.log the .delay property in the mocked response, it seems to be there when i execute the call i need but the delay doesn't happen.

Should i take some other step besidesd adding this wrapper?

I tried doing worker.resetHandlers with and without params (the params would be the newly formed handlers i think

[kettanaito]

Hey there again, im trying this approach at the moment, and when i console.log the .delay property in the mocked response, it seems to be there when i execute the call i need but the delay doesn't happen.

That's interesting. May I please ask you to set up a reproduction repository for me to look at this? That'd help a lot.

[Geddard]

Hey there again, im trying this approach at the moment, and when i console.log the .delay property in the mocked response, it seems to be there when i execute the call i need but the delay doesn't happen.

That's interesting. May I please ask you to set up a reproduction repository for me to look at this? That'd help a lot.

That might be not possible for a long time, could you confirm to me if i should actually resetHandlers from the worker (or server) after updating the global delay value?
Or maybe just hint me to which steps you would take after updating the delay value