惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

人人都是产品经理
人人都是产品经理
D
Docker
GbyAI
GbyAI
B
Blog RSS Feed
博客园 - 司徒正美
博客园 - Franky
美团技术团队
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
aimingoo的专栏
aimingoo的专栏
C
Check Point Blog
IT之家
IT之家
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
www.infosecurity-magazine.com
www.infosecurity-magazine.com
AI
AI
O
OpenAI News
Attack and Defense Labs
Attack and Defense Labs
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
T
Tailwind CSS Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
S
Secure Thoughts
博客园 - 聂微东
L
LINUX DO - 最新话题
U
Unit 42
SecWiki News
SecWiki News
A
Arctic Wolf
Schneier on Security
Schneier on Security
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
V
Visual Studio Blog
量子位
The Cloudflare Blog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
大猫的无限游戏
大猫的无限游戏
Google DeepMind News
Google DeepMind News
G
Google Developers Blog
T
Threat Research - Cisco Blogs
TaoSecurity Blog
TaoSecurity Blog
Recent Commits to openclaw:main
Recent Commits to openclaw:main
B
Blog
博客园 - 【当耐特】
C
CERT Recently Published Vulnerability Notes
Scott Helme
Scott Helme
Last Week in AI
Last Week in AI
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Microsoft Security Blog
Microsoft Security Blog
Apple Machine Learning Research
Apple Machine Learning Research
F
Full Disclosure
Hacker News: Ask HN
Hacker News: Ask HN
A
About on SuperTechFans
博客园 - 三生石上(FineUI控件)
Latest news
Latest news

Kent C. Dodds Blog

Implementing Hybrid Semantic + Lexical Search Simplifying Containers with Cloudflare Sandboxes Migrating to Workspaces and Nx Offloading FFmpeg with Cloudflare Building Semantic Search on my Content Helping YOU ask ME questions with AI How I used Cursor to Migrate Frameworks The Dow's Start on the Covenant Path 2025 in Review The next chapter: EpicAI.pro AI is taking your job How I increased my visibility Launching Epic Web 2023 in Review Stop Being a Junior RSC with Dan Abramov and Joe Savona Live Stream Fixing a Memory Leak in a Production Node.js App 2022 in Review My Car Accident I Migrated from a Postgres Cluster to Distributed SQLite with LiteFS I'm building EpicWeb.dev A review of my time at Remix Remix: The Yang to React's Yin How I help you build better websites Why I Love Remix The State Initializer Pattern How to React ⚛️ Get a catch block error message with TypeScript Building an awesome image loading experience How Remix makes CSS clashes predictable Introducing the new kentcdodds.com How I built a modern website in 2021 How to use React Context effectively Static vs Unit vs Integration vs E2E Testing for Frontend Apps The Testing Trophy and Testing Classifications Array reduce vs chaining vs for loop Don't Solve Problems, Eliminate Them Super Simple Start to Remix Super Simple Start to ESModules in Node.js JavaScript Pass By Value Function Parameters How to write a Constrained Identity Function (CIF) in TypeScript How to optimize your context value How to write a React Component in TypeScript TypeScript Function Syntaxes Listify a JavaScript Array Build vs Buy: Component Libraries edition Using fetch with TypeScript Wrapping React.useState with TypeScript Define function overload types with TypeScript 2020 in Review Business and Engineering alignment Hi, thanks for reaching out to me 👋 useEffect vs useLayoutEffect Super simple start to Firebase functions Super simple start to Netlify functions Super Simple Start to css variables Favor Progress Over Pride in Open Source Testing Implementation Details How getting into Open Source has been awesome for me useState lazy initialization and function updates Use ternaries rather than && in JSX Application State Management with React Use react-error-boundary to handle errors in React JavaScript to Know for React How I structure Express apps What open source project should I contribute to? When I follow TDD AHA Programming 💡 How I Record Educational Videos Should I write a test or fix a bug? Stop mocking fetch Intentional Career Building Improve test error messages of your abstractions Tracing user interactions with React Eliminate an entire category of bugs with a few simple tools Common mistakes with React Testing Library Super Simple Start to React Stop using client-side route redirects Function forms Replace axios with a simple custom fetch wrapper How to test custom React hooks React Production Performance Monitoring Should I useState or useReducer? Stop using isLoading booleans Make Your Test Fail Make your own DevTools An Argument for Automation Fix the "not wrapped in act(...)" warning Super Simple Start to ESModules in the Browser Implementing a simple state machine library in JavaScript 2010s Decade in Review Why users care about how you write code Why I avoid nesting closures Don't call a React function component Why your team needs TestingJavaScript.com Inversion of Control Understanding React's key prop How to Enable React Concurrent Mode How to add testing to an existing project Profile a React App for Performance
The State Reducer Pattern with React Hooks
2020-04-06 · via Kent C. Dodds Blog

Some History

A while ago, I developed a new pattern for enhancing your React components called the state reducer pattern. I used it in downshift to enable an awesome API for people who wanted to make changes to how downshift updates state internally.

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.

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" (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 and hooks are way better at doing this than 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)

As a reminder, the benefit of the state reducer pattern is in the fact that it allows "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:

Read also on my blog: "Inversion of Control"

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).

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:

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:

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.

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):

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:

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:

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:

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:

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:

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:

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:

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:

Error embedding 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!