Is your feature request related to a problem? Please describe.
Quite often you would want a mocked response to behave similar to the actual response in terms of response time. Real servers rarely reply to requests instantly, while using res() would do so.
Describe the solution you'd like
Calling ctx.delay() without arguments should implicitly create a random realistic response delay, similar to the one of the actual server.
rest.get('/numbers', (req, res, ctx) => {
return res(ctx.delay(), ctx.json([1, 2, 3])
})
Possible implementation
Check if the durationMs argument is given to the delay() function:
https://github.com/mswjs/msw/blob/4a49e733ed10cb2b11c1941160d9a46ec21182af/src/context/delay.ts#L8-L13
And if not, generate a random response delay number instead. Something similar to:
res.delay = durationMs || RANDOM_REALISTIC_RESPONSE_TIME
Do we have an idea about what would a realistic response time be?
Maybe something below 100ms would be a good starting point. If the delay range isn't configurable it' probably be a bad idea to set the range too high.
Unfixed delay time will increase commissioning costs. This is unknown to the developer.
According to this ranking the optimal server response time is ~320ms or less. We can generate a random response time between 100ms (fast) and 400ms (slightly over optimal) to be realistic. Any exceeding response time is considered slow, and should be treated as an issue on the server. We shouldn't ship a slow response time as default, as it effectively means encouraging slow servers.
default delay amount should be very short when running in node vs. when running in browser.
Maybe 10ms and 600ms
Good point, @andreawyss. I don't think we handled the difference between the browser and Node.
During unit testing, implicit delay shouldn't be in place at all, imho.
I will work on it!