![\"Lint](\"./exhaustive-deps.gif\")
shouldComponentUpdate?useCallback?Starting 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.
\nHooks offer a powerful and expressive new way to reuse functionality between components.\n“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.
\nWhen you’re ready, we’d encourage you to start trying Hooks in new components you write.\nYou can’t use Hooks inside of a class component, but you can definitely mix classes and function components with Hooks in a single tree.\nWhether a component is a class or a function that uses Hooks is an implementation detail of that component.\nIn 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.\nThere are no Hook equivalents to the uncommon getSnapshotBeforeUpdate and componentDidCatch lifecycles yet, but we plan to add them soon.
Often, render props and higher-order components render only a single child. We think Hooks are a simpler way to serve this use case.\nThere is still a place for both patterns (for example, a virtual scroller component might have a renderItem prop, or a visual container\ncomponent might have its own DOM structure). But in most cases, Hooks will be sufficient and can help reduce nesting in your tree.
We provide an ESLint plugin that\nenforces rules of Hooks to avoid bugs.\nIt assumes that any function starting with ”use” and a capital letter right after it is a Hook.\nWe recognize this heuristic isn’t perfect and there may be some false positives, but without an ecosystem-wide convention there is just no way\nto make Hooks work well — and longer names will discourage people from either adopting Hooks or following the convention.
\nIn particular, the rule enforces that:
\nPascalCase function (assumed to be a component) or\nanother useSomething function (assumed to be a custom Hook).constructor: Function components don’t need a constructor. You can initialize the state in\nthe useState call.\nIf computing the initial state is expensive, you can pass a function to useState.getDerivedStateFromProps: Schedule an update\nwhile rendering instead.shouldComponentUpdate: See React.memo below.render: This is the function component body itself.componentDidMount, componentDidUpdate, componentWillUnmount: The\nuseEffect Hook can express all combinations of these (including less common cases).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\nthis article about data fetching with Hooks.
\nIf you’re coming from classes, you might be tempted to always call useState() once and put all state into a single object.\nYou can do it if you’d like. Here is an example of a component that follows the mouse movement.\nWe 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\nto merge these fields into the previous state object manually:
\n // ...\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,\nwhich merges the updated fields into the object.
If you miss automatic merging, you can write a custom useLegacyState Hook that merges object state updates.\nHowever, instead 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\nno 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\ninto 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\ncustom 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\ntend to be most readable when you find a balance between these two extremes, and group related state into a few\nindependent 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 (Q-Is there something like instance variables?)\nto manually store a boolean value corresponding to whether you are on the first or a subsequent render, then check\nthat 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.
Any function inside a component, including event handlers and effects, “sees” the props and state from the render it was\ncreated 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\nclicked 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\ndidn’t correctly specify all the dependencies. For example, if an effect specifies [] as the second argument but reads\nsomeProp inside, it will keep “seeing” the initial value of someProp. The solution is to either remove the dependency\narray, or to fix it. Here’s how you can deal with functions, and here’s other common strategies to run effects less\noften without incorrectly skipping dependencies.
We provide an exhaustive-deps ESLint rule as a part of the\neslint-plugin-react-hooks package.\nIt warns when dependencies are specified incorrectly and suggests a fix.
\nSometimes, 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. let 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.
\nconst [state, setState] = useState(initialState);Returns a stateful value, and a function to update it.
\nDuring the initial render, the returned state (state) is the same as the value passed as the first argument (initialState).
The setState function is used to update the state. It accepts a new state value and enqueues a re-render of the component.
setState(newState);During subsequent re-renders, the first value returned by useState will always be the most recent state after applying updates.
\n\nNote
\nReact guarantees that
\nsetStatefunction identity is stable and won’t change on re-renders. This is why it’s safe to omit from theuseEffectoruseCallbackdependency list.
If the new state is computed using the previous state, you can pass a function to setState. The function will receive the previous value, and return an updated value. Here’s an example of a counter component that uses both forms of setState:
function Counter({initialCount}) {\n const [count, setCount] = useState(initialCount);\n return (\n <>\n Count: {count}\n <button onClick={() => setCount(initialCount)}>Reset</button>\n <button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>\n <button onClick={() => setCount(prevCount => prevCount - 1)}>-</button>\n </>\n );\n}The ”+” and ”-” buttons use the functional form, because the updated value is based on the previous value. But the “Reset” button uses the normal form, because it always sets the count back to the initial value.
\n\n\nNote
\nUnlike the
\nsetStatemethod found in class components,useStatedoes not automatically merge update objects. You can replicate this behavior by combining the function updater form with object spread syntax:\nsetState(prevState => {\n // Object.assign would also work\n return {...prevState, ...updatedValues};\n});Another option is
\nuseReducer, which is more suited for managing state objects that contain multiple sub-values.
The initialState argument is the state used during the initial render. In subsequent renders, it is disregarded. If the initial state is the result of an expensive computation, you may provide a function instead, which will be executed only on the initial render:
const [state, setState] = useState(() => {\n const initialState = someExpensiveComputation(props);\n return initialState;\n});If you update a State Hook to the same value as the current state, React will bail out without rendering the children or firing effects. (React uses the Object.is comparison algorithm.)
Note that React may still need to render that specific component again before bailing out. That shouldn’t be a concern because React won’t unnecessarily go “deeper” into the tree. If you’re doing expensive calculations while rendering, you can optimize them with useMemo.
useEffect(didUpdate);Accepts a function that contains imperative, possibly effectful code.
\nMutations, subscriptions, timers, logging, and other side effects are not allowed inside the main body of a function component (referred to as React’s render phase). Doing so will lead to confusing bugs and inconsistencies in the UI.
\nInstead, use useEffect. The function passed to useEffect will run after the render is committed to the screen. Think of effects as an escape hatch from React’s purely functional world into the imperative world.
By default, effects run after every completed render, but you can choose to fire it only when certain values have changed.
\nOften, effects create resources that need to be cleaned up before the component leaves the screen, such as a subscription or timer ID. To do this, the function passed to useEffect may return a clean-up function. For example, to create a subscription:
useEffect(() => {\n const subscription = props.source.subscribe();\n return () => {\n // Clean up the subscription\n subscription.unsubscribe();\n };\n});The clean-up function runs before the component is removed from the UI to prevent memory leaks. Additionally, if a component renders multiple times (as they typically do), the previous effect is cleaned up before executing the next effect. In our example, this means a new subscription is created on every update. To avoid firing an effect on every update, refer to the next section.
\nUnlike componentDidMount and componentDidUpdate, the function passed to useEffect fires after layout and paint, during a deferred event. This makes it suitable for the many common side effects, like setting up subscriptions and event handlers, because most types of work shouldn’t block the browser from updating the screen.
However, not all effects can be deferred. For example, a DOM mutation that is visible to the user must fire synchronously before the next paint so that the user does not perceive a visual inconsistency. (The distinction is conceptually similar to passive versus active event listeners.) For these types of effects, React provides one additional Hook called useLayoutEffect. It has the same signature as useEffect, and only differs in when it is fired.
Although useEffect is deferred until after the browser has painted, it’s guaranteed to fire before any new renders. React will always flush a previous render’s effects before starting a new update.
The default behavior for effects is to fire the effect after every completed render. That way an effect is always recreated if one of its dependencies changes.
\nHowever, this may be overkill in some cases, like the subscription example from the previous section. We don’t need to create a new subscription on every update, only if the source props has changed.
To implement this, pass a second argument to useEffect that is the array of values that the effect depends on. Our updated example now looks like this:
useEffect(\n () => {\n const subscription = props.source.subscribe();\n return () => {\n subscription.unsubscribe();\n };\n },\n [props.source],\n);Now the subscription will only be recreated when props.source changes.
\n\nNote
\nIf you use this optimization, make sure the array includes all values from the component scope (such as props and state) that change over time and that are used by the effect. Otherwise, your code will reference stale values from previous renders. Learn more about how to deal with functions and what to do when the array values change too often.
\nIf you want to run an effect and clean it up only once (on mount and unmount), you can pass an empty array (
\n[]) as a second argument. This tells React that your effect doesn’t depend on any values from props or state, so it never needs to re-run. This isn’t handled as a special case — it follows directly from how the dependencies array always works.If you pass an empty array (
\n[]), the props and state as inside the effect will always have their initial values. While passing[]as the second argument is closer to the familiarcomponentDidMountandcomponentWillUnmountmental model, there are usually better solutions to avoid re-running effects too often. Also, don’t forget that React defers runninguseEffectuntil after the browser has painted, so doing extra work is less of a problem.We recommend using the
\nexhaustive-depsrule as part of oureslint-plugin-react-hookspackage. It warns when dependencies are specified incorrectly and suggests a fix.
The array of dependencies is not passed as arguments to the effect function. Conceptually, though, that’s what they represent: every value referenced inside the effect function should also appear in the dependencies array. In the future, a sufficiently advanced compiler could create this array automatically.
\nReference - https://overreacted.io/a-complete-guide-to-useeffect/#moving-functions-inside-effects
\nA common mistake is to think functions shouldn’t be dependencies. For example, this seems like it could work:
\nfunction SearchResults() {\n const [data, setData] = useState({ hits: [] });\n\n async function fetchData() {\n const result = await axios(\n 'https://hn.algolia.com/api/v1/search?query=react',\n );\n setData(result.data);\n }\n\n useEffect(() => {\n fetchData();\n }, []); // Is this okay?\n // ...(This example is adapted from a great article by Robin Wieruch — check it out!)
\nAnd to be clear, this code does work. But the problem with simply omitting local functions is that it gets pretty hard to tell whether we’re handling all cases as the component grows!
\nImagine our code was split like this and each function was five times larger:
\nfunction SearchResults() {\n // Imagine this function is long\n function getFetchUrl() {\n return 'https://hn.algolia.com/api/v1/search?query=react';\n }\n\n // Imagine this function is also long\n async function fetchData() {\n const result = await axios(getFetchUrl());\n setData(result.data);\n }\n\n useEffect(() => {\n fetchData();\n }, []);\n\n // ...\n}Now let’s say we later use some state or prop in one of these functions:
\nfunction SearchResults() {\n const [query, setQuery] = useState('react');\n\n // Imagine this function is also long\n function getFetchUrl() {\n return 'https://hn.algolia.com/api/v1/search?query=' + query; }\n\n // Imagine this function is also long\n async function fetchData() {\n const result = await axios(getFetchUrl());\n setData(result.data);\n }\n\n useEffect(() => {\n fetchData();\n }, []);\n\n // ...\n}If we forget to update the deps of any effects that call these functions (possibly, through other functions!), our effects will fail to synchronize changes from our props and state. This doesn’t sound great.
\nLuckily, there is an easy solution to this problem. If you only use some functions inside an effect, move them directly into that effect:
\nfunction SearchResults() {\n // ...\n useEffect(() => {\n // We moved these functions inside! function getFetchUrl() { return 'https://hn.algolia.com/api/v1/search?query=react'; } async function fetchData() { const result = await axios(getFetchUrl()); setData(result.data); }\n fetchData();\n }, []); // ✅ Deps are OK\n // ...\n}So what is the benefit? We no longer have to think about the “transitive dependencies”. Our dependencies array isn’t lying anymore: we truly aren’t using anything from the outer scope of the component in our effect.
\nIf we later edit getFetchUrl to use the query state, we’re much more likely to notice that we’re editing it inside an effect — and therefore, we need to add query to the effect dependencies:
function SearchResults() {\n const [query, setQuery] = useState('react');\n\n useEffect(() => {\n function getFetchUrl() {\n return 'https://hn.algolia.com/api/v1/search?query=' + query; }\n\n async function fetchData() {\n const result = await axios(getFetchUrl());\n setData(result.data);\n }\n\n fetchData();\n }, [query]); // ✅ Deps are OK\n // ...\n}(Here’s a demo.)
\nBy adding this dependency, we’re not just “appeasing React”. It makes sense to refetch the data when the query changes. The design of useEffect forces you to notice the change in our data flow and choose how our effects should synchronize it — instead of ignoring it until our product users hit a bug.
Thanks to the exhaustive-deps lint rule from the eslint-plugin-react-hooks plugin, you can analyze the effects as you type in your editor and receive suggestions about which dependencies are missing. In other words, a machine can tell you which data flow changes aren’t handled correctly by a component.
Pretty sweet.
\nNote - This is a follow up question of “Q - If you only use some functions inside an effect, why you should move them directly into that effect?”
\nReference - https://overreacted.io/a-complete-guide-to-useeffect/#but-i-cant-put-this-function-inside-an-effect
\nSometimes you might not want to move a function inside an effect. For example, several effects in the same component may call the same function, and you don’t want to copy and paste its logic. Or maybe it’s a prop.
\nShould you skip a function like this in the effect dependencies? I think not. Again, effects shouldn’t lie about their dependencies. There are usually better solutions. A common misconception is that “a function would never change”. But as we learned throughout this article, this couldn’t be further from truth. Indeed, a function defined inside a component changes on every render!
\nThat by itself presents a problem. Say two effects call getFetchUrl:
function SearchResults() {\n function getFetchUrl(query) {\n return 'https://hn.algolia.com/api/v1/search?query=' + query;\n }\n\n useEffect(() => {\n const url = getFetchUrl('react');\n // ... Fetch data and do something ...\n }, []); // 🔴 Missing dep: getFetchUrl\n\n useEffect(() => {\n const url = getFetchUrl('redux');\n // ... Fetch data and do something ...\n }, []); // 🔴 Missing dep: getFetchUrl\n\n // ...\n}In that case you might not want to move getFetchUrl inside either of the effects since you wouldn’t be able to share the logic.
On the other hand, if you’re “honest” about the effect dependencies, you may run into a problem. Since both our effects depend on getFetchUrl (which is different on every render), our dependency arrays are useless:
function SearchResults() {\n // 🔴 Re-triggers all effects on every render function getFetchUrl(query) { return 'https://hn.algolia.com/api/v1/search?query=' + query; }\n useEffect(() => {\n const url = getFetchUrl('react');\n // ... Fetch data and do something ...\n }, [getFetchUrl]); // 🚧 Deps are correct but they change too often\n\n useEffect(() => {\n const url = getFetchUrl('redux');\n // ... Fetch data and do something ...\n }, [getFetchUrl]); // 🚧 Deps are correct but they change too often\n\n // ...\n}A tempting solution to this is to just skip the getFetchUrl function in the deps list. However, I don’t think it’s a good solution. This makes it difficult to notice when we are adding a change to the data flow that needs to be handled by an effect. This leads to bugs like the “never updating interval” we saw earlier.
Instead, there are two other solutions that are simpler.
\nFirst of all, if a function doesn’t use anything from the component scope, you can hoist it outside the component and then freely use it inside your effects:
\n// ✅ Not affected by the data flowfunction getFetchUrl(query) { return 'https://hn.algolia.com/api/v1/search?query=' + query;}\nfunction SearchResults() {\n useEffect(() => {\n const url = getFetchUrl('react');\n // ... Fetch data and do something ...\n }, []); // ✅ Deps are OK\n\n useEffect(() => {\n const url = getFetchUrl('redux');\n // ... Fetch data and do something ...\n }, []); // ✅ Deps are OK\n\n // ...\n}There’s no need to specify it in deps because it’s not in the render scope and can’t be affected by the data flow. It can’t accidentally depend on props or state.
\nAlternatively, you can wrap it into the useCallback Hook:
function SearchResults() {\n // ✅ Preserves identity when its own deps are the same const getFetchUrl = useCallback((query) => { return 'https://hn.algolia.com/api/v1/search?query=' + query; }, []); // ✅ Callback deps are OK\n useEffect(() => {\n const url = getFetchUrl('react');\n // ... Fetch data and do something ...\n }, [getFetchUrl]); // ✅ Effect deps are OK\n\n useEffect(() => {\n const url = getFetchUrl('redux');\n // ... Fetch data and do something ...\n }, [getFetchUrl]); // ✅ Effect deps are OK\n\n // ...\n}useCallback is essentially like adding another layer of dependency checks. It’s solving the problem on the other end — rather than avoid a function dependency, we make the function itself only change when necessary.
Let’s see why this approach is useful. Previously, our example showed two search results (for 'react' and 'redux' search queries). But let’s say we want to add an input so that you can search for an arbitrary query. So instead of taking query as an argument, getFetchUrl will now read it from local state.
We’ll immediately see that it’s missing a query dependency:
function SearchResults() {\n const [query, setQuery] = useState('react');\n const getFetchUrl = useCallback(() => { // No query argument\n return 'https://hn.algolia.com/api/v1/search?query=' + query;\n }, []); // 🔴 Missing dep: query // ...\n}If I fix my useCallback deps to include query, any effect with getFetchUrl in deps will re-run whenever the query changes:
function SearchResults() {\n const [query, setQuery] = useState('react');\n\n // ✅ Preserves identity until query changes const getFetchUrl = useCallback(() => { return 'https://hn.algolia.com/api/v1/search?query=' + query; }, [query]); // ✅ Callback deps are OK\n useEffect(() => {\n const url = getFetchUrl();\n // ... Fetch data and do something ...\n }, [getFetchUrl]); // ✅ Effect deps are OK\n\n // ...\n}Thanks to useCallback, if query is the same, getFetchUrl also stays the same, and our effect doesn’t re-run. But if query changes, getFetchUrl will also change, and we will re-fetch the data. It’s a lot like when you change some cell in an Excel spreadsheet, and the other cells using it recalculate automatically.
This is just a consequence of embracing the data flow and the synchronization mindset. The same solution works for function props passed from parents:
\nfunction Parent() {\n const [query, setQuery] = useState('react');\n\n // ✅ Preserves identity until query changes const fetchData = useCallback(() => { const url = 'https://hn.algolia.com/api/v1/search?query=' + query; // ... Fetch data and return it ... }, [query]); // ✅ Callback deps are OK\n return <Child fetchData={fetchData} />\n}\n\nfunction Child({ fetchData }) {\n let [data, setData] = useState(null);\n\n useEffect(() => {\n fetchData().then(setData);\n }, [fetchData]); // ✅ Effect deps are OK\n\n // ...\n}Since fetchData only changes inside Parent when its query state changes, our Child won’t refetch the data until it’s actually necessary for the app.
\n\nNote
\nThis is another explanations for the same questions of ‘Q - If you only use some functions inside an effect, why you should move them directly into that effect?’ and\n‘Q - What are the solutions, if you can’t put a function inside an effect?’
\nReference - https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-functions-from-the-list-of-dependencies
\n
Generally 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, useMemo, useCallback, or useImperativeHandle, it must include all values used inside that 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.
const value = useContext(MyContext);Accepts a context object (the value returned from React.createContext) and returns the current context value for that context. The current context value is determined by the value prop of the nearest <MyContext.Provider> above the calling component in the tree.
When the nearest <MyContext.Provider> above the component updates, this Hook will trigger a rerender with the latest context value passed to that MyContext provider.
Don’t forget that the argument to useContext must be the context object itself:
useContext(MyContext)useContext(MyContext.Consumer)useContext(MyContext.Provider)A component calling useContext will always re-render when the context value changes. If re-rendering the component is expensive, you can optimize it by using memoization.
\n\nTip
\nIf you’re familiar with the context API before Hooks,
\nuseContext(MyContext)is equivalent tostatic contextType = MyContextin a class, or to<MyContext.Consumer>.\n
useContext(MyContext)only lets you read the context and subscribe to its changes. You still need a<MyContext.Provider>above in the tree to provide the value for this context.
const [state, dispatch] = useReducer(reducer, initialArg, init);An alternative to useState. Accepts a reducer of type (state, action) => newState, and returns the current state paired with a dispatch method. (If you’re familiar with Redux, you already know how this works.)
useReducer is usually preferable to useState when you have complex state logic that involves multiple sub-values or when the next state depends on the previous one. useReducer also lets you optimize performance for components that trigger deep updates because you can pass dispatch down instead of callbacks.
Here’s the counter example from the useState section, rewritten to use a reducer:
const initialState = {count: 0};\n\nfunction reducer(state, action) {\n switch (action.type) {\n case 'increment':\n return {count: state.count + 1};\n case 'decrement':\n return {count: state.count - 1};\n default:\n throw new Error();\n }\n}\n\nfunction Counter() {\n const [state, dispatch] = useReducer(reducer, initialState);\n return (\n <>\n Count: {state.count}\n <button onClick={() => dispatch({type: 'increment'})}>+</button>\n <button onClick={() => dispatch({type: 'decrement'})}>-</button>\n </>\n );\n}\n\nNote
\nReact guarantees that
\ndispatchfunction identity is stable and won’t change on re-renders. This is why it’s safe to omit from theuseEffectoruseCallbackdependency list.
There are two different ways to initialize useReducer state. You may choose either one depending on the use case. The simplest way is to pass the initial state as a second argument:
const [state, dispatch] = useReducer(\n reducer,\n {count: initialCount} );\n\nNote
\nReact doesn’t use the
\nstate = initialStateargument convention popularized by Redux. The initial value sometimes needs to depend on props and so is specified from the Hook call instead. If you feel strongly about this, you can calluseReducer(reducer, undefined, reducer)to emulate the Redux behavior, but it’s not encouraged.
You can also create the initial state lazily. To do this, you can pass an init function as the third argument. The initial state will be set to init(initialArg).
It lets you extract the logic for calculating the initial state outside the reducer. This is also handy for resetting the state later in response to an action:
\nfunction init(initialCount) { return {count: initialCount};}\nfunction reducer(state, action) {\n switch (action.type) {\n case 'increment':\n return {count: state.count + 1};\n case 'decrement':\n return {count: state.count - 1};\n case 'reset': return init(action.payload); default:\n throw new Error();\n }\n}\n\nfunction Counter({initialCount}) {\n const [state, dispatch] = useReducer(reducer, initialCount, init); return (\n <>\n Count: {state.count}\n <button\n onClick={() => dispatch({type: 'reset', payload: initialCount})}> Reset\n </button>\n <button onClick={() => dispatch({type: 'increment'})}>+</button>\n <button onClick={() => dispatch({type: 'decrement'})}>-</button>\n </>\n );\n}If you return the same value from a Reducer Hook as the current state, React will bail out without rendering the children or firing effects. (React uses the Object.is comparison algorithm.)
Note that React may still need to render that specific component again before bailing out. That shouldn’t be a concern because React won’t unnecessarily go “deeper” into the tree. If you’re doing expensive calculations while rendering, you can optimize them with useMemo.
const memoizedCallback = useCallback(\n () => {\n doSomething(a, b);\n },\n [a, b],\n);Returns a memoized callback.
\nPass an inline callback and an array of dependencies. useCallback will return a memoized version of the callback that only changes if one of the dependencies has changed. This is useful when passing callbacks to optimized child components that rely on reference equality to prevent unnecessary renders (e.g. shouldComponentUpdate).
useCallback(fn, deps) is equivalent to useMemo(() => fn, deps).
\n\nNote
\nThe array of dependencies is not passed as arguments to the callback. Conceptually, though, that’s what they represent: every value referenced inside the callback should also appear in the dependencies array. In the future, a sufficiently advanced compiler could create this array automatically.
\nWe recommend using the
\nexhaustive-depsrule as part of oureslint-plugin-react-hookspackage. It warns when dependencies are specified incorrectly and suggests a fix.
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);Returns a memoized value.
\nPass a “create” function and an array of dependencies. useMemo will only recompute the memoized value when one of the dependencies has changed. This optimization helps to avoid expensive calculations on every render.
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.
If no array is provided, a new value will be computed on every render.
\nYou 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.
\n\nNote
\nThe array of dependencies is not passed as arguments to the function. Conceptually, though, that’s what they represent: every value referenced inside the function should also appear in the dependencies array. In the future, a sufficiently advanced compiler could create this array automatically.
\nWe recommend using the
\nexhaustive-depsrule as part of oureslint-plugin-react-hookspackage. It warns when dependencies are specified incorrectly and suggests a fix.
const refContainer = useRef(initialValue);useRef returns a mutable ref object whose .current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.
A common use case is to access a child imperatively:
\nfunction TextInputWithFocusButton() {\n const inputEl = useRef(null);\n const onButtonClick = () => {\n // `current` points to the mounted text input element\n inputEl.current.focus();\n };\n return (\n <>\n <input ref={inputEl} type=\"text\" />\n <button onClick={onButtonClick}>Focus the input</button>\n </>\n );\n}Essentially, useRef is like a “box” that can hold a mutable value in its .current property.
You might be familiar with refs primarily as a way to access the DOM. If you pass a ref object to React with <div ref={myRef} />, React will set its .current property to the corresponding DOM node whenever that node changes.
However, useRef() is useful for more than the ref attribute. It’s handy for keeping any mutable value around similar to how you’d use instance fields in classes.
This works because useRef() creates a plain JavaScript object. The only difference between useRef() and creating a {current: ...} object yourself is that useRef will give you the same ref object on every render.
Keep in mind that useRef doesn’t notify you when its content changes. Mutating the .current property doesn’t cause a re-render. If you want to run some code when React attaches or detaches a ref to a DOM node, you may want to use a callback ref instead.
Yes! The useRef() Hook isn’t just for DOM refs.\nThe “ref” object is a generic container whose current property is\nmutable 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\nwe want to clear the interval from an event handler:
// ...\nfunction handleCancelClick() {\n clearInterval(intervalRef.current);}\n// ...Conceptually, you can think of refs as similar to instance variables in a class. Unless you’re doing\nlazy initialization,\navoid setting refs during rendering — this can lead to surprising behavior. Instead, typically you want to modify refs\nin event handlers and effects.
\nIn order to measure the position or size of a DOM node, you can 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.
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}useImperativeHandle(ref, createHandle, [deps])useImperativeHandle customizes the instance value that is exposed to parent components when using ref. As always, imperative code using refs should be avoided in most cases. useImperativeHandle should be used with forwardRef:
function FancyInput(props, ref) {\n const inputRef = useRef();\n useImperativeHandle(ref, () => ({\n focus: () => {\n inputRef.current.focus();\n }\n }));\n return <input ref={inputRef} ... />;\n}\nFancyInput = forwardRef(FancyInput);In this example, a parent component that renders <FancyInput ref={fancyInputRef} /> would be able to call fancyInputRef.current.focus().
useDeferredValue accepts a value and returns a new copy of the value that will defer to more urgent updates. If the current render is the result of an urgent update, like user input, React will return the previous value and then render the new value after the urgent render has completed.useDeferredValue is that React will work on the update as soon as other work finishes (instead of waiting for an arbitrary amount of time), and like startTransition, deferred values can suspend without triggering an unexpected fallback for existing content.useDeferredValue is mainly useful when the value comes from above and you don’t actually have control over the corresponding setState call that is related to the laggish behaviour. If we do have control over it, using startTransition and the useTransition Hook in general is preferable as it’s seems.const deferredValue = useDeferredValue(value);useDeferredValue only defers the value that you pass to it. If you want to prevent a child component from re-rendering during an urgent update, you must also memoize that component with React.memo or React.useMemo:function Typeahead() {\n const query = useSearchQuery('');\n const deferredQuery = useDeferredValue(query);\n\n // Memoizing tells React to only re-render when deferredQuery changes,\n // not when query changes.\n const suggestions = useMemo(() =>\n <SearchSuggestions query={deferredQuery} />,\n [deferredQuery]\n );\n\n return (\n <>\n <SearchInput query={query} />\n <Suspense fallback=\"Loading results...\">\n {suggestions}\n </Suspense>\n </>\n );\n}Starting 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.
\nHooks offer a powerful and expressive new way to reuse functionality between components.\n“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.
\nWhen you’re ready, we’d encourage you to start trying Hooks in new components you write.\nYou can’t use Hooks inside of a class component, but you can definitely mix classes and function components with Hooks in a single tree.\nWhether a component is a class or a function that uses Hooks is an implementation detail of that component.\nIn 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.\nThere are no Hook equivalents to the uncommon getSnapshotBeforeUpdate and componentDidCatch lifecycles yet, but we plan to add them soon.
Often, render props and higher-order components render only a single child. We think Hooks are a simpler way to serve this use case.\nThere is still a place for both patterns (for example, a virtual scroller component might have a renderItem prop, or a visual container\ncomponent might have its own DOM structure). But in most cases, Hooks will be sufficient and can help reduce nesting in your tree.
We provide an ESLint plugin that\nenforces rules of Hooks to avoid bugs.\nIt assumes that any function starting with ”use” and a capital letter right after it is a Hook.\nWe recognize this heuristic isn’t perfect and there may be some false positives, but without an ecosystem-wide convention there is just no way\nto make Hooks work well — and longer names will discourage people from either adopting Hooks or following the convention.
\nIn particular, the rule enforces that:
\nPascalCase function (assumed to be a component) or\nanother useSomething function (assumed to be a custom Hook).constructor: Function components don’t need a constructor. You can initialize the state in\nthe useState call.\nIf computing the initial state is expensive, you can pass a function to useState.getDerivedStateFromProps: Schedule an update\nwhile rendering instead.shouldComponentUpdate: See React.memo below.render: This is the function component body itself.componentDidMount, componentDidUpdate, componentWillUnmount: The\nuseEffect Hook can express all combinations of these (including less common cases).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\nthis article about data fetching with Hooks.
\nIf you’re coming from classes, you might be tempted to always call useState() once and put all state into a single object.\nYou can do it if you’d like. Here is an example of a component that follows the mouse movement.\nWe 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\nto merge these fields into the previous state object manually:
\n // ...\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,\nwhich merges the updated fields into the object.
If you miss automatic merging, you can write a custom useLegacyState Hook that merges object state updates.\nHowever, instead 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\nno 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\ninto 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\ncustom 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\ntend to be most readable when you find a balance between these two extremes, and group related state into a few\nindependent 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 (Q-Is there something like instance variables?)\nto manually store a boolean value corresponding to whether you are on the first or a subsequent render, then check\nthat 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.
Any function inside a component, including event handlers and effects, “sees” the props and state from the render it was\ncreated 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\nclicked 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\ndidn’t correctly specify all the dependencies. For example, if an effect specifies [] as the second argument but reads\nsomeProp inside, it will keep “seeing” the initial value of someProp. The solution is to either remove the dependency\narray, or to fix it. Here’s how you can deal with functions, and here’s other common strategies to run effects less\noften without incorrectly skipping dependencies.
We provide an exhaustive-deps ESLint rule as a part of the\neslint-plugin-react-hooks package.\nIt warns when dependencies are specified incorrectly and suggests a fix.
\nSometimes, 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.