Mirage JS lets you mock out production APIs directly alongside your frontend React code. You can tweak the data or force a network request to hang, so you can quickly design different states of your application. In this way Mirage lets you build every state of your UI regardless of the state of your production API.

Check out [Mirage's React quickstart here](https://miragejs.com/quickstarts/react/develop-a-component).

https://app.egghead.io/api/v1/lessons/javascript-mock-an-api-for-local-development-in-react-with-mirage-js/subtitles

Mock an API for Local Development in React with Mirage JS

Sam Selikoff: [0:00] I'm working on this Hires page which fetches some data from the server. If we reload the app, we can see that React makes a GET request to /api/hires, and the server responds with the data that powers this page.

[0:16] Let's mock out this endpoint so we can control the data as we develop this UI. I'll stop our development server and run yarn add miragejs. Now that Mirage is installed, we can start up the dev server again.

[0:37] In the top of our Hires component, we can import { Server } from "miragejs" and create a new Server(). If we check out the console in our application, we'll see that Mirage has thrown an error, "Your app tried to GET '/api/hires', but there was no route defined to handle this request."

[0:59] Back in our code, we'll pass in an options object to our server and define the routes() Hook where we can mock out this endpoint. We'll use this.get since this is a GET request, we'll pass in /api/hires as the URL, and then we'll write a function that returns our response.

[1:22] Now we can see there's no more error. Mirage is handling this API request with a 200, but there's no data. If we comment out Mirage, we can grab our production data from the network tab. We'll come back to our server and return this instead. Let's just return a single new hire.

[1:57] Now that we've mocked out our route, let's see what our app looks like when there's no hires. Looks a little confusing. Let's go ahead and add an empty state to our UI. Before we render our table here, we'll go ahead and check if hires.length === . If it is, let's render a message that says, "There are no new hires." Otherwise we'll render our existing content.

[2:29] We can now easily tweak the design of this new application state. Let's make this text-gray-500 to make the message a little bit softer.

[2:41] Let's return data from our mock endpoint again. Now, when we reload the app, we see our new message for a split second. That's because we're not accounting for the loading state. Let's do that by updating our UI. Instead of starting out hires as an empty array, we'll start it out as null.

[3:06] Then down in our render function, we can add a new check. If we don't have any hires, we'll say that we're loading, otherwise we'll continue on with our rendering. Now we can see the loading message when we first load up our app.

[3:30] Let's return a new Promise that never resolves to force our app to stay in the loading state. We can now work on the UI in this case. Let's center the text, make it a little bit larger. We'll also make the text a little bit softer. When we remove this Promise, we should see our new design loading state.

[4:04] We can continue to work in this way as we develop every screen of our UI application. For example, we could put our new hire into the rejected state to work on that. Once we're ready to ship our code to production, we can disable Mirage without changing any of our component code. That's because Mirage works by mocking out HTTP rather than any of our application code.

Mock an API for Local Development in React with Mirage JS

Share this video with your friends