Learn redux-toolkit part 2

Tram Ho

In the first part to learn and use redux-toolkit ( link part 1 ), I introduced and shared how to use some of the basic redux-toolkit api to help us create a complete redux flow to replace the default function of redux , in this section I will introduce some more advanced api of redux-toolkit .

Create a complete module with createSlice

First to understand what the concept of “complete module” is , let’s review the store initialization example from the previous section.

In this simple example we have a rootReducer , in fact in the project the reducer is not very small like this, the principle of redux is only 1 single source of truth , which means the entire state of the app will be set. In a single reducer , redux allows us to split reducers into smaller reducers , usually sub-reducers are logically independent and follow the screens or features of the application, each sub-reducer will usually listen to the action. separately, there are respective middleware . Usually we will see the store directory in the app structured like this:

OK, assuming we all understand the concept of the module , there will be no problem with directory division as above, but there is no guarantee that the reducer and actions in the other module are related to each other, I usually Create a convention in the project such as naming the module by function, the type of the action must have a module prefix to distinguish and avoid duplicate actions , for example:

As introduced in the previous section, redux-toolkit will create a standardization for us to write redux code in a more consistent and concise manner, we will solve this module problem with createSlice function, first of all let’s take a look. Demo offline.

createSlice helps us to solve the problem when creating the redux module we mentioned above, the reducer and action are grouped in an object , and we just need to export them for use in the application, and the action types are also generated. prefixed with the default field name when creating the slice .

At this point, you will surely find it quite convenient, right, createSlice has actually created a complete, consistent and concise syntax for application state management with redux . There is another point to note, in the above example, the actions will automatically generate corresponding properties in the reducers field, so what if the reducer of the slice wants to listen to other actions , say listen to a certain joint action of the application?
In this case, we need to use another option when creating the slice , named extraReducers , and there are two different spelling styles.

extraReducers builder callback

Here is the first way, recommended by the document redux-toolkit , let’s see the demo :

Each action needs to listen, the builder will call an addCase function with the parameter passed action type ( action created by createAction function of redux or exported from createSlice just pass * that action , and action created by normal function or other library should transmit correct value type of action), for the case of default, just call addDefaultCase, here still allow direct state mutate slightly.

Note that the createReducer function also allows the use of this builder function, the syntax is similar to the following.

extraReducers with map object

This second way uses an object with key action type and value as state handler function.

This second way has a cleaner and easier to read syntax, but the redux-toolkit side recommends the first in case our application is written in typescript , you can see more here .

reducer listens to many actions with the same logic

In the examples I introduced through two parts, we handle the case reducer processes each action in turn, each action type is listened to and processed by a function , in fact sometimes there are some cases where they are We want to process action types in the same function to minimize code iteration, for example:

This problem actually does not meet much, because if many actions have the same handling, we should dispatch the same action . However, if you are forced to do the above, in the reducer we will use the builder callback with the addMatcher function, as follows:

Other slightly with builder.addCase and builder.addDefaultCase, the first parameter of the function is a function addMatcher parameter is the action to dispatch and returns a boolean value, all of the action to dispatch will be tested and said reducer needs to listen for any action . You can see more details about the addMatcher here .

In the second part of this redux-toolkit article, I focused on creatingSlice , a function that allows us to write redux in all-in-one style , I find this function too cool and convenient, if you feel can still use createReducer or createAction but I suggest that if the application Redux-toolkit, use always createSlice because it genuine really there, I temporarily associated part two here, part 3 here I will introduce notes about how to handle asynchronous actions .

Share the news now

Source : Viblo