Handling API request race conditions in React

Note: this is best read on my website. The original post includes runnable React demos that I had to remove, as LinkedIn does not support MDX. Also please tell me if you see any typo, as the conversion process is error prone.

---------------------------------------------------------------------------------------------------------------

Intro

Many blog articles talk about loading api/async data in a React apps, with componentDidMount, useEffect, Redux, Apollo...

Yet, all those articles are generally optimistic, and never mention something important to consider: race conditions could happen, and your UI may end up in an inconsistant state.

An image is worth a thousand words:

You search for Macron, then change your mind and search for Trump, and you end up with a mismatch between what you want (Trump) and what you get (Macron).

If there is a non-null probability that your UI could end up in such a state, your app is subject to race conditions.

Why this happens

Sometimes, multiple requests are fired in parallel (competing to render the same view), and we just assume the last request will resolve last. Actually, the last request may resolve first, or just fail, leading to the first request resolving last.

It happens more often than you think. For some apps, it can lead to very serious problems, like a user buying the wrong product, or a doctor prescribing the wrong drug to a patient.

A non-exhaustive list of reasons:

• The network is slow, bad, unpredictable, with variable request latencies...
• The backend is under heavy load, throttling some requests, under a Denial-of-Service attack...
• The user is clicking fast, commuting, travelling, on the country side...
• You are just unlucky

Developers don't see them in development, where the network conditions are generally good, sometimes running the backend API on your own computer, with close to 0ms latency.

In this post, I'll show you what those issues do, using realistic network simulations and runnable demos. I'll also explain how you can fix those issues, depending on the libraries you already use.

Disclaimer: to keep the focus on race conditions, the following code samples will not prevent the React warning if you setState after unmounting.

The incriminated code:

You probably already read tutorials with the following code:

Or with the class API:

All 2 versions above lead to this same result. When changing the id very fast, even with your own good home network and very fast API, something is wrong and sometimes, previous request's data is rendered. Please don't think debouncing protects you: it just reduces the chances of being unlucky.

Now let's see what happens when you are on a train with a few tunnels.

Simulating bad network conditions

Let's build some utils to simulate bad network conditions:

Adding network delays

You might be on a slow network, or the backend may take time to answer.

Adding network delays + failures

You are on a train in the countryside, and there are a few tunnels: requests are delayed randomly and some of them might fail.

This code very easily leads to weird, inconsistant UI states.

How to avoid this problem

Let's suppose 3 requests R1, R2 and R3 gets fired in this order, and are still pending. The solution is to only handle the response from R3, the last issued request.

There are a few ways to do so:

• Ignoring responses from former api calls
• Cancelling former api calls
• Cancelling and ignoring

Ignoring responses from former api calls

Here is one possible implementation.

Another option could be to have the effect's cleanup function to set a boolean to false, so that the promise result gets ignored.

Some might be tempted to use the id to do this filtering, but it's not a good idea: if the user clicks next and then previous, we might end up with 2 distinct requests for the same hero. Generally this is not a problem (as the 2 requests will often return the exact same data), but using promise identity is a more generic and portable solution.

Cancelling former api calls

It is better to cancel former api requests in-flight: the browser can avoid parsing the response and prevent some useless CPU/Network usage. fetch support cancellation thanks to AbortSignal:

An abort signal is like a little event emitter, you can trigger it (through the AbortController), and every request started with this signal will be notified and canceled.

Let's see how to use this feature to solve race conditions:

This code looks good at first, but actually we are still not safe.

Let's consider the following code:

If we abort the request during the fetch, the browser will be notified and do something about it. But if the abortion happens while the browser is running the then() callback, it has no way to handle the abortion of this part of the code, and you have to write this logic on your own. If the abortion happens during the fake delay we added, it won't cancel that delay and stop the flow.

Let's get back to our problem. Here's the final, safe version, aborting the request in-flight, but also using the abortion to eventually filter the results. Also let's use the hooks cleanup function, which makes the code a bit simpler.

And now only we are safe.

Using libraries

Doing all this manually is complex and error prone. Hopefully, some libraries solve this problem for you. Let's explore a non-exhaustive list of libraries generally used for loading data into React.

Redux

There are multiple ways to load data into a Redux store. Generally, if you are using Redux-saga or Redux-observable, you are fine. For Redux-thunk, Redux-promise and other middlewares, you might check the "vanilla React/Promise" solutions in next sections.

Redux-saga

You might notice there are multiple take methods on the Redux-saga API, but generally you'll find many examples using takeLatest. This is because takeLatest will protect you against those race conditions.

Forks a saga on each action dispatched to the Store that matches pattern. And automatically cancels any previous saga task started previously if it's still running.

The previous loadStarwarsHero generator executions will be "cancelled". Unfortunately the underlying API request will not really be cancelled (you need an AbortSignal for that), but Redux-saga will ensure that the success/error actions will only be dispatched to Redux for the last requested Starwars hero. For in-flight request cancellation, follow this issue.

You can also opt-out from this protection and use take or takeEvery.

Redux-observable

Similarly, Redux-observable (actually RxJS) has a solution: switchMap

The main difference between switchMap and other flattening operators is the cancelling effect. On each emission the previous inner observable (the result of the function you supplied) is cancelled and the new observable is subscribed. You can remember this by the phrase switch to a new observable.

You can also use other RxJS operators like mergeMap if you know what you are doing, but many tutorials will use switchMap, as it's a safer default. Like Redux-saga, it won't cancel the underlying request in-flight, but there are solutions to add this behavior.

Apollo

Apollo lets you pass down GraphQL query variables. Whenever the Starwars hero id changes, a new request is fired to load the appropriate data. You can use the HOC, the render props or the hooks, Apollo will always guarantee that if you request id: 2, your UI will never return you the data for another Starwars hero.

Vanilla React

There are many libraries to load data into React components, without needing a global state management solution.

I created react-async-hook: a very simple and tiny hooks library to load async data into React components. It has very good native Typescript support, and protects you against race conditions by using the techniques discussed above.

Other options protecting you:

• react-async: quite similar, also with render props api
• react-refetch: older project, based on HOCs
• swr and react-query: most recent options, that claim to integrate well with Suspense, and manage an external cache

There are many other library options, for which I won't be able to tell you if they are protecting you: take a look at the implementation.

Note: it's possible react-async-hook and react-async will merge in the next months.

Note: it's possible to use StarwarsHero key={id} id={id}/> as a simple React workaround, to ensure the component remounts everytime the id changes. This will protect you (and sometime a useful feature), but gives more work to React.

Vanilla promises and Javascript

If you are dealing with vanilla promises and Javascript, here are simple tools you can use to prevent those issues.

Those tools can also be useful to handle race conditions if you are using thunks or promises with Redux.

Note: some of these tools are actually low-level implementation details of react-async-hook

Cancellable promises

React has an old blog post isMounted() is an antipattern on which you'll learn how to make a promise cancellable to avoid the setState after unmount warning. The promise is not really cancellable (the underlying api call won't be cancelled), but you can choose to ignore or reject the response of a promise.

I made a library awesome-imperative-promise to make this process easier:

Note: all those methods have to be called before the underlying API request resolves or reject. If the promise is already resolved, there's no way to "unresolve" it.

Automatically ignoring last call

awesome-only-resolves-last-promise is a library to ensure we only handle the result of the last async call:

What about Suspense?

It should prevent those issues, but let's wait for the official release :) I hope to revisit this blog post soon (will be updated on my website)

Conclusion

For your next React data loading usecase, I hope you will consider handling race conditions properly.

I can also recommend to hardcode some little delays to your API requests in development environment. Potential race conditions and bad loading experiences will be more easy to notice. I think it's safer to make this delay mandatory, instead of expecting each developer to turn on the slow network option in devtools.

I hope you've found this post interesting and you learned something, it was my first technical blog post ever :)

---------------------------------------------------------------------------------------------------------------

• Originally posted on my website
• If you like it, spread the word with a retweet
• Browser demos code or correct my post typos on the blog repo
• For more content like this, subscribe to my mailing list and follow me on Twitter
• Thanks for my reviewers: Shawn Wang, Mateusz Burzyński, Andrei Calazans, Adrian Carolli, Clément Oriol, Thibaud Duthoit, Bernard Pratz