Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class.
\nThis page answers some of the frequently asked questions about Hooks.
\n\nStarting with 16.8.0, React includes a stable implementation of React Hooks for:
\nNote that to enable Hooks, all React packages need to be 16.8.0 or higher. Hooks won’t work if you forget to update, for example, React DOM.
\nReact Native 0.59 and above support Hooks.
\nNo. There are no plans to remove classes from React — we all need to keep shipping products and can’t afford rewrites. We recommend trying Hooks in new code.
\nHooks offer a powerful and expressive new way to reuse functionality between components. “Building Your Own Hooks” provides a glimpse of what’s possible. This article by a React core team member dives deeper into the new capabilities unlocked by Hooks.
\nHooks are a more direct way to use the React features you already know — such as state, lifecycle, context, and refs. They don’t fundamentally change how React works, and your knowledge of components, props, and top-down data flow is just as relevant.
\nHooks do have a learning curve of their own. If there’s something missing in this documentation, raise an issue and we’ll try to help.
\nWhen you’re ready, we’d encourage you to start trying Hooks in new components you write. Make sure everyone on your team is on board with using them and familiar with this documentation. We don’t recommend rewriting your existing classes to Hooks unless you planned to rewrite them anyway (e.g. to fix bugs).
\nYou can’t use Hooks inside a class component, but you can definitely mix classes and function components with Hooks in a single tree. Whether a component is a class or a function that uses Hooks is an implementation detail of that component. In the longer term, we expect Hooks to be the primary way people write React components.
\nOur goal is for Hooks to cover all use cases for classes as soon as possible. There are no Hook equivalents to the uncommon getSnapshotBeforeUpdate, getDerivedStateFromError and componentDidCatch lifecycles yet, but we plan to add them soon.
It is an early time for Hooks, and some third-party libraries might not be compatible with Hooks at the moment.
\nOften, render props and higher-order components render only a single child. We think Hooks are a simpler way to serve this use case. There is still a place for both patterns (for example, a virtual scroller component might have a renderItem prop, or a visual container component might have its own DOM structure). But in most cases, Hooks will be sufficient and can help reduce nesting in your tree.
connect() and React Router? You can continue to use the exact same APIs as you always have; they’ll continue to work.
\nReact Redux since v7.1.0 supports Hooks API and exposes hooks like useDispatch or useSelector.
React Router supports hooks since v5.1.
\nOther libraries might support hooks in the future too.
\nHooks were designed with static typing in mind. Because they’re functions, they are easier to type correctly than patterns like higher-order components. The latest Flow and TypeScript React definitions include support for React Hooks.
\nImportantly, custom Hooks give you the power to constrain React API if you’d like to type them more strictly in some way. React gives you the primitives, but you can combine them in different ways than what we provide out of the box.
\nFrom React’s point of view, a component using Hooks is just a regular component. If your testing solution doesn’t rely on React internals, testing components with Hooks shouldn’t be different from how you normally test components.
\n\n\nNote
\nTesting Recipes include many examples that you can copy and paste.
\n
For example, let’s say we have this counter component:
\nfunction Example() {\n const [count, setCount] = useState(0);\n useEffect(() => {\n document.title = `You clicked ${count} times`;\n });\n return (\n <div>\n <p>You clicked {count} times</p>\n <button onClick={() => setCount(count + 1)}>\n Click me\n </button>\n </div>\n );\n}We’ll test it using React DOM. To make sure that the behavior matches what happens in the browser, we’ll wrap the code rendering and updating it into ReactTestUtils.act() calls:
import React from 'react';\nimport ReactDOM from 'react-dom';\nimport { act } from 'react-dom/test-utils';import Counter from './Counter';\n\nlet container;\n\nbeforeEach(() => {\n container = document.createElement('div');\n document.body.appendChild(container);\n});\n\nafterEach(() => {\n document.body.removeChild(container);\n container = null;\n});\n\nit('can render and update a counter', () => {\n // Test first render and effect\n act(() => { ReactDOM.render(<Counter />, container); }); const button = container.querySelector('button');\n const label = container.querySelector('p');\n expect(label.textContent).toBe('You clicked 0 times');\n expect(document.title).toBe('You clicked 0 times');\n\n // Test second render and effect\n act(() => { button.dispatchEvent(new MouseEvent('click', {bubbles: true})); }); expect(label.textContent).toBe('You clicked 1 times');\n expect(document.title).toBe('You clicked 1 times');\n});The calls to act() will also flush the effects inside of them.
If you need to test a custom Hook, you can do so by creating a component in your test, and using your Hook from it. Then you can test the component you wrote.
\nTo reduce the boilerplate, we recommend using React Testing Library which is designed to encourage writing tests that use your components as the end users do.
\nFor more information, check out Testing Recipes.
\nWe provide an ESLint plugin that enforces rules of Hooks to avoid bugs. It assumes that any function starting with ”use” and a capital letter right after it is a Hook. We recognize this heuristic isn’t perfect and there may be some false positives, but without an ecosystem-wide convention there is just no way to make Hooks work well — and longer names will discourage people from either adopting Hooks or following the convention.
In particular, the rule enforces that:
\nPascalCase function (assumed to be a component) or another useSomething function (assumed to be a custom Hook).There are a few more heuristics, and they might change over time as we fine-tune the rule to balance finding bugs with avoiding false positives.
\nconstructor: Function components don’t need a constructor. You can initialize the state in the useState call. If computing the initial state is expensive, you can pass a function to useState.getDerivedStateFromProps: Schedule an update while rendering instead.shouldComponentUpdate: See React.memo below.render: This is the function component body itself.componentDidMount, componentDidUpdate, componentWillUnmount: The useEffect Hook can express all combinations of these (including less common cases).getSnapshotBeforeUpdate, componentDidCatch and getDerivedStateFromError: There are no Hook equivalents for these methods yet, but they will be added soon.Here is a small demo to get you started. To learn more, check out this article about data fetching with Hooks.
\nYes! The useRef() Hook isn’t just for DOM refs. The “ref” object is a generic container whose current property is mutable and can hold any value, similar to an instance property on a class.
You can write to it from inside useEffect:
function Timer() {\n const intervalRef = useRef();\n useEffect(() => {\n const id = setInterval(() => {\n // ...\n });\n intervalRef.current = id; return () => {\n clearInterval(intervalRef.current);\n };\n });\n\n // ...\n}If we just wanted to set an interval, we wouldn’t need the ref (id could be local to the effect), but it’s useful if we want to clear the interval from an event handler:
// ...\n function handleCancelClick() {\n clearInterval(intervalRef.current); }\n // ...Conceptually, you can think of refs as similar to instance variables in a class. Unless you’re doing lazy initialization, avoid setting refs during rendering — this can lead to surprising behavior. Instead, typically you want to modify refs in event handlers and effects.
\nIf you’re coming from classes, you might be tempted to always call useState() once and put all state into a single object. You can do it if you’d like. Here is an example of a component that follows the mouse movement. We keep its position and size in the local state:
function Box() {\n const [state, setState] = useState({ left: 0, top: 0, width: 100, height: 100 });\n // ...\n}Now let’s say we want to write some logic that changes left and top when the user moves their mouse. Note how we have to merge these fields into the previous state object manually:
// ...\n useEffect(() => {\n function handleWindowMouseMove(e) {\n // Spreading \"...state\" ensures we don't \"lose\" width and height setState(state => ({ ...state, left: e.pageX, top: e.pageY })); }\n // Note: this implementation is a bit simplified\n window.addEventListener('mousemove', handleWindowMouseMove);\n return () => window.removeEventListener('mousemove', handleWindowMouseMove);\n }, []);\n // ...This is because when we update a state variable, we replace its value. This is different from this.setState in a class, which merges the updated fields into the object.
If you miss automatic merging, you could write a custom useLegacyState Hook that merges object state updates. However, we recommend to split state into multiple state variables based on which values tend to change together.
For example, we could split our component state into position and size objects, and always replace the position with no need for merging:
function Box() {\n const [position, setPosition] = useState({ left: 0, top: 0 }); const [size, setSize] = useState({ width: 100, height: 100 });\n\n useEffect(() => {\n function handleWindowMouseMove(e) {\n setPosition({ left: e.pageX, top: e.pageY }); }\n // ...Separating independent state variables also has another benefit. It makes it easy to later extract some related logic into a custom Hook, for example:
\nfunction Box() {\n const position = useWindowPosition(); const [size, setSize] = useState({ width: 100, height: 100 });\n // ...\n}\n\nfunction useWindowPosition() { const [position, setPosition] = useState({ left: 0, top: 0 });\n useEffect(() => {\n // ...\n }, []);\n return position;\n}Note how we were able to move the useState call for the position state variable and the related effect into a custom Hook without changing their code. If all state was in a single object, extracting it would be more difficult.
Both putting all state in a single useState call, and having a useState call per each field can work. Components tend to be most readable when you find a balance between these two extremes, and group related state into a few independent state variables. If the state logic becomes complex, we recommend managing it with a reducer or a custom Hook.
This is a rare use case. If you need it, you can use a mutable ref to manually store a boolean value corresponding to whether you are on the first or a subsequent render, then check that flag in your effect. (If you find yourself doing this often, you could create a custom Hook for it.)
\nCurrently, you can do it manually with a ref:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n const prevCountRef = useRef();\n useEffect(() => {\n prevCountRef.current = count; });\n const prevCount = prevCountRef.current;\n return <h1>Now: {count}, before: {prevCount}</h1>;\n}This might be a bit convoluted but you can extract it into a custom Hook:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n const prevCount = usePrevious(count); return <h1>Now: {count}, before: {prevCount}</h1>;\n}\n\nfunction usePrevious(value) { const ref = useRef();\n useEffect(() => {\n ref.current = value;\n });\n return ref.current;\n}Note how this would work for props, state, or any other calculated value.
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n const calculation = count + 100;\n const prevCalculation = usePrevious(calculation); // ...It’s possible that in the future React will provide a usePrevious Hook out of the box since it’s a relatively common use case.
See also the recommended pattern for derived state.
\nAny function inside a component, including event handlers and effects, “sees” the props and state from the render it was created in. For example, consider code like this:
\nfunction Example() {\n const [count, setCount] = useState(0);\n\n function handleAlertClick() {\n setTimeout(() => {\n alert('You clicked on: ' + count);\n }, 3000);\n }\n\n return (\n <div>\n <p>You clicked {count} times</p>\n <button onClick={() => setCount(count + 1)}>\n Click me\n </button>\n <button onClick={handleAlertClick}>\n Show alert\n </button>\n </div>\n );\n}If you first click “Show alert” and then increment the counter, the alert will show the count variable at the time you clicked the “Show alert” button. This prevents bugs caused by the code assuming props and state don’t change.
If you intentionally want to read the latest state from some asynchronous callback, you could keep it in a ref, mutate it, and read from it.
\nFinally, another possible reason you’re seeing stale props or state is if you use the “dependency array” optimization but didn’t correctly specify all the dependencies. For example, if an effect specifies [] as the second argument but reads someProp inside, it will keep “seeing” the initial value of someProp. The solution is to either remove the dependency array, or to fix it. Here’s how you can deal with functions, and here’s other common strategies to run effects less often without incorrectly skipping dependencies.
\n\nNote
\nWe provide an
\nexhaustive-depsESLint rule as a part of theeslint-plugin-react-hookspackage. It warns when dependencies are specified incorrectly and suggests a fix.
getDerivedStateFromProps? While you probably don’t need it, in rare cases that you do (such as implementing a <Transition> component), you can update the state right during rendering. React will re-run the component with updated state immediately after exiting the first render so it wouldn’t be expensive.
Here, we store the previous value of the row prop in a state variable so that we can compare:
function ScrollView({row}) {\n const [isScrollingDown, setIsScrollingDown] = useState(false);\n const [prevRow, setPrevRow] = useState(null);\n\n if (row !== prevRow) {\n // Row changed since last render. Update isScrollingDown.\n setIsScrollingDown(prevRow !== null && row > prevRow);\n setPrevRow(row);\n }\n\n return `Scrolling down: ${isScrollingDown}`;\n}This might look strange at first, but an update during rendering is exactly what getDerivedStateFromProps has always been like conceptually.
Both useState and useReducer Hooks bail out of updates if the next value is the same as the previous one. Mutating state in place and calling setState will not cause a re-render.
Normally, you shouldn’t mutate local state in React. However, as an escape hatch, you can use an incrementing counter to force a re-render even if the state has not changed:
\n const [ignored, forceUpdate] = useReducer(x => x + 1, 0);\n\n function handleClick() {\n forceUpdate();\n }Try to avoid this pattern if possible.
\nWhile you shouldn’t need this often, you may expose some imperative methods to a parent component with the useImperativeHandle Hook.
One rudimentary way to measure the position or size of a DOM node is to use a callback ref. React will call that callback whenever the ref gets attached to a different node. Here is a small demo:
\nfunction MeasureExample() {\n const [height, setHeight] = useState(0);\n\n const measuredRef = useCallback(node => { if (node !== null) { setHeight(node.getBoundingClientRect().height); } }, []);\n return (\n <>\n <h1 ref={measuredRef}>Hello, world</h1> <h2>The above header is {Math.round(height)}px tall</h2>\n </>\n );\n}We didn’t choose useRef in this example because an object ref doesn’t notify us about changes to the current ref value. Using a callback ref ensures that even if a child component displays the measured node later (e.g. in response to a click), we still get notified about it in the parent component and can update the measurements.
Note that we pass [] as a dependency array to useCallback. This ensures that our ref callback doesn’t change between the re-renders, and so React won’t call it unnecessarily.
In this example, the callback ref will be called only when the component mounts and unmounts, since the rendered <h1> component stays present throughout any rerenders. If you want to be notified any time a component resizes, you may want to use ResizeObserver or a third-party Hook built on it.
If you want, you can extract this logic into a reusable Hook:
\nfunction MeasureExample() {\n const [rect, ref] = useClientRect(); return (\n <>\n <h1 ref={ref}>Hello, world</h1>\n {rect !== null &&\n <h2>The above header is {Math.round(rect.height)}px tall</h2>\n }\n </>\n );\n}\n\nfunction useClientRect() {\n const [rect, setRect] = useState(null);\n const ref = useCallback(node => {\n if (node !== null) {\n setRect(node.getBoundingClientRect());\n }\n }, []);\n return [rect, ref];\n}const [thing, setThing] = useState() mean? If you’re not familiar with this syntax, check out the explanation in the State Hook documentation.
\nYes. See conditionally firing an effect. Note that forgetting to handle updates often introduces bugs, which is why this isn’t the default behavior.
\nGenerally speaking, no.
\nfunction Example({ someProp }) {\n function doSomething() {\n console.log(someProp); }\n\n useEffect(() => {\n doSomething();\n }, []); // 🔴 This is not safe (it calls `doSomething` which uses `someProp`)}It’s difficult to remember which props or state are used by functions outside of the effect. This is why usually you’ll want to declare functions needed by an effect inside of it. Then it’s easy to see what values from the component scope that effect depends on:
\nfunction Example({ someProp }) {\n useEffect(() => {\n function doSomething() {\n console.log(someProp); }\n\n doSomething();\n }, [someProp]); // ✅ OK (our effect only uses `someProp`)}If after that we still don’t use any values from the component scope, it’s safe to specify []:
useEffect(() => {\n function doSomething() {\n console.log('hello');\n }\n\n doSomething();\n}, []); // ✅ OK in this example because we don't use *any* values from component scopeDepending on your use case, there are a few more options described below.
\n\n\nNote
\nWe provide the
\nexhaustive-depsESLint rule as a part of theeslint-plugin-react-hookspackage. It helps you find components that don’t handle updates consistently.
Let’s see why this matters.
\nIf you specify a list of dependencies as the last argument to useEffect, useLayoutEffect, useMemo, useCallback, or useImperativeHandle, it must include all values that are used inside the callback and participate in the React data flow. That includes props, state, and anything derived from them.
It is only safe to omit a function from the dependency list if nothing in it (or the functions called by it) references props, state, or values derived from them. This example has a bug:
\nfunction ProductPage({ productId }) {\n const [product, setProduct] = useState(null);\n\n async function fetchProduct() {\n const response = await fetch('http://myapi/product/' + productId); // Uses productId prop const json = await response.json();\n setProduct(json);\n }\n\n useEffect(() => {\n fetchProduct();\n }, []); // 🔴 Invalid because `fetchProduct` uses `productId` // ...\n}The recommended fix is to move that function inside of your effect. That makes it easy to see which props or state your effect uses, and to ensure they’re all declared:
\nfunction ProductPage({ productId }) {\n const [product, setProduct] = useState(null);\n\n useEffect(() => {\n // By moving this function inside the effect, we can clearly see the values it uses. async function fetchProduct() { const response = await fetch('http://myapi/product/' + productId); const json = await response.json(); setProduct(json); }\n fetchProduct();\n }, [productId]); // ✅ Valid because our effect only uses productId // ...\n}This also allows you to handle out-of-order responses with a local variable inside the effect:
\n useEffect(() => {\n let ignore = false; async function fetchProduct() {\n const response = await fetch('http://myapi/product/' + productId);\n const json = await response.json();\n if (!ignore) setProduct(json); }\n\n fetchProduct();\n return () => { ignore = true }; }, [productId]);We moved the function inside the effect so it doesn’t need to be in its dependency list.
\n\n\nTip
\nCheck out this small demo and this article to learn more about data fetching with Hooks.
\n
If for some reason you can’t move a function inside an effect, there are a few more options:
\nuseCallback Hook. This ensures it doesn’t change on every render unless its own dependencies also change:function ProductPage({ productId }) {\n // ✅ Wrap with useCallback to avoid change on every render const fetchProduct = useCallback(() => { // ... Does something with productId ... }, [productId]); // ✅ All useCallback dependencies are specified\n return <ProductDetails fetchProduct={fetchProduct} />;\n}\n\nfunction ProductDetails({ fetchProduct }) {\n useEffect(() => {\n fetchProduct();\n }, [fetchProduct]); // ✅ All useEffect dependencies are specified\n // ...\n}Note that in the above example we need to keep the function in the dependencies list. This ensures that a change in the productId prop of ProductPage automatically triggers a refetch in the ProductDetails component.
Sometimes, your effect may be using state that changes too often. You might be tempted to omit that state from a list of dependencies, but that usually leads to bugs:
\nfunction Counter() {\n const [count, setCount] = useState(0);\n\n useEffect(() => {\n const id = setInterval(() => {\n setCount(count + 1); // This effect depends on the `count` state }, 1000);\n return () => clearInterval(id);\n }, []); // 🔴 Bug: `count` is not specified as a dependency\n return <h1>{count}</h1>;\n}The empty set of dependencies, [], means that the effect will only run once when the component mounts, and not on every re-render. The problem is that inside the setInterval callback, the value of count does not change, because we’ve created a closure with the value of count set to 0 as it was when the effect callback ran. Every second, this callback then calls setCount(0 + 1), so the count never goes above 1.
Specifying [count] as a list of dependencies would fix the bug, but would cause the interval to be reset on every change. Effectively, each setInterval would get one chance to execute before being cleared (similar to a setTimeout.) That may not be desirable. To fix this, we can use the functional update form of setState. It lets us specify how the state needs to change without referencing the current state:
function Counter() {\n const [count, setCount] = useState(0);\n\n useEffect(() => {\n const id = setInterval(() => {\n setCount(c => c + 1); // ✅ This doesn't depend on `count` variable outside }, 1000);\n return () => clearInterval(id);\n }, []); // ✅ Our effect doesn't use any variables in the component scope\n return <h1>{count}</h1>;\n}(The identity of the setCount function is guaranteed to be stable so it’s safe to omit.)
Now, the setInterval callback executes once a second, but each time the inner call to setCount can use an up-to-date value for count (called c in the callback here.)
In more complex cases (such as if one state depends on another state), try moving the state update logic outside the effect with the useReducer Hook. This article offers an example of how you can do this. The identity of the dispatch function from useReducer is always stable — even if the reducer function is declared inside the component and reads its props.
As a last resort, if you want something like this in a class, you can use a ref to hold a mutable variable. Then you can write and read to it. For example:
function Example(props) {\n // Keep latest props in a ref. const latestProps = useRef(props); useEffect(() => { latestProps.current = props; });\n useEffect(() => {\n function tick() {\n // Read latest props at any time console.log(latestProps.current); }\n\n const id = setInterval(tick, 1000);\n return () => clearInterval(id);\n }, []); // This effect never re-runs}Only do this if you couldn’t find a better alternative, as relying on mutation makes components less predictable. If there’s a specific pattern that doesn’t translate well, file an issue with a runnable example code and we can try to help.
\nshouldComponentUpdate? You can wrap a function component with React.memo to shallowly compare its props:
const Button = React.memo((props) => {\n // your component\n});It’s not a Hook because it doesn’t compose like Hooks do. React.memo is equivalent to PureComponent, but it only compares props. (You can also add a second argument to specify a custom comparison function that takes the old and new props. If it returns true, the update is skipped.)
React.memo doesn’t compare state because there is no single state object to compare. But you can make children pure too, or even optimize individual children with useMemo.
The useMemo Hook lets you cache calculations between multiple renders by “remembering” the previous computation:
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);This code calls computeExpensiveValue(a, b). But if the dependencies [a, b] haven’t changed since the last value, useMemo skips calling it a second time and simply reuses the last value it returned.
Remember that the function passed to useMemo runs during rendering. Don’t do anything there that you wouldn’t normally do while rendering. For example, side effects belong in useEffect, not useMemo.
You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance. (For rare cases when a value must never be recomputed, you can lazily initialize a ref.)
Conveniently, useMemo also lets you skip an expensive re-render of a child:
function Parent({ a, b }) {\n // Only re-rendered if `a` changes:\n const child1 = useMemo(() => <Child1 a={a} />, [a]);\n // Only re-rendered if `b` changes:\n const child2 = useMemo(() => <Child2 b={b} />, [b]);\n return (\n <>\n {child1}\n {child2}\n </>\n )\n}Note that this approach won’t work in a loop because Hook calls can’t be placed inside loops. But you can extract a separate component for the list item, and call useMemo there.
useMemo lets you memoize an expensive calculation if the dependencies are the same. However, it only serves as a hint, and doesn’t guarantee the computation won’t re-run. But sometimes you need to be sure an object is only created once.
The first common use case is when creating the initial state is expensive:
\nfunction Table(props) {\n // ⚠️ createRows() is called on every render\n const [rows, setRows] = useState(createRows(props.count));\n // ...\n}To avoid re-creating the ignored initial state, we can pass a function to useState:
function Table(props) {\n // ✅ createRows() is only called once\n const [rows, setRows] = useState(() => createRows(props.count));\n // ...\n}React will only call this function during the first render. See the useState API reference.
You might also occasionally want to avoid re-creating the useRef() initial value. For example, maybe you want to ensure some imperative class instance only gets created once:
function Image(props) {\n // ⚠️ IntersectionObserver is created on every render\n const ref = useRef(new IntersectionObserver(onIntersect));\n // ...\n}useRef does not accept a special function overload like useState. Instead, you can write your own function that creates and sets it lazily:
function Image(props) {\n const ref = useRef(null);\n\n // ✅ IntersectionObserver is created lazily once\n function getObserver() {\n if (ref.current === null) {\n ref.current = new IntersectionObserver(onIntersect);\n }\n return ref.current;\n }\n\n // When you need it, call getObserver()\n // ...\n}This avoids creating an expensive object until it’s truly needed for the first time. If you use Flow or TypeScript, you can also give getObserver() a non-nullable type for convenience.
No. In modern browsers, the raw performance of closures compared to classes doesn’t differ significantly except in extreme scenarios.
\nIn addition, consider that the design of Hooks is more efficient in a couple ways:
\nTraditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks shouldComponentUpdate optimizations in child components. Hooks approach this problem from three sides.
The useCallback Hook lets you keep the same callback reference between re-renders so that shouldComponentUpdate continues to work:
// Will not change unless `a` or `b` changes\nconst memoizedCallback = useCallback(() => { doSomething(a, b);\n}, [a, b]);useMemo Hook makes it easier to control when individual children update, reducing the need for pure components.useReducer Hook reduces the need to pass callbacks deeply, as explained below.We’ve found that most people don’t enjoy manually passing callbacks through every level of a component tree. Even though it is more explicit, it can feel like a lot of “plumbing”.
\nIn large component trees, an alternative we recommend is to pass down a dispatch function from useReducer via context:
const TodosDispatch = React.createContext(null);\n\nfunction TodosApp() {\n // Note: `dispatch` won't change between re-renders const [todos, dispatch] = useReducer(todosReducer);\n return (\n <TodosDispatch.Provider value={dispatch}>\n <DeepTree todos={todos} />\n </TodosDispatch.Provider>\n );\n}Any child in the tree inside TodosApp can use the dispatch function to pass actions up to TodosApp:
function DeepChild(props) {\n // If we want to perform an action, we can get dispatch from context. const dispatch = useContext(TodosDispatch);\n function handleClick() {\n dispatch({ type: 'add', text: 'hello' });\n }\n\n return (\n <button onClick={handleClick}>Add todo</button>\n );\n}This is both more convenient from the maintenance perspective (no need to keep forwarding callbacks), and avoids the callback problem altogether. Passing dispatch down like this is the recommended pattern for deep updates.
Note that you can still choose whether to pass the application state down as props (more explicit) or as context (more convenient for very deep updates). If you use context to pass down the state too, use two different context types — the dispatch context never changes, so components that read it don’t need to rerender unless they also need the application state.
useCallback? \n\nNote
\nWe recommend to pass
\ndispatchdown in context rather than individual callbacks in props. The approach below is only mentioned here for completeness and as an escape hatch.Also note that this pattern might cause problems in the concurrent mode. We plan to provide more ergonomic alternatives in the future, but the safest solution right now is to always invalidate the callback if some value it depends on changes.
\n
In some rare cases you might need to memoize a callback with useCallback but the memoization doesn’t work very well because the inner function has to be re-created too often. If the function you’re memoizing is an event handler and isn’t used during rendering, you can use ref as an instance variable, and save the last committed value into it manually:
function Form() {\n const [text, updateText] = useState('');\n const textRef = useRef();\n\n useEffect(() => {\n textRef.current = text; // Write it to the ref });\n\n const handleSubmit = useCallback(() => {\n const currentText = textRef.current; // Read it from the ref alert(currentText);\n }, [textRef]); // Don't recreate handleSubmit like [text] would do\n\n return (\n <>\n <input value={text} onChange={e => updateText(e.target.value)} />\n <ExpensiveTree onSubmit={handleSubmit} />\n </>\n );\n}This is a rather convoluted pattern but it shows that you can do this escape hatch optimization if you need it. It’s more bearable if you extract it to a custom Hook:
\nfunction Form() {\n const [text, updateText] = useState('');\n // Will be memoized even if `text` changes:\n const handleSubmit = useEventCallback(() => { alert(text);\n }, [text]);\n\n return (\n <>\n <input value={text} onChange={e => updateText(e.target.value)} />\n <ExpensiveTree onSubmit={handleSubmit} />\n </>\n );\n}\n\nfunction useEventCallback(fn, dependencies) { const ref = useRef(() => {\n throw new Error('Cannot call an event handler while rendering.');\n });\n\n useEffect(() => {\n ref.current = fn;\n }, [fn, ...dependencies]);\n\n return useCallback(() => {\n const fn = ref.current;\n return fn();\n }, [ref]);\n}In either case, we don’t recommend this pattern and only show it here for completeness. Instead, it is preferable to avoid passing callbacks deep down.
\nReact keeps track of the currently rendering component. Thanks to the Rules of Hooks, we know that Hooks are only called from React components (or custom Hooks — which are also only called from React components).
\nThere is an internal list of “memory cells” associated with each component. They’re just JavaScript objects where we can put some data. When you call a Hook like useState(), it reads the current cell (or initializes it during the first render), and then moves the pointer to the next one. This is how multiple useState() calls each get independent local state.
Hooks synthesize ideas from several different sources:
\nadopt keyword proposal as a sugar syntax for render props.Sebastian Markbåge came up with the original design for Hooks, later refined by Andrew Clark, Sophie Alpert, Dominic Gannaway, and other members of the React team.
","frontmatter":{"title":"Hooks FAQ","next":null,"prev":"hooks-reference.html"},"fields":{"path":"content/docs/hooks-faq.md","slug":"docs/hooks-faq.html"}}},"pageContext":{"slug":"docs/hooks-faq.html"}},"staticQueryHashes":[]}