In this lesson, we will explore some common patterns for managing asynchronous operations and the state changes they cause. 

Managing Promise Lifecycle Actions

At this point, you can write a Redux app that uses `redux-thunk`—a middleware included in Redux toolkit—to permit asynchronous operations, such as fetching data from an API.  In this lesson, we will explore some common patterns for managing asynchronous operations and the state changes they cause. We will learn about two Redux toolkit utilities—`createAsyncThunk` and the `extraReducers` option you can pass to the `createSlice` function—that simplify the process of performing asynchronous operations and reflecting their results in state.

> This lesson uses [Mock Service Worker](https://mswjs.io/) to replicate the functionality of an external API. To use MSW, you'll want to use Google Chrome and [enable third-party cookies](https://support.google.com/chrome/answer/95647?co=GENIE.Platform%3DDesktop&hl=en).

Introduction

In a previous lesson, you learned about `createSlice`. In this lesson, you will learn about `extraReducers`, a property you can optionally pass to `createSlice` that allows `createSlice` to respond to action types it did not generate. 

To refresh your memory, `createSlice` accepts a single argument, `options`, which is an object containing configuration parameters including a name, some initial state, and reducers. `createSlice` then uses these configuration parameters to generate a slice of the store, including action creators and action types for updating the state contained in that slice. Consider the following example:

```js
const usersSlice = createSlice({
  name: 'users',
  initialState: { users:  [] },
  reducers: {
    addUser: (state, action) => { 
      state.users.push(action.payload) 
    }        
  },
})
```

This call to `createSlice`, generates a slice of the store that responds to the action creator `usersSlice.actions.addUser`. But what if we've generated our action creators via calls to `createAsyncThunk`? Consider `fetchUserById`, the asynchronous action creator from earlier in this lesson:

```js
const fetchUserById = createAsyncThunk(
  'users/fetchUserById', // action type
  async (userId, thunkAPI) => { // payload creator
    const response = await fetchUser(userId)
    return response.data
  }
)
```

This asynchronous action creator will generate three action types: `'users/fetchUserById/pending'`, `'users/fetchUserById/fulfilled'`, and `'users/fetchUserById/rejected'`.  Currently, these action types have no effect on our users slice, which only responds to the `users/addUser` action type generated by `createSlice`. 

How can we account for these promise lifecycle action types in our user slice? This is exactly the problem that `extraReducers`, an optional property on the configuration object passed to `createSlice`,  was designed to solve. `extraReducers` allows `createSlice` to respond to action types generated elsewhere.  To make the users slice respond to promise lifecycle action types, we pass them to `createSlice` in the `extraReducers` property. 

Open `usersSlice.js` in your code editor to see an example of the `extraReducers` property in context.

Note that in addition to using the `extraReducers` property, we also added some extra fields to our state object: a boolean, `isLoading`, which will be true when a request is pending, and otherwise false, and a boolean `hasError`, which we will set to `true` if our request to fetch a user is rejected. These additions allow us to track promise lifecycle states so that we can create satisfying and informative user interfaces when the promise is either `pending` or `rejected`. When the promise is `fulfilled` these are set to `false` and the user data is added to the state.


Using createSlice() with Async Action Creators

In the last exercise, we promised to elaborate on the two arguments that the payload creator (the asynchronous  function we pass to `createAsyncThunk`) receives: `arg` and `thunkAPI`. The first argument, `arg`, will be equal to the first argument passed to the thunk action creator itself. For example, if we call `fetchUserById(7)`, then inside the payload creator, `arg` will be equal to 7. 

But what if you need to pass multiple arguments to your thunk? Since the payload creator only receives the first argument passed to the thunk action creator, you'll want to bundle multiple arguments into a single object. For example, say we want to search our app's users by first and last name. If the thunk action creator is called `searchUsers`, we would call it like this: `searchUsers({firstName: 'Ada', lastName: 'Lovelace'})`.

If you need to access these variables individually, you can use ES6 destructuring assignment to unpack the object when you declare the payload creator and pass it to `createAsyncThunk`, like this :

```js
const searchUsers = createAsyncThunk(
	'users/searchUsers',
	async ({ firstName, lastName}, thunkAPI) => {
		// perform the asynchronous search request here	
	}
)
```

If your thunk requires no arguments, you can just call your thunk action creator without, and the `arg` argument will be undefined.
In the event the thunk requires only one param (for example, fetching a specific resource by `id`) you should name that first param semantically. Here's the `fetchUserById` example from the last exercise, with the `arg` parameter semantically renamed to `userId`. 

```js
import { createAsyncThunk } from '@reduxjs/toolkit'
import { fetchUser } from './api'
const fetchUserById = createAsyncThunk(
    'users/fetchUserById', // action type
    async (userId, thunkAPI) => { // payload creator
        const response = await fetchUser(userId)
        return response.data
    }
)
```

The payload creator's second argument, `thunkAPI`, is an object containing several useful methods, including the store's `dispatch` and `getState`. [For an exhaustive list of methods available in the `thunkAPI` object, you can read the documentation](https://redux-toolkit.js.org/api/createAsyncThunk#payloadcreator). 


Passing Arguments to Thunks

`createAsyncThunk` is a function with two parameters—an action type string and an asynchronous callback—that generates a thunk action creator that will run the provided callback and automatically dispatch promise lifecycle actions as appropriate so that you don't have to dispatch pending/fulfilled/rejected actions by hand. 

To use `createAsyncThunk`, you'll first need to import it from Redux Toolkit like so:

```js
import { createAsyncThunk } from '@reduxjs/toolkit';
```

Next, you'll need to call `createAsyncThunk`, passing two arguments. The first is a string representing the asynchronous action's type. Conventionally, type strings take the form `"resourceType/actionName"`. In this case, since we are getting an individual user by their `id`, our action type will be `users/fetchUserById`. The second argument to `createAsyncThunk` is the payload creator: an asynchronous function that returns a promise resolving to the result of an asynchronous operation. Here is `fetchUserById` rewritten using `createAsyncThunk`:

```js
import { createAsyncThunk } from '@reduxjs/toolkit'
import { fetchUser } from './api'
const fetchUserById = createAsyncThunk(
  'users/fetchUserById', // action type
  async (arg, thunkAPI) => { // payload creator
    const response = await fetchUser(arg);
    return response.json();
  }
)
```

There are a few things worth highlighting here. First, observe that the payload creator receives two arguments—`arg` and `thunkAPI`. We will elaborate on those in the next exercise. Second, note that the payload creator we provided doesn't dispatch any actions at all. It just returns the result of an asynchronous operation.

As you can see, `createAsyncThunk` makes defining thunk action creators more concise. All you have to write is an asynchronous thunk function; `createAsyncThunk` takes care of the rest, returning an action creator that will dispatch pending/fulfilled/rejected actions as appropriate. 


createAsyncThunk()

In a perfect world, every network request we make would yield an immediate and successful response. But network requests can be slow, and sometimes fail. As developers, we need to account for these realities in order to create the best possible experience for our users. If we know a request is pending, we can make our application more user-friendly by displaying a loading state. Similarly, if we know a request has failed, we can display an appropriate error state. 

In order to create these satisfying user experiences, we need to keep track of the state our async requests are in at any given moment so that we can reflect those states for the user. It is common to dispatch a "pending" action right before performing an asynchronous operation, and "fulfilled" or "rejected" actions depending on the results of the completed operation. Take this simple thunk action creator, `fetchUserById`. 

```js
import { fetchUser } from './api';

const fetchUserById = (id) => {
  return async (dispatch, getState) => {
    const payload = await fetchUser(id);
    dispatch({type: 'users/addUser', payload: payload});
  }
}
```
Rewritten to include pending and rejected actions, it might look like this:

```js
import { fetchUser } from './api'
const fetchUserById = (id) => {
  return async (dispatch, getState) => {
    dispatch({type: 'users/requestPending'})
    try {
      const payload = await fetchUser(id)
      dispatch({type: 'users/addUser', payload: payload})
    } catch(err) {
      dispatch({type: 'users/error', payload: err})
    }
  }
}
```

We call these pending/fulfilled/rejected actions _promise lifecycle actions_. This pattern is so common that Redux Toolkit provides a neat abstraction, `createAsyncThunk`, for including promise lifecycle actions in your Redux apps. We'll explore that method in the following exercises.


A promise begins in the pending state. If success, it moves to the fulfilled state and returns data. If failure, it moves to the rejected state and returns an error.

Promise Lifecycle Actions

Well done! In this lesson you:
* Learned the three _promise lifecycle actions_: pending, fulfilled, and rejected
* Learned how to use `createAsyncThunk`, which abstracts the process of handling promise lifecycle states according to best practices/common design paradigms
* Imported `createAsyncThunk` from the Redux Toolkit:


```js
import { createAsyncThunk } from '@reduxjs/toolkit';
```

* Refactored existing asynchronous action creators using `createAsyncThunk`.
* Made your reducers respond to pending/fulfilled/rejected promise lifecycle actions by supplying the extraReducers property to `createSlice`.


Conclusion

As you know, `createAsyncThunk` takes care of dispatching actions for each of the promise lifecycle states: pending, fulfilled, and rejected. But what exactly do these actions look like? 

Building off the action type string you pass to it, `createAsyncThunk` produces an action type for each promise lifecycle states. If you pass the action type string `'resourceType/actionType'` to `createAsyncThunk`, it will produce these three action types: 
* `'resourceType/actionType/pending'`
* `'resourceType/actionType/fulfilled'`
* `'resourceType/actionType/rejected'`

To use our earlier example:

```js
import { createAsyncThunk } from '@reduxjs/toolkit'
import { fetchUser } from './api'

const fetchUserById = createAsyncThunk(
  'users/fetchUserById', // action type
  async (userId, thunkAPI) => { // payload creator
    const response = await fetchUser(userId)
    return response.data
  }
)
```

When you pass `createAsyncThunk` the action type string `'users/fetchUserById'`, `createAsyncThunk` produces these three action types: 
* `'users/fetchUserById/pending'`
* `'users/fetchUserById/fulfilled'`
* `'users/fetchUserById/rejected'` 

If you need to access the individual pending/fulfilled/rejected action creators, you can reference them like this: 
* `fetchUserById.pending`
* `fetchUserById.fulfilled`
* `fetchUserById.rejected`

You will have to handle these action types in your reducers if you want to reflect these promise lifecycle states in your app. In the next exercise, we will show you how to do that. 
