The more your request handlers resemble the actual production behavior, the more confident you'll get when prototyping and testing with Mock Service Worker. But here's the thing—mocked responses arrive to the client really quickly. Learn how to control response timing and server-side latency by using the "delay" function.
Instructor: [0:00] You might have noticed that developing against a fixed network description is really fast. In fact, our application receives responses almost instantaneously, which is great while iterating on a feature, but it's likely to be different once it starts communicating with an actual production API.
[0:16] We can affect the server response timing in any request handler using the delay() function from MSW. The delay() function returns a timeout promise that we can await in any point in our resolver by making it an asynchronous function.
[0:30] When called without any arguments, the delay() function will create a timeout with a random duration that emulates an average server response time. We can provide an exact delay duration in milliseconds as well. This is handy when working on logic that depends on the server response time, like handling request timeouts on the client, for example.
[0:54] The delay() function can also accept a delay mode. A delay mode is a special string that tells MSW how to delay this response. We can use the real delay mode to emulate an average server response time. It's the same as using delay without any arguments.
[1:14] There is also an infinite delay mode, which causes the request to pan forever, allowing us to develop and test the loading state of our application or its individual components.
[1:23] Since our request handlers are environment-agnostic, the delay can affect the response time for both client-side and server-side requests.
[1:34] For example, if we add a delay to the featured movie's handler, it will affect the initial page load time because that request happens on the server.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!