When you use fetch-mock, it allows you to mock HTTP requests made by using the fetch or a library that imitates its API like node-fetch or fetch-ponyfill. It usually supports most JavaScript environments, including Node.js, web workers, service workers, and browsers that support fetch natively or an installed bring pollyfill.
As a front-end developer, we divide features into components and integrate them into the project. So, to better understand and perform unit tests, we use a storybook to represent the features visually. In this blog, I will take you through implementing API by leveraging the Storybook with the help of fetch-mock. Let’s start the process by first briefly understanding the Storybook.
Storybook
We leverage a library to create the product works as an open-source tool for developing the UI components. You can also build the pages in isolation with Storybook, and Storybook UI developers can easily streamline their UI development, testing, & documentation.
Problem Statement
While building the Storybook components, I encountered an issue where the components having some operational changes would call the API from the backend. In such cases, I required data from API to perform visual transitions.
Back-end APIs have requirements related to the type of data you send in the body. But majorly, we focus on the different types of responses our page can handle, which is hard to do when we don’t control it. It is impossible to create Storybook components entirely and make them functional in such scenarios. We should wait for actual API integration to test the UI functionality and fix bugs which is a time-consuming process.
So, to handle these kinds of problems, I started mocking API using fetch-mock.
Solution
‘Fetch-mock’ is a popular library to mock HTTP requests made with fetch. I found that it is effective to use mock for UI development and Storybook.
Example :
In the above example, I have used the variable “mockData” to store dummy data. The JSON object will be the same as the actual API response to my component.
Then in fetchMock, I have used the ‘get’ method because I require the ‘get’ method response of that particular API. You can use other fetch methods also as per your requirements.
Finally, I passed the “mockData” variable as the fetchMock API call response. When the actual API gets triggered, then, if the Storybook fails to find any response, the fetchMock gets the call. As a response, we get data from the variable we have passed while mocking.
Implementation
Use the code below to carry out the implementation.
Code:
Output :
Conclusion
You can now start writing stories that are more efficient and highly dynamic. Extend the development process before switching over to an existing API integration in the project. You can then enjoy the following benefits:
- Handles the states as per the requirement to make the stories more accurate by sending the data we expect from the API.
- Once an API is in place with the developer building it, you both can work simultaneously with no dependency on each other.
- It doesn’t change the mock API and won’t even change the behavior in the backend API.
- UI tests are more accurate; you can avoid waiting for the API integration.
I hope you will carry out the process soon and experience the benefits for yourself. Do share your experience with us till then, enjoy coding!