Better way to use useReducer with TypeScript

Introducing useComplexState hook, a small wrapper combining Redux Toolkit, useReducer with some extra syntax sugar to make things even simpler and more to the point.

Why?

useReducer is a low-level counterpart to Redux but is meant to be used for a much smaller scope (usually a single component). As such, it comes with similar problems that Redux does out of the box - the default code is unnecessarily verbose and difficult to type.
Redux Toolkit solves those problems for Redux, but it's not really meant out of the box for useReducer. This package changes that, allowing you to use the best of both worlds.

How?

npm install use-complex-state

And then:

import { useComplexState } from "use-complex-state";

Pass to it an options object in the shape of what createSlice takes. It returns an array with a form:

[state, objectWithActions, dispatch];

note: the dispatch is exposed just in case, but you will most likely not need it

What?

Turn this:

import { useReducer } from "react";
const initialState = { count: 0 };

function reducer(
  state = initialState,
  action: { type: string; payload?: any }
) {
  switch (action.type) {
    case "increment":
      return { count: state.count + 1 };
    case "incrementBy":
      return { count: state.count + action.payload };
    default:
      throw new Error();
  }
}

export default function App() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <div>
      {state.count}
      <button onClick={() => dispatch({ type: "incrementBy", payload: 2 })}>
        2 points!
      </button>
      <button onClick={() => dispatch({ type: "increment" })}>1 point</button>
    </div>
  );
}

Into this:

import { PayloadAction } from "@reduxjs/toolkit";
import { useComplexState } from "use-complex-state";

export default function App() {
  const [state, { incrementBy, increment }] = useComplexState({
    initialState: { count: 0 },
    reducers: {
      increment: (state) => {
        state.count += 1;
      },
      incrementBy: (state, action: PayloadAction<number>) => {
        state.count += action.payload;
      },
    },
  });

  return (
    <div>
      {state.count}
      <button onClick={() => incrementBy(2)}>2 points!</button>
      <button onClick={() => increment()}>1 point</button>
    </div>
  );
}

Comparison with using Redux toolkit and useReducer directly:

import { createSlice, PayloadAction } from "@reduxjs/toolkit";

const initialState = { count: 0 }; // #2
const {
  actions: { increment, incrementBy },
  reducer,
} = createSlice({
  name: "counter", // #1
  initialState, // #2
  reducers: {
    increment: (state) => {
      state.count += 1;
    },
    incrementBy: (state, action: PayloadAction<number>) => {
      state.count += action.payload;
    },
  },
});

function App() {
  const [state, dispatch] = useReducer(reducer, initialState /* #2 */);

  return (
    <div>
      {state.count}
      <button onClick={() => dispatch(incrementBy(2)) /* #3 */}>
        2 points!
      </button>
      <button onClick={() => dispatch(increment()) /* #3 */}>1 point</button>
    </div>
  );
}

The differences are (compare with the use-complex-state example just above):

  1. The name is optional. Since we are not combining multiple slices together, as you would likely do with redux, this is just unnecessary noise.
  2. You pass the initialState just once, and you can define it in-line.
  3. No need to wrap the actions with dispatches. That wrapping is ugly, noisy, and easy to mess up (no warning if you call the action without a dispatch - might be a confusing bug to debug)

Testing

You might want to use react-testing-library, or even a browser-based tool like cypress (with react component testing) to verify the behavior of your component. If your reducers are super complex and you would like to test them without React context, you can move your slice definition out of your component.

Note: We use a prepareSliceOptions wrapper function so you still can get the benefit of TypeScript checks and code-completion on that object. That function takes an object and returns it without any transformation, except for optionally adding a name - because createSlice used for testing will expect that.

import { PayloadAction } from "@reduxjs/toolkit";
import { useComplexState, prepareSliceOptions } from "use-complex-state";

export const sliceOptions = prepareSliceOptions({
  initialState: { count: 0 },
  reducers: {
    increment: (state) => {
      state.count += 1;
    },
    incrementBy: (state, action: PayloadAction<number>) => {
      state.count += action.payload;
    },
  },
});

export default function App() {
  const [state, { incrementBy, increment }] = useComplexState(sliceOptions);

  return (
    <div>
      {state.count}
      <button onClick={() => incrementBy(2)}>2 points!</button>
      <button onClick={() => increment()}>1 point</button>
    </div>
  );
}

Then in your tests, you can test it the same way you would test redux toolkit slice:

import { createSlice } from "@reduxjs/toolkit";
import { sliceOptions } from "./App";
const {
  actions: { increment, incrementBy },
  reducer,
} = createSlice(sliceOptions);

test("increase by one", () => {
  expect(reducer({ count: 1 }, increment())).toEqual({ count: 2 });
});

test("increment by two", () => {
  expect(reducer({ count: 1 }, incrementBy(2))).toEqual({ count: 3 });
});

test("multiple actions", () => {
  const actions = [increment(), incrementBy(10), incrementBy(100)];

  expect(actions.reduce(reducer, { count: 0 })).toEqual({ count: 111 });
});

useState vs useReducer (/ use-complex-state)

If you want to learn more about when to use one or the other, take a look at this blog post:
https://xolv.io/dev-notes/choosing-between-use-state-and-use-reducer

Let me know if you have any questions or thoughts in the comments below.


Let us help you on your journey to Quality Faster

We at Xolvio specialize in helping our clients get more for less. We can get you to the holy grail of continuous deployment where every commit can go to production — and yes, even for large enterprises.

Feel free to schedule a call or send us a message below to see how we can help.

User icon
Envelope icon

or

Book a call
+
Loading Calendly widget...
  • Add types to your AWS lambda handler

    Lambdas handlers can be invoked with many different, but always complex, event arguments. Add to that the context, callback, matching return type and you basically start listing all the different ways that your function can fail in production.

  • How to expose a local service to the internet

    From time to time you might need to expose your locally running service to the external world - for example you might want to test a webhook that calls your service. To speed up the test/development feedback loop it would be great to be able to point that webhook to your local machine.

  • For loops in JavaScript (vs _.times)

    From time to time I still see a for loop in JavaScript codebases. Linters are frequently angry about them. Let's see how we can replace them.