React Lesson 13. Part 1: Asynchronous actions

React Lesson 13. Part 1: Asynchronous actions

React Lesson 13. Part 1: Asynchronous actions

Hey everyone, we are going to learn asynchronous actions in this lesson. Up until now, we were using fixtures.js to get the articles and comments and our actions were pure functions, which worked fine. But now we will get our data from an API endpoint just like what happens in the real world.
Previous lessons you can find by the link.

API calls are asynchronous, it means that there will be a small delay followed by success or failure of an API request. We are going to learn how to handle all these cases. Let’s start.


If you go to the repo, you will see a simple API already setup. Go into simple_api directory and run:


This will install all the required packages and you will see a node_modules folder created for you.
Now, we have run the server and development server simultaneously as one will serve the requests yarn run API and the other one launches dev server for our app yarn start.
API and dev server both are running on different ports. We have to set up redirection to avoid any сrossdomain requests. Everything that goes to /API will be proxied to your API. It is now localhost:3001, but later it can be some remote address. You set up redirection and will have access to the article from both addresses:



Let’s start working on the implementation of API, we don’t want to keep using fixtures.js with static data.
At the moment, the api/article is returning all the articles. We need to limit the number of articles returned in one request as the number can be huge and we might not need everything at first. Moreover, we will make additional requests to get comments separately.

The Concept: How it works?

First, let us get a list of articles from API and get them displayed at our traditional address:


We will use fetch to call request API for articles. Any asynchronous API call can include three important phases that we need to address. We will see what are those and how to handle them using plain old synchronous action creators:

  • Start of request

    The first phase is when we start fetching data. We need to tell UI that data fetching has been started. We can do this by dispatching an action with a flag isFetching: true and then showing a loader/spinner based on this state.

  • Request finished successfully

    The second phase occurs when the request is completed successfully and we have the desired data in API response. We can then dispatch an action with data as payload and reset the flag isFetching to false. This will hide the spinner and render the data.

  • Request failed

    The third phase occurs when the request is failed and we don’t have the data to render. In this case, we have to inform the user that something bad has happened and we have met an error. We can dispatch an action with an error message and reset the flag isFetching to false. This will hide the spinner and show the error message.

Note: Only one phase from phase 2 or 3 happens in any API call. Requests will either be successful or failed.

Let’s code

We have already seen that we will need three types of action creator to handle all 3 cases. These can be defined in types.js as:

We will use fetch API in the examples. We have to install to redux-thunk to be able to dispatch asynchronous actions.

Actions must return a pure object, which means we can’t wait for an API to return response and we dispatch an action afterward. That’s where redux-thunk comes into play. Redux Thunk is a middleware that allows us to return a function instead of an object. The inner function receives the store methods dispatch as parameters that we can use to delay the dispatch of action or dispatch only if a certain condition is met. Let’s add this middleware to store:

Now we have to create the three action creators for each phase we talked earlier:

We can dispatch as many times as we want. As you can see from the code above, we are sending flags in the form of types. We will update the isFetching state as true or false based on the type we receive at reducer which will inform the view about the three phases on API call discussed earlier.

Finally, we have to handle these actions on the reducer side and then dispatch actions from the view. We will continue with that in the next lesson.

Lesson code can be found in the GitHub repo.

About the author

Stay Informed

It's important to keep up
with industry - subscribe!

Stay Informed

Looks good!
Please enter the correct name.
Please enter the correct email.
Looks good!

Related articles

React Lesson 15: Checking Homework progress from Lesson 14

Today, we are going to cover homework from Lesson 14 and add comment API to load comments. ...

React Lesson 14: Redux Thunk Deep Dive

In this lesson, we will understand the internals of Redux Thunk and the use cases where we should use ...

React Lesson 13 Part 2: Asynchronous actions

In the previous article, we used Redux Thunk and learned how to structure actions for asynchronous calls. Now we will update reducer to handle them ...

No comments yet

Sign in

Forgot password?

Or use a social network account


By Signing In \ Signing Up, you agree to our privacy policy

Password recovery

You can also try to

Or use a social network account


By Signing In \ Signing Up, you agree to our privacy policy