How To Reset Redux State with a Root Reducer
source link: https://www.digitalocean.com/community/tutorials/redux-reset-state-redux
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Introduction
Have you ever had to reset your Redux state to its initial state in your reducers? Resetting the state is something lots of apps need to do. A typical example of when the app state must be reset could be when the user logs out.
In this article, you will learn about centralizing the resetting of the state, per-reducer reset logic, and excluding reducers from being reset.
Prerequisites
To follow along with this tutorial, you will need:
- Some familiarity with React and Redux. You can refer to this post if you’re getting started with Redux.
This tutorial was verified with redux
v4.1.0.
Understanding the Limitations of RESET_APP
The most naive approach is to add a RESET_APP
condition to all reducers.
Consider a users
reducer with the following shape:
const usersDefaultState = [];
const users = (state = usersDefaultState, { type, payload }) => {
switch (type) {
case 'ADD_USER':
return [...state, payload];
default:
return state;
}
};
Then you would add a RESET_APP
case to the switch in order to return the usersDefaultState
:
const usersDefaultState = [];
const users = (state = usersDefaultState, { type, payload }) => {
switch (type) {
case 'RESET_APP':
return usersDefaultState;
case 'ADD_USER':
return [...state, payload];
default:
return state;
}
};
This is acceptable for a reducer or two, but in any real-world app, that would lead to repeating the same code for each reducer, and you’ll most likely have many of them:
const usersDefaultState = [];
const users = (state = usersDefaultState, { type, payload }) => {
switch (type) {
case 'RESET_APP':
return usersDefaultState;
case 'ADD_USER':
return [...state, payload];
default:
return state;
}
};
const articlesDefaultState = [];
const articles = (state = articlesDefaultState, { type, payload }) => {
switch (type) {
case 'RESET_APP':
return articlesDefaultState;
case 'ADD_ARTICLE':
return [...state, payload];
default:
return state;
}
};
Remember DRY (Don’t Repeat Yourself)? Well, this code doesn’t really comply with that principle and that’s something we as developers should try to avoid.
Centralizing the Resetting of the State
The trick to reuse the logic for resetting the app in a single place is to create a root reducer over your app root reducer. That is a reducer on top of your reducers where you check for that condition and apply it if necessary.
Usually, you would use the combineReducers
function to create a single root reducer for your redux store:
import { combineReducers } from 'redux';
const usersDefaultState = [];
const users = (state = usersDefaultState, { type, payload }) => //...
const articlesDefaultState = [];
const articles = (state = articlesDefaultState, { type, payload }) => //...
const allReducers = combineReducers({
users,
articles
});
In this case, allReducers
is your app’s root reducer that you’ll pass to Redux’s createStore
function.
In order to create a wrapping root reducer over that one, we just need to define a function that calls that root reducer:
const rootReducer = (state, action) => {
return allReducers(state, action);
}
Right now, rootReducer
is acting as a function that stands between the allReducers
call. Right before that call is where we can add a common functionality that will apply before the reducers call. And in order to reset the app, we could just pass a state set to undefined
:
const rootReducer = (state, action) => {
if (action.type === 'RESET_APP') {
state = undefined;
}
return allReducers(state, action);
}
Wait, what? Why would that reset the app? Well, if we analyze the reducer definition:
const users = (state = usersDefaultState, { type, payload }) => //...
You’ll see that the default value for the state
parameter is usersDefaultState
in this case, and the default parameter of a function applies when and only when the received parameter value is undefined
(not even null
, only undefined
). That’s why the state that all the reducers will receive is the default state.
Wait, aren’t we mutating the state? Nope, we’re changing the state reference to undefined
, not mutating it. Remember that mutating the state goes against Redux principles.
Using Per-Reducer Reset Logic
Applying the centralized reset logic using a rootReducer
doesn’t prevent you from having custom functionality for the RESET_APP
action in other reducers.
For example, let’s say that the articles
reducer must return a state other than the default’s one when the RESET_APP
is triggered:
const articles = (state = articlesDefaultState, { type, payload }) => {
switch (type) {
case "RESET_APP":
return "App is reset";
case "ADD_ARTICLE":
return [...state, payload];
default:
return state;
}
};
The point is, by default you’ll make all reducers return their default state, and you only will have custom reset behavior when you need it.
Excluding Reducers From Being Reset
It could happen that we would want to avoid having some specific reducers be reset. We could prevent that by keeping the slice of the state we want to exclude.
For example, if you’d like to exclude the articles
reducer from resetting:
const rootReducer = (state, action) => {
if (action.type === 'RESET_APP') {
const { articles } = state;
state = { articles };
}
return allReducers(state, action);
};
What’s happening here? Well, the combineReducers
function combines the reducers and passes the corresponding piece of state, so that each reducer has only its part of the state in its scope.
In this case, picking the articles
piece of the state with state = { articles }
, the function allReducers
will pass state.articles
to the articles
reducer and state.users
to users
reducer. Since state.users
is undefined
and state.articles
is not, only the users reducer will be reset.
Conclusion
In this article, you learned about centralizing the resetting of the state, per-reducer reset logic, and excluding reducers from being reset.
There are usually multiple ways to work around code duplication, but indeed following the DRY principle makes your code more understandable and maintainable.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK