Handling Async Errors With Axios in React

Ever clicked a button and couldn’t figure out if it worked? This guide has four quick snippets to make your React app feel less janky

Photo by Clever Sparkle on Unsplash.

Have you ever been stuck on what looks like an empty page and asked yourself, “Am I supposed to be seeing something yet?” only for it to appear 30 seconds later? Or maybe you clicked on a button and you’re not sure whether it’s processing or not (e.g. on checkout pages). If that’s what your own app feels like, then read on.

In this guide, I’ll walk you through four scenarios you should handle when working with APIs using Axios and React:

• Handling requests that sometimes take longer than usual and leave the user looking at an empty page.
• Handling requests that have error-ed and you want to give the user a way out.
• Handling a possible timeout where the request is taking significantly longer than usual and giving the user an updated loading message so they see the page isn’t frozen.
• Handling a definite timeout where you want to abort the request to give the user a more specific error message.

I’ll start with a very innocent example: When the ResultsList component loads, it requests some data and displays it in the UI.

The data from the API is being stored in the results field of the component's state. It starts as an empty array and gets replaced with the actual results when the data is fetched.

This is buggy. Here’s why as well as how you can improve your code.

1. Handling Long Response Times

Not all users will have a great connection — even if your backend is stable — and that request may take a little longer to complete than usual. In this example, there’s no feedback to the user that something is happening, and when there are issues, the page will be empty for a lot longer than you’re expecting.

It will make your users ask, “Am I supposed to be seeing something yet?”

You can fix that by showing the user something useful like a spinner:

There are two changes here:

• Rather than initializing results to an empty array [], it’s initialized to null.
• I can then check if I should show a loading message or show the list with data.

Pro tip: Add spinners. They’re so easy. Your users will be less confused. I say this as someone who has had to field a lot of support issues from lack of progress feedback.

2. Handling Errors

When something goes wrong, show the user an error message and a way for them to fix it. If you’re looking for more details about the Axios error object (especially if you’re using it in the browser), I offer more details in this article.

Here, I’ve added an error field to the component's state where I can keep track of errors and conditionally show an error message to the user. I give them a painfully generic error message, but I offer a way out via a button to “Try again,” which will retry the request.

When the request succeeds, the error is cleared from the state and the user sees the right info. Wonderful.

3. Handling a Possible Timeout

You get bonus points if you add this. Every once in a while, a user will come across a loading spinner, and they’ll wonder, “Is it frozen and the icon is just spinning, or is this really taking this long?”

If a request is taking a while, you can give the user a little feedback in the form of “This is taking longer than usual…”

The refs are needed due to an issue with React and the way it handles setTimeout (see the Facebook/React issue). The function in setTimeout doesn’t get the latest state value when it executes if you’re using Hooks. setTimeout uses a closure, which means that it copies the initial value of the variable. The workaround is to use useRef.

You can set a timer for whichever TIMEOUT_INTERVAL you want. When the timer executes, check whether the data has already loaded and show the extra error message. If there are no results yet and no errors, we're still waiting for data, so you can show the updated loading message.

4. Handling a Definite Timeout

If you know a request is supposed to be quick and you want to give the user quick feedback, you can set a hard timeout in the config passed to axios.get.

Axios will throw an error here when the request times out and it’ll have an error message like timeout of 30000ms exceeded.

Review Your Error Handling

If you want to see this behavior in action, I hacked together an API to provide examples of a buggy API and put a working React example on CodePen. You can also see a commented version of the code in this gist.

Take a look at your React projects that are working with APIs and review how you’re handling errors. These tips are an easy way to give your users a less buggy experience. If you’ve tried it out or have different ways of approaching your errors, let me know in the comments!

Originally published at https://www.intricatecloud.io.