---
title: The State Reducer Pattern with React Hooks
date: 2020-04-06
description:
  A pattern for you to use in custom hooks to enhance the power and flexibility
  of your hooks.
categories:
  - react
meta:
  keywords:
    - react
    - hooks
  translations:
    - language: 한국어
    - link: https://dkrnfls.tistory.com/403
bannerCloudinaryId: unsplash/photo-1539404234905-48cf3d73aec5
bannerCredit: Photo by [Alex Eckermann](https://unsplash.com/photos/W_K6j6OQBDg)
---

## Some History

A while ago, I developed a new pattern for enhancing your React components
called [the state reducer pattern](/blog/the-state-reducer-pattern). I used it
in [downshift](https://github.com/downshift-js/downshift) to enable an awesome
API for people who wanted to make changes to how downshift updates state
internally.

<callout-info class="aside">
	If you're unfamiliar with downshift, just know that it's an "enhanced input"
	component that allows you to build things like accessible
	autocomplete/typeahead/dropdown components. It's important to know that it
	manages the following items of state: `isOpen`, `selectedItem`,
	`highlightedIndex`, and `inputValue`.
</callout-info>

Downshift is currently implemented as a render prop component, because at the
time, render props was the best way to make a
["Headless UI Component"](https://www.merrickchristensen.com/articles/headless-user-interface-components)
(typically implemented via a "render prop" API) which made it possible for you
to share logic without being opinionated about the UI. This is the major reason
that downshift is so successful.

Today however, we have [React Hooks](https://reactjs.org/hooks) and
[hooks are way better at doing this than render props](/blog/react-hooks-whats-going-to-happen-to-render-props).
So I thought I'd give you all an update of how this pattern transfers over to
this new API the React team has given us. (Note:
[Downshift has plans to implement a hook](https://github.com/downshift-js/downshift/issues/683))

As a reminder, the benefit of the state reducer pattern is in the fact that it
allows
["inversion of control"](https://en.wikipedia.org/wiki/Inversion_of_control)
which is basically a mechanism for the author of the API to allow the user of
the API to control how things work internally. For an example-based talk about
this, I strongly recommend you give my React Rally 2018 talk a watch:

https://youtu.be/AiJ8tRRH0f8?list=PLV5CVI1eNcJgNqzNwcs4UKrlJdhfDjshf

<callout-info class="aside">
	Read also on my blog: ["Inversion of Control"](/blog/inversion-of-control)
</callout-info>

So in the downshift example, I had made the decision that when an end user
selects an item, the `isOpen` should be set to `false` (and the menu should be
closed). Someone was building a multi-select with downshift and wanted to keep
the menu open after the user selects an item in the menu (so they can continue
to select more).

By inverting control of state updates with the state reducer pattern, I was able
to enable their use case as well as any other use case people could possibly
want when they want to change how downshift operates internally. Inversion of
control is an enabling computer science principle and the state reducer pattern
is an awesome implementation of that idea that translates even better to hooks
than it did to regular components.

## Using a State Reducer with Hooks

Ok, so the concept goes like this:

1. End user does an action
2. Dev calls dispatch
3. Hook determines the necessary changes
4. Hook calls dev's code for further changes 👈 this is the inversion of control
   part
5. Hook makes the state changes

**WARNING: Contrived example ahead**: To keep things simple, I'm going to use a
simple `useToggle` hook and component as a starting point. It'll feel contrived,
but I don't want you to get distracted by a complicated example as I teach you
how to use this pattern with hooks. Just know that this pattern works best when
it's applied to complex hooks and components (like downshift).

```tsx
function useToggle() {
	const [on, setOnState] = React.useState(false)

	const toggle = () => setOnState((o) => !o)
	const setOn = () => setOnState(true)
	const setOff = () => setOnState(false)

	return { on, toggle, setOn, setOff }
}

function Toggle() {
	const { on, toggle, setOn, setOff } = useToggle()

	return (
		<div>
			<button onClick={setOff}>Switch Off</button>
			<button onClick={setOn}>Switch On</button>
			<Switch on={on} onClick={toggle} />
		</div>
	)
}

function App() {
	return <Toggle />
}

ReactDOM.render(<App />, document.getElementById('root'))
```

Now, let's say we wanted to adjust the `<Toggle />` component so the user
couldn't click the `<Switch />` more than 4 times in a row unless they click a
"Reset" button:

```tsx lines=2-3,7-10,16-19
function Toggle() {
	const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
	const tooManyClicks = clicksSinceReset >= 4

	const { on, toggle, setOn, setOff } = useToggle()

	function handleClick() {
		toggle()
		setClicksSinceReset((count) => count + 1)
	}

	return (
		<div>
			<button onClick={setOff}>Switch Off</button>
			<button onClick={setOn}>Switch On</button>
			<Switch on={on} onClick={handleClick} />
			{tooManyClicks ? (
				<button onClick={() => setClicksSinceReset(0)}>Reset</button>
			) : null}
		</div>
	)
}
```

Cool, so an easy solution to this problem would be to add an if statement in the
`handleClick` function and not call `toggle` if `tooManyClicks` is true, but
let's keep going for the purposes of this example.

How could we change the `useToggle` hook, to _invert control_ in this situation?
Let's think about the API first, then the implementation second. As a user, it'd
be cool if I could hook into every state update before it actually happens and
modify it, like so:

```tsx lines=6-14
function Toggle() {
	const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
	const tooManyClicks = clicksSinceReset >= 4

	const { on, toggle, setOn, setOff } = useToggle({
		modifyStateChange(currentState, changes) {
			if (tooManyClicks) {
				// other changes are fine, but on needs to be unchanged
				return { ...changes, on: currentState.on }
			} else {
				// the changes are fine
				return changes
			}
		},
	})

	function handleClick() {
		toggle()
		setClicksSinceReset((count) => count + 1)
	}

	return (
		<div>
			<button onClick={setOff}>Switch Off</button>
			<button onClick={setOn}>Switch On</button>
			<Switch on={on} onClick={handleClick} />
			{tooManyClicks ? (
				<button onClick={() => setClicksSinceReset(0)}>Reset</button>
			) : null}
		</div>
	)
}
```

So that's great, except it prevents changes from happening when people click the
"Switch Off" or "Switch On" buttons, and we only want to prevent the
`<Switch />` from toggling the state.

Hmmm... What if we change `modifyStateChange` to be called `reducer` and it
accepts an `action` as the second argument? Then the `action` could have a
`type` that determines what type of change is happening, and we could get the
`changes` from the `toggleReducer` which would be exported by our `useToggle`
hook. We'll just say that the `type` for clicking the switch is `TOGGLE`.

```tsx lines=6-8
function Toggle() {
	const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
	const tooManyClicks = clicksSinceReset >= 4

	const { on, toggle, setOn, setOff } = useToggle({
		reducer(currentState, action) {
			const changes = toggleReducer(currentState, action)
			if (tooManyClicks && action.type === 'TOGGLE') {
				// other changes are fine, but on needs to be unchanged
				return { ...changes, on: currentState.on }
			} else {
				// the changes are fine
				return changes
			}
		},
	})

	function handleClick() {
		toggle()
		setClicksSinceReset((count) => count + 1)
	}

	return (
		<div>
			<button onClick={setOff}>Switch Off</button>
			<button onClick={setOn}>Switch On</button>
			<Switch on={on} onClick={handleClick} />
			{tooManyClicks ? (
				<button onClick={() => setClicksSinceReset(0)}>Reset</button>
			) : null}
		</div>
	)
}
```

Nice! This gives us all kinds of control. One last thing, let's not bother with
the string `'TOGGLE'` for the type. Instead we'll have an object of all the
change types that people can reference instead. This'll help avoid typos and
improve editor autocompletion (for folks not using TypeScript):

```tsx lines=8
function Toggle() {
	const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
	const tooManyClicks = clicksSinceReset >= 4

	const { on, toggle, setOn, setOff } = useToggle({
		reducer(currentState, action) {
			const changes = toggleReducer(currenState, action)
			if (tooManyClicks && action.type === actionTypes.toggle) {
				// other changes are fine, but on needs to be unchanged
				return { ...changes, on: currentState.on }
			} else {
				// the changes are fine
				return changes
			}
		},
	})

	function handleClick() {
		toggle()
		setClicksSinceReset((count) => count + 1)
	}

	return (
		<div>
			<button onClick={setOff}>Switch Off</button>
			<button onClick={setOn}>Switch On</button>
			<Switch on={on} onClick={handleClick} />
			{tooManyClicks ? (
				<button onClick={() => setClicksSinceReset(0)}>Reset</button>
			) : null}
		</div>
	)
}
```

## Implementing a State Reducer with Hooks

Alright, I'm happy with the API we're exposing here. Let's take a look at how we
could implement this with our `useToggle` hook. In case you forgot, here's the
code for that:

```tsx
function useToggle() {
	const [on, setOnState] = React.useState(false)

	const toggle = () => setOnState((o) => !o)
	const setOn = () => setOnState(true)
	const setOff = () => setOnState(false)

	return { on, toggle, setOn, setOff }
}
```

We _could_ add logic to every one of these helper functions, but I'm just going
to skip ahead and tell you that this would be really annoying, even in this
simple hook. Instead, we're going to rewrite this from `useState` to
`useReducer` and that'll make our implementation a LOT easier:

```tsx
function toggleReducer(state, action) {
	switch (action.type) {
		case 'TOGGLE': {
			return { on: !state.on }
		}
		case 'ON': {
			return { on: true }
		}
		case 'OFF': {
			return { on: false }
		}
		default: {
			throw new Error(`Unhandled type: ${action.type}`)
		}
	}
}

function useToggle() {
	const [{ on }, dispatch] = React.useReducer(toggleReducer, { on: false })

	const toggle = () => dispatch({ type: 'TOGGLE' })
	const setOn = () => dispatch({ type: 'ON' })
	const setOff = () => dispatch({ type: 'OFF' })

	return { on, toggle, setOn, setOff }
}
```

Ok, cool. Really quick, let's add that `types` property to our `useToggle` to
avoid the strings thing. And we'll export that so users of our hook can
reference them:

```tsx lines=1-5,8,11,14,26-28,33
const actionTypes = {
	toggle: 'TOGGLE',
	on: 'ON',
	off: 'OFF',
}
function toggleReducer(state, action) {
	switch (action.type) {
		case actionTypes.toggle: {
			return { on: !state.on }
		}
		case actionTypes.on: {
			return { on: true }
		}
		case actionTypes.off: {
			return { on: false }
		}
		default: {
			throw new Error(`Unhandled type: ${action.type}`)
		}
	}
}

function useToggle() {
	const [{ on }, dispatch] = React.useReducer(toggleReducer, { on: false })

	const toggle = () => dispatch({ type: actionTypes.toggle })
	const setOn = () => dispatch({ type: actionTypes.on })
	const setOff = () => dispatch({ type: actionTypes.off })

	return { on, toggle, setOn, setOff }
}

export { useToggle, actionTypes }
```

Cool, so now, users are going to pass `reducer` as a configuration object to our
`useToggle` function, so let's accept that:

```tsx lines=1
function useToggle({ reducer }) {
	const [{ on }, dispatch] = React.useReducer(toggleReducer, { on: false })

	const toggle = () => dispatch({ type: actionTypes.toggle })
	const setOn = () => dispatch({ type: actionTypes.on })
	const setOff = () => dispatch({ type: actionTypes.off })

	return { on, toggle, setOn, setOff }
}
```

Great, so now that we have the developer's `reducer`, how do we combine that
with our reducer? Well, if we're truly going to invert control for the user of
our hook, we don't want to call our own `reducer`. Instead, let's expose our own
reducer and they can use it themselves if they want to, so let's export it, and
then we'll use the `reducer` they give us instead of our own:

```tsx lines=2, 11
function useToggle({ reducer }) {
	const [{ on }, dispatch] = React.useReducer(reducer, { on: false })

	const toggle = () => dispatch({ type: actionTypes.toggle })
	const setOn = () => dispatch({ type: actionTypes.on })
	const setOff = () => dispatch({ type: actionTypes.off })

	return { on, toggle, setOn, setOff }
}

export { useToggle, actionTypes, toggleReducer }
```

Great, but now everyone using our component has to provide a reducer which is
not really what we want. We want to enable inversion of control for people who
_do_ want control, but for the more common case, they shouldn't have to do
anything special, so let's add some defaults:

```tsx lines=1
function useToggle({ reducer = toggleReducer } = {}) {
	const [{ on }, dispatch] = React.useReducer(reducer, { on: false })

	const toggle = () => dispatch({ type: actionTypes.toggle })
	const setOn = () => dispatch({ type: actionTypes.on })
	const setOff = () => dispatch({ type: actionTypes.off })

	return { on, toggle, setOn, setOff }
}

export { useToggle, actionTypes, toggleReducer }
```

Sweet, so now people can use our `useToggle` hook with their own reducer or they
can use it with the built-in one. Either way works just as well.

## Conclusion

Here's the final version:

```tsx
import * as React from 'react'
import ReactDOM from 'react-dom'
import Switch from './switch'

const actionTypes = {
	toggle: 'TOGGLE',
	on: 'ON',
	off: 'OFF',
}

function toggleReducer(state, action) {
	switch (action.type) {
		case actionTypes.toggle: {
			return { on: !state.on }
		}
		case actionTypes.on: {
			return { on: true }
		}
		case actionTypes.off: {
			return { on: false }
		}
		default: {
			throw new Error(`Unhandled type: ${action.type}`)
		}
	}
}

function useToggle({ reducer = toggleReducer } = {}) {
	const [{ on }, dispatch] = React.useReducer(reducer, { on: false })

	const toggle = () => dispatch({ type: actionTypes.toggle })
	const setOn = () => dispatch({ type: actionTypes.on })
	const setOff = () => dispatch({ type: actionTypes.off })

	return { on, toggle, setOn, setOff }
}

// export {useToggle, actionTypes, toggleReducer}

function Toggle() {
	const [clicksSinceReset, setClicksSinceReset] = React.useState(0)
	const tooManyClicks = clicksSinceReset >= 4

	const { on, toggle, setOn, setOff } = useToggle({
		reducer(currentState, action) {
			const changes = toggleReducer(currentState, action)
			if (tooManyClicks && action.type === actionTypes.toggle) {
				// other changes are fine, but on needs to be unchanged
				return { ...changes, on: currentState.on }
			} else {
				// the changes are fine
				return changes
			}
		},
	})

	return (
		<div>
			<button onClick={setOff}>Switch Off</button>
			<button onClick={setOn}>Switch On</button>
			<Switch
				onClick={() => {
					toggle()
					setClicksSinceReset((count) => count + 1)
				}}
				on={on}
			/>
			{tooManyClicks ? (
				<button onClick={() => setClicksSinceReset(0)}>Reset</button>
			) : null}
		</div>
	)
}

function App() {
	return <Toggle />
}

ReactDOM.render(<App />, document.getElementById('root'))
```

And here it is running in [a codesandbox](https://codesandbox.io/s/9j0pkq30lo):

https://codesandbox.io/s/9j0pkq30lo

Remember, what we've done here is enable users to hook into every state update
of our reducer to make changes to it. This makes our hook WAY more flexible, but
it also means that the way we update state is now part of the API and if we make
changes to how that happens, then it could be a breaking change for users. It's
totally worth the trade-off for complex hooks/components, but it's just good to
keep that in mind.

I hope you find patterns like this useful. Thanks to `useReducer`, this pattern
just kinda falls out (thank you React!). So give it a try on your codebase!

Good luck!
