Redux with Code-Splitting and Type Checking

Before We Get Started

This article assumes a working knowledge of Redux, React, React-Redux, TypeScript, and uses a little bit of Lodash for convenience. If you’re not familiar with those subjects, you might need to do some Googling. You can find the final version of all the code here.

Introduction

Redux has become the go-to state management system for React applications. While plenty of material exists about Redux best practices in Single Page Applications (SPAs), there isn’t a lot of material on putting together a store for a large, monolithic application.

What happens when you only need a few reducers on each page, but it could be any permutation of the total number of reducers you support? How do you code-split your store so you’re not serving unnecessary JavaScript on a single page? And while you’re working on code splitting, how do you get it to play nicely with TypeScript so that you can trust what’s going in and coming out of the store?

The Architecture

Before we dive into code, let’s outline the architecture we’re about to build.

We need to create the store in such a way that we can register reducers asynchronously. This allows us to async load code associated with those reducers.

We need to type the store in such a way that it knows about all possible reducers we can register. This allows us to ensure static typing of all components at runtime.

Creating the Store

In order to code split, we need to instantiate the store in a way that allows us to register reducers after store creation. We start with the following code:


// redux-utils/store.ts

import { combineReducers, createStore, Store } from "redux";
import { ReducerMap, StoreShape } from "./types";

let reducerMap: ReducerMap = {};
const store = createStore(combineReducers(reducerMap));

export function getStore() {
  return store;
}

export function registerReducer(newReducers: ReducerMap): Store {
  reducerMap = { ...reducerMap, ...newReducers };
  // We probably want to validate we're not replacing reducers that already
  // exist here but that exercise is left up to the reader.
  store.replaceReducer(combineReducers(reducerMap));
  return store;
}

What’s going on here? We’re instantiating the store with the file and we’ve also exported two functions. One called getStore, which is simply a wrapper around the store and doesn’t need much further explanation, and registerReducer.

registerReducer is the more interesting function. We maintain a map of existing reducers internal to the module and then replace add new ones as they come in. We then call replaceReducer on the store and replace it wholesale. replaceReducer is smart enough to maintain the state of the reducers that were previously there and fires an INIT action for the new ones to populate their default state.

This is what makes code-splitting possible. We don’t care when the reducer is registered and all of that code can be loaded after the store is created.

Type Safety

Now let’s dig into what makes this type safe. Well, let’s dig into our types.ts file.

// redux-utils/types.ts

import { NonwizardNamespaceShape } from "../data/nonwizard/types";
import { WizardNamespaceShape } from "../data/wizards/types";
import { Reducer } from "redux";
export const NONWIZARD_NAMESPACE_KEY = "NONWIZARD_NAMESPACE";
export const WIZARD_NAMESPACE_KEY = "WIZARD_NAMESPACE";

export type FullStoreShape = {
  [NONWIZARD_NAMESPACE_KEY]: NonwizardNamespaceShape;
  [WIZARD_NAMESPACE_KEY]: WizardNamespaceShape;
};
export type StoreShape = Partial<FullStoreShape>;
export type NamespaceKey = keyof StoreShape;
export type ReducerMap = Partial<
  {[k in NamespaceKey]: Reducer<FullStoreShape[k]>}
>;

You’ll notice we import NonwizardNamespaceShape and WizardNamespaceShapefrom elsewhere in the codebase. This is okay. Because these are type-only imports, most build systems won’t actually bundle them in when building packages. This is where the statically typed code splitting magic happens.

We then export types StoreShape and ReducerMap, which allow us to register all possible types on the actual state object in advance. Because we colocate the namespace keys in the types file, our developers can ensure that there are no key conflicts.

You’ll notice these types are both Partial, so how do we enforce that a reducer is actually registered? Well, we do that in the selector layer.

Selectors

Our selector layer is what ensures that we always have the reducers registered that we need. We can do this with a simple helper function.

	
// redux-utils/selectors.ts

import { FullStoreShape, NamespaceKey, StoreShape } from "./types";
export function getStateAtNamespaceKey(
  state: StoreShape,
  namespace: T
): FullStoreShape[T] {
  const namespaceState = state[namespace];
  if (!namespaceState) {
    throw new Error(
      `Attempted to access state for an unregistered namespace at key ${namespace}`
    );
  }
  // We need to explicitly say this is not undefined because TypeScript doesn't 
  // recognize the thrown error will prevent us from ever getting here.
  return namespaceState!;
}

In short, getStateAtNamespaceKey complains very loudly if you attempt to access a namespace that hasn’t been registered yet. This is the only way we should access our data. As long as you call registerReducer in the same part of your tree as your <Provider /> component, your namespace should be registered by the time you get down to a connect. We’ll elaborate on this in a moment.

Writing Actual Product Code

This is is all well and good, but let’s talk about what our product code looks like.

//wizards.tsx

import * as React from "react";
import { connect, Provider } from "react-redux";
import { getStoreForWizardApp } from "./data/wizards/store";
import { Wizard } from "./data/wizards/types";
import { getWizards } from "./data/wizards/selectors";
export function WizardApp() {
  return (
    <Provider store={getStoreForWizardApp()}>
      <ConnectedWizards />
    </Provider>
  );
}
function Wizard({ name, spells, hasWand }: Wizard) {
  return (
    <>
      <span>Name: {name}</span>
      <span>Parents: {parentsAlive ? "Alive" : "Dead"}</span>
      <span>Learned Spells: {spells.map(spell => `${spell} `)}</span>
    </>
  );
}
type WizardsProps = { wizards: Wizard[] };
function Wizards({ wizards }: WizardsProps) {
  return (
    <>
      {wizards.map(wizardProps => (
        <Wizard {...wizardProps} />
      ))}
    </>
  );
}
const mapStateToProps = state => ({
  wizards: getWizards(state)
});
const ConnectedWizards = connect(mapStateToProps)(
  Wizards
);

The code above is (hopefully) straightforward. We connect to the Redux store using react-redux and use the <Provider /> and connect component/HOC respectively. We take a list of wizards and render them out to the screen, along with information about what spells they know and the status of their parents. Spoiler: We’re getting to a certain boy wizard with a lightning scar.

The two novel bits of code here are getStoreForWizardApp and getWizards. Let’s dig into them both.

getStoreForWizardApp

	
// data/wizards/store.ts

import { getStore, registerReducer } from "../../redux-utils/store";
import { WIZARD_NAMESPACE_KEY } from "../../redux-utils/types";
import { once } from "lodash";
import wizardReducer from "./reducer";
export const getStoreForWizardApp = once(() =&gt; {
  registerReducer({ [WIZARD_NAMESPACE_KEY]: wizardReducer });
  return getStore();
});

In the above code, you saw what we call the registerReducerand getStorefunctions that we declared before. We pass registerReducera map with the key for the Wizard namespace and the Wizard reducer. Another important note: if we try to pass the wrong key or even the wrong reducer to registerReducer, type checking will complain about it.

One last but crucial bit. We wrap getStoreForWizardApp in lodash.once. This ensures that we only register the reducer once and then always return the same instance of the store. While this isn’t strictlyrequired, replaceReduceris an expensive noop, if called repeatedly.

getWizards

	
// data/wizards/selectors.ts

import { getStateAtNamespaceKey } from "../../redux-utils/selectors";
import { StoreShape, WIZARD_NAMESPACE_KEY } from "../../redux-utils/types";
import { mapValues } from "lodash";
import { Wizard } from "./types";

const getWizards = (state: StoreShape) =&gt; (
  getStateAtNamespaceKey(state, WIZARD_NAMESPACE_KEY)
);

This one is much more straightforward. We call getStateAtNamespaceKeyand spit out the wizards to the user.

Actions

Sweet! We’ve set up the store, registered our reducer, and even built some components. Now let’s talk about how we can strongly type our actions. We do this in both the action layer and the reducer layer.

	
// data/wizards/actions.ts

import { AnyAction } from "redux";
export type Wizard = {
  name: string;
  hasWand: boolean;
  spells: string[];
};
export const enum WizardActionTypes {
  LearnSpell = "WIZARD/LEARN_SPELL",
  BreakWand = "WIZARD/BREAK_WAND"
}
export type WizardNamespaceShape = {
  [id: string]: Wizard;
};
export interface LearnSpellAction extends AnyAction {
  type: WizardActionTypes.LearnSpell;
  payload: { id: string; spell: string };
}
export interface BreakWandAction extends AnyAction {
  type: WizardActionTypes.BreakWand;
  payload: { id: string };
}
export type WizardAction = LearnSpellAction | BreakWandAction;

You’ll notice that we have two action types: LearnSpellActionand BreakWandAction. These actions each have a strongly-typed payload and their type is a predetermined string enum. We also export WizardAction, which is useful in our reducer.

	
// data/wizards/reducer.ts

import { WizardAction, WizardActionTypes, WizardNamespaceShape } from "./types";
const defaultState: WizardNamespaceShape = {
  powerfulWizard: {
    name: "Powerful Wizard",
    hasWand: false,
    spells: []
  }
};
export default function reducer(
  state: WizardNamespaceShape,
  action: WizardAction
) {
  switch (action.type) {
    case WizardActionTypes.breakWand: {
      const { id } = action.payload;
      return {
        ...state,
        [id]: {
          ...state[id],
          hasWand: false
        }
      };
    }
    case WizardActionTypes.LearnSpell: {
      const { id, spell } = action.payload;
      return {
        ...state,
        [id]: {
          ...state[id],
          spells: [...state[id].spells, spell]
        }
      };
    }
    default: {
      return state;
    }
  }
}

This is one of those occasions where TypeScript is truly brilliant. Our given action type is any of the WizardActionTypes. Because each of them has their own defined typeproperty, our switch statement will actually strongly type action.payloadafter we determine its type. If we were to put any invalid code here, TypeScript would complain.

Store Hydration

The last question to answer here is: “How do we get initial data into the store?” That’s done through a process called store hydration. What this means is that we’re going to dispatch an action that sets the state. Let’s take a look at this code. First, we update our actions.tsfile as shown.

	
export const enum WizardActionTypes {
  Hydrate = "WIZARD/HYDRATE",
  LearnSpell = "WIZARD/LEARN_SPELL",
  BreakWand = "WIZARD/BREAK_WAND"
}

export interface HydrateWizardsAction extends AnyAction {
  type: WizardActionTypes.Hydrate;
  payload: WizardNamespaceShape;
}
export type WizardAction =
  | HydrateWizardsAction
  | LearnSpellAction
  | BreakWandAction;

Second, we add another switch statement to our reducer.

	
switch (action.type) {
  case WizardActionTypes.Hydrate: {
    return {
      ...action.payload
    };
  }
  case WizardActionTypes.BreakWand: {

Third, we need to make an action creator.

	
// data/wizards/actions.ts

import { WizardActionTypes, WizardNamespaceShape } from "./types";

export function hydrateWizardNamespace(initialData: WizardNamespaceShape) {
  return {
    type: WizardActionTypes.Hydrate,
    payload: initialData
  };
}
// LearnSpell and BreakWand are exercises left up to the reader

Finally, we dispatch the hydration action from our store creation function.

	
import { getStore, registerReducer } from "../../redux-utils/store";
import { WIZARD_NAMESPACE_KEY } from "../../redux-utils/types";
import { once } from "lodash";
import wizardReducer from "./reducer";
import { WizardNamespaceShape } from "./types";
import { hydrateWizardNamespace } from "./actions";
export const getStoreForWizardApp = once(
  (initialData?: WizardNamespaceShape) =&gt; {
    registerReducer({ [WIZARD_NAMESPACE_KEY]: wizardReducer });
    const store = getStore();
    if (initialData) {
      store.dispatch(hydrateWizardNamespace(initialData));
    }
    return store;
  }
);

The lodash.once is now extra useful because we will only ever populate the store once.

Conclusions

I hope this article helped you get started with Redux. At compile time, our store is strongly typed and has knowledge of the entire system. At runtime, we can code split however we’d like.

Glossary of Functions

This is a list of the core functions and types and the roles they serve in this architecture.

Types

NamespaceKey — A key for a reducer or namespace within the state object.
ReducerMap — Object of all possible keys we can have on our store and their matching reducers. Is declared as a partial because it is not guaranteed that any given namespace is on the store.
StoreShape — Object of all possible keys we can have on our store and their state shapes. Is declared as a partial because it is not guaranteed that any given namespace is on the store.

Functions

hydrateWizardNamespace — Product layer function that provides initial state for the wizard namespace after the reducer is registered.
getStoreForWizardApp — Product layer function that registers the “wizard” namespace within the store.
getStateAtNamespaceKey — Function that grabs a namespace from the state object and fails quickly if that namespace is unregistered. Used to make our selectors type safe.
registerReducer — Function that injects a reducer into the store after page load. Ensures that we only register known reducers at the typing layer.

This post was originally posted on Matthew Gerstman’s personal blog. Links to original gists as well as a list of acknowledgements can be found there. You can follow Matthew on Twitter @MatthewGerstman.

// Tags

// Copy link

Link copied