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 on when the app state must be reset could be when the user logs out.

The most naive approach, which I’ve seen used many times, 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;
  }
};

That’s ok 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 in top of your reducers where you check for that condition and apply it if necessary. Let me explain: usually you’ll 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 appReducer(state, action);
}

Right now, rootReducer is acting as a function that stands between the appReducer 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 appReducer(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 you mutating the state?: Nope, I’m changing the state reference to undefined, not mutating it. Remember that mutating the state goes against Redux principles.

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.

Wrapping up

I hope this particular example of resetting an app’s state helped you learn about one way to reuse logic with Redux. There are usually multiple ways to work around code duplication, but indeed following the DRY principle makes your code more understandable and maintainable.

Stay cool 🦄