Reasons I use a mock API in React Native apps

I’m doing plenty of React Native applications these days.

Something common to all of them, from a developer experience point of view, is: they avoid calling out to a real API and use fake data instead. If/when needed.

This has been a pretty useful tactic for me. This post will not dive much into how that can be achieved (since there are several ways), and will instead focus on why.

Why

1. The back-end might not be implemented yet.

It’s not unusual for the back-end to be developed along with the mobile application, and to take longer to be implemented.

This definitely should not prevent you from working on the app.

As long as back-end’s endpoints are specified somehow, you can mock them out. The spec can be anything: be it a RAML schema, a text document with the description of endpoints and their response types, or something else.

2. You can develop while on a flight.

Or in other situations when you might not have an internet connection, or be on a shitty connection.

“But you can keep a copy of the back-end locally and use that!”

First off, you can’t always have it this way. Sometimes the back-end is a black box to you, and you don’t have the sources.

Second, back-ends might want exotic dependencies and very careful configuration. You shouldn’t have to do these to develop the mobile app, for the most part.

3. Your productivity can be unaffected if the server is down or broken.

It happens, and we should just deal with it.

Not having to rely on a real API means your productivity stays unaffected.

4. You get to control latency.

You can easily reduce the “latency” of the mock to 0 to develop quickly.

You can easily set the “latency” to a couple of seconds maybe to see how your application would behave in these conditions.

Not talking to a real, remote API means you can control latency.

5. You can simulate errors.

There are a variety of errors the request can end with.

Some are within your control (like sending invalid data), while others are not:

• internal server error;
• session expired.

You can’t normally trigger these by yourself at will if you’re talking to a real API server.

Having a mock API means you get control over these as well.

It means you can easily test that your application behaves properly in cases like “if I get a session expired error, log the user out, show the login screen, and alert them why that happened.”

Mocking comes at a cost, but it still can be useful

Since it requires you to maintain a set of fake data and update the mock when the API changes, you don’t get mocking for free.

That said, the productivity benefits can outweigh the cost of maintaining fake data.

How

There are multiple ways to mock the API. The simplest one is to tweak your API client:

// helper function
// used as: delayedPromise(1000, "hey")
// will return a promise that will resolve with "hey" in 1000ms.
function delayedPromise(ms, value) {
  return new Promise(resolve => {
    setTimeout(() => resolve(value), ms);
  });
}

const USE_REAL_API = true; // change to `false` when needed

function getPosts() {
  if (USE_REAL_API) {
    return fetch(...);
  } else {
    // new: fake data
    return delayedPromise(500, [
      { id: 1, title: 'How to' },
    ]);
  }
}

There are more ways & more to consider when implementing the mock of an API, of course. This post will not go as far as to address that, but I will probably write about that at some point.

I blog about all things React and React Native.
If you like what you see here, subscribe here to make sure you don't miss out on my next post.