# Four More Important React Hooks 🪝 By now, you've worked with some of [React](/courses/reactjs)'s most important tools: - [useState](https://asif.to/reactjs/chapter-4-state-usestate-hook) - [useEffect](https://asif.to/reactjs/chapter-7-useeffect-hook) - [useContext](https://asif.to/reactjs/chapter-10-context-api-global-state) Those [Hooks](/courses/reactjs/chapter-11-advanced-hooks-useref-usereducer-usememo-usecallback) cover a huge amount of everyday [React](/courses/reactjs) development. But as applications become more complex, you'll eventually run into situations where `useState()` alone isn't quite the right tool. Maybe you need to access an actual DOM element. Maybe you need to remember a value without causing another render. Maybe your state has become a mess of five different update [functions](/javascript/functions-in-javascript). Maybe a calculation is genuinely expensive and running far more often than necessary. Or maybe you're optimizing a component and need a [function](/javascript/functions-in-javascript) reference to remain stable between renders. React provides [Hooks](/courses/reactjs/chapter-11-advanced-hooks-useref-usereducer-usememo-usecallback) for those situations: - `useRef()` - `useReducer()` - `useMemo()` - `useCallback()` These Hooks are slightly more advanced than `useState`, but don't let the names scare you. The ideas behind them are actually quite reasonable once you understand **what problem each Hook is trying to solve**. We'll eventually cover each of these Hooks in its own dedicated article, but this chapter will give you enough understanding to use them properly without copying mysterious code from Stack Overflow and hoping for spiritual guidance. 😌 --- # 1. `useRef` — Remember Something Without Re-Rendering 📌 Let's begin with `useRef`. `useRef` allows a component to keep a value between renders **without causing another render when that value changes**. That immediately makes it different from state. Consider: ```jsx const [count, setCount] = useState(0) ``` When you call: ```jsx setCount(1) ``` React schedules another render because state changed. But with a ref: ```jsx const countRef = useRef(0) ``` you can change: ```jsx countRef.current = 1 ``` and React does **not** re-render the component just because the ref changed. That makes refs useful for information the component needs to remember, but that doesn't directly control what should appear on the screen. --- # What Does `useRef()` Return? Let's create one: ```jsx import { useRef } from "react" function Example() { const myRef = useRef(0) console.log(myRef) return

Hello

} ``` Conceptually, `myRef` looks like: ```js { current: 0 } ``` The important property is: ```jsx myRef.current ``` The value you pass to `useRef()` becomes its initial `current` value: ```jsx const myRef = useRef(0) ``` means: ```text myRef.current = 0 ``` If you later write: ```jsx myRef.current = 100 ``` the ref remembers: ```text 100 ``` across future renders. But React does not re-render merely because `.current` changed. --- # State vs Ref This distinction is extremely important. State is for information that affects the UI. ```jsx const [count, setCount] = useState(0) ``` If the screen displays: ```jsx

Count: {count}

``` then changing `count` should cause another render. That's exactly what state does. A ref is different: ```jsx const countRef = useRef(0) ``` If you write: ```jsx countRef.current++ ``` React does not automatically render again. So think: ```text STATE 🧠 Value changes ↓ React re-renders ↓ UI can update ``` while: ```text REF 📌 .current changes ↓ React remembers it ↓ No re-render caused by that change ``` A useful question is: > **Does changing this value need to update what the user sees immediately?** If yes, you probably want state. If no, a ref may be appropriate. --- # The Two Most Common Uses of `useRef` You'll usually encounter refs for two reasons: ```text 1. Accessing a DOM element 2. Remembering a non-visual value between renders ``` Let's look at both. --- # Use Case 1: Accessing a DOM Element Normally, React manages DOM elements for you. You write: ```jsx ``` and React creates and manages the actual browser DOM [node](/courses/nodejs). Most of the time, that's exactly what you want. But occasionally you need direct access to the real DOM element. For example, maybe you want to: * focus an input * scroll an element into view * play or pause a video * measure an element * integrate with a third-party DOM library This is one of the main uses of refs. --- # Focusing an Input Here's a useful example: ```jsx import { useRef } from "react" function SearchBox() { const inputRef = useRef(null) function focusInput() { inputRef.current.focus() } return (

) } ``` We start with: ```jsx const inputRef = useRef(null) ``` Initially: ```text inputRef.current = null ``` because the input DOM element doesn't exist yet. Then we connect the ref to the input: ```jsx ``` After React creates that input in the DOM, React places the actual element into: ```jsx inputRef.current ``` So now it refers to the real browser input. That's why this works: ```jsx inputRef.current.focus() ``` We're calling the browser's normal `.focus()` method directly on the input element. --- # Ref Flow for DOM Elements You can picture it like this: ```text const inputRef = useRef(null) │ │ ▼ │ │ React creates DOM node ▼ inputRef.current │ ▼ Actual DOM element ``` Then: ```jsx inputRef.current.focus() ``` means: > "Find that actual input element and focus it." --- # Auto-Focusing an Input Maybe you want the input focused as soon as a page or modal appears. You can combine `useRef` with an Effect: ```jsx import { useEffect, useRef } from "react" function AutoFocusInput() { const inputRef = useRef(null) useEffect(() => { inputRef.current?.focus() }, []) return ( ) } ``` Notice: ```jsx inputRef.current?.focus() ``` The optional chaining: ```text ?. ``` means: > "Call `.focus()` only if `current` actually contains something." By the time the Effect runs after the component has been committed, React should have attached the DOM [node](/courses/nodejs) to the ref. --- # Another Useful Example: Scrolling to Content Refs can also help with scrolling. ```jsx import { useRef } from "react" function Article() { const commentsRef = useRef(null) function goToComments() { commentsRef.current?.scrollIntoView({ behavior: "smooth" }) } return (

Article content...

Comments

) } ``` The ref gives us access to the comments section, and: ```jsx scrollIntoView() ``` uses the browser's DOM API to scroll there. That's a practical example of why React sometimes needs to give us a controlled escape hatch into the DOM. --- # Use Case 2: Storing Values That Don't Affect Rendering Refs are also useful when you need to remember information but don't need that information itself displayed. A classic example is an interval ID. When you call: ```jsx setInterval(...) ``` the browser gives you an identifier. You need to remember that identifier so you can later call: ```jsx clearInterval(...) ``` But the interval ID doesn't belong on the screen. Nobody needs: ```text Current interval ID: 483 ``` in your beautiful stopwatch UI. 😂 So a ref is perfect. --- # A Better Stopwatch Example ```jsx import { useRef, useState } from "react" function Stopwatch() { const [seconds, setSeconds] = useState(0) const [running, setRunning] = useState(false) const intervalRef = useRef(null) function start() { if (intervalRef.current !== null) { return } setRunning(true) intervalRef.current = setInterval(() => { setSeconds(previous => previous + 1 ) }, 1000) } function stop() { if (intervalRef.current === null) { return } clearInterval( intervalRef.current ) intervalRef.current = null setRunning(false) } function reset() { stop() setSeconds(0) } return (

Time: {seconds}s

) } ``` Here: ```jsx seconds ``` belongs in state because the screen displays it. But: ```jsx intervalRef.current ``` doesn't need to appear anywhere. We just need to remember it so we can stop the timer. Perfect job for a ref. --- # Why Not Store the Interval ID in State? Technically, you could. But then every time the interval ID changes, you'd request another render even though that value doesn't affect the visual UI. That would be unnecessary. This is a good example of choosing state based on whether something affects rendering. ```text seconds ↓ Displayed on screen ↓ STATE ``` ```text interval ID ↓ Needed internally only ↓ REF ``` --- # Refs Are Mutable Unlike state, you directly modify a ref: ```jsx intervalRef.current = intervalId ``` That's completely normal. Compare: ```text STATE ❌ count = 5 ✅ setCount(5) ``` with: ```text REF ✅ countRef.current = 5 ``` Refs are intentionally mutable. However, don't start replacing all state with refs just because direct assignment feels convenient. React can't know that your UI should update when you change `.current`. If the value affects rendering, state is still the right tool. --- # When to Use `useRef` Good examples include: ```text DOM element reference Interval ID Timeout ID Previous value Third-party library instance WebSocket-like connection reference Mutable internal tracking value ``` But if you find yourself writing: ```jsx const nameRef = useRef("Alice") return (

{nameRef.current}

) ``` and then expecting: ```jsx nameRef.current = "Bob" ``` to update the heading... that's where you've taken a wrong turn. If the UI should react to the value, use state. --- # `useRef` Mental Model 📌 Think of a ref as a little persistent box: ```text ref ┌─────────┐ │ current │ │ │ │ 42 │ └─────────┘ ``` React gives you the same box across renders. You can change what is inside: ```jsx ref.current = 100 ``` without asking React to render again. So: > **State is reactive memory. A ref is non-rendering memory.** That's a useful beginner mental model. --- # 2. `useReducer` — Organizing Complex State Logic ⚙️ Now let's move to `useReducer`. `useReducer` solves a very different problem. Imagine a component with: ```jsx const [items, setItems] = useState([]) const [coupon, setCoupon] = useState(null) const [shipping, setShipping] = useState("standard") const [status, setStatus] = useState("idle") ``` Then you have: ```text addItem() removeItem() changeQuantity() applyCoupon() removeCoupon() changeShipping() clearCart() ``` Eventually your component starts looking like it has taken on a second job as an accounting department. 😭 This is where `useReducer` can become useful. --- # What Is `useReducer`? `useReducer` is another way to manage state. Instead of directly saying: ```jsx setCount(count + 1) ``` you send an **action** describing what happened: ```jsx dispatch({ type: "increment" }) ``` A reducer function receives that action, looks at the current state, and calculates the next state. The flow is: ```text User does something ↓ dispatch(action) ↓ Reducer receives: current state + action ↓ Reducer calculates next state ↓ React stores it ↓ UI updates ``` --- # Basic `useReducer` Syntax ```jsx import { useReducer } from "react" function reducer(state, action) { // calculate next state } function App() { const [state, dispatch] = useReducer( reducer, initialState ) } ``` `useReducer()` gives us two things: ```jsx state ``` and: ```jsx dispatch ``` This should remind you of: ```jsx const [count, setCount] = useState(0) ``` The difference is how we request state changes. With `useState`: ```jsx setCount(5) ``` With `useReducer`: ```jsx dispatch({ type: "something_happened" }) ``` --- # What Is a Reducer? A reducer is a normal [JavaScript](/courses/javascript) function. It usually looks like: ```jsx function reducer(state, action) { switch (action.type) { case "increment": return { ...state, count: state.count + 1 } default: return state } } ``` It receives: ```text state ``` which is the current state, and: ```text action ``` which describes what happened. Then it returns the **next state**. --- # What Is an Action? An action is usually a normal [JavaScript](/courses/javascript) object. For example: ```jsx { type: "increment" } ``` or: ```jsx { type: "add_item", product: product } ``` or: ```jsx { type: "change_quantity", productId: 42, quantity: 3 } ``` The `type` tells the reducer what happened. Other properties provide any information required to calculate the next state. So rather than saying: > "Set the state to exactly this object." you can say: > "The user added this product." and let the reducer decide what the next state should become. --- # A Simple Counter Reducer Let's begin with something small. ```jsx import { useReducer } from "react" const initialState = { count: 0 } function counterReducer( state, action ) { switch (action.type) { case "increment": return { ...state, count: state.count + 1 } case "decrement": return { ...state, count: state.count - 1 } case "reset": return initialState default: throw new Error( `Unknown action: ${action.type}` ) } } function Counter() { const [state, dispatch] = useReducer( counterReducer, initialState ) return (

Count: {state.count}

) } ``` For a counter, this is arguably more code than `useState`. And that's okay. You don't use `useReducer` because it looks more advanced. Use it when it makes complicated update logic easier to organize. --- # Following an Action Through the Reducer Suppose: ```text state.count = 5 ``` The user clicks `+1`. We dispatch: ```jsx dispatch({ type: "increment" }) ``` React passes: ```text state = { count: 5 } action = { type: "increment" } ``` to the reducer. The matching case runs: ```jsx case "increment": return { ...state, count: state.count + 1 } ``` The reducer returns: ```js { count: 6 } ``` React stores that as the next state and renders again. --- # Reducers Must Be Pure A reducer should calculate state without mutating the existing state. Wrong: ```jsx case "increment": state.count++ return state ``` We're modifying the original object. Instead: ```jsx case "increment": return { ...state, count: state.count + 1 } ``` Same rule you learned with React state: > Don't mutate existing state. Create the next state. --- # A More Useful Example: Shopping Cart 🛒 A shopping cart is a better demonstration of `useReducer` because several different actions can affect the same state. Let's create: ```jsx const initialCart = { items: [] } ``` Notice that we are **not storing `total` separately**. Why? Because total can be calculated from the items. Keeping both: ```text items total ``` in state creates two pieces of data that must always stay synchronized. If they ever disagree, congratulations: your shopping cart has invented accounting fraud. 😭 Instead, store the source data and derive the total later. --- # Shopping Cart Reducer ```jsx function cartReducer( state, action ) { switch (action.type) { case "add_item": { return { ...state, items: [ ...state.items, action.product ] } } case "remove_item": { return { ...state, items: state.items.filter( item => item.id !== action.productId ) } } case "clear_cart": { return { ...state, items: [] } } default: { throw new Error( `Unknown action: ${action.type}` ) } } } ``` Now the cart has one centralized place describing how each action changes state. --- # Using the Cart Reducer ```jsx import { useReducer } from "react" const initialCart = { items: [] } function cartReducer( state, action ) { switch (action.type) { case "add_item": return { ...state, items: [ ...state.items, action.product ] } case "remove_item": return { ...state, items: state.items.filter( item => item.id !== action.productId ) } case "clear_cart": return { ...state, items: [] } default: throw new Error( `Unknown action: ${action.type}` ) } } function ShoppingCart() { const [cart, dispatch] = useReducer( cartReducer, initialCart ) const total = cart.items.reduce( (sum, item) => sum + item.price, 0 ) function addWidget() { dispatch({ type: "add_item", product: { id: crypto.randomUUID(), name: "Widget", price: 9.99 } }) } function removeItem(id) { dispatch({ type: "remove_item", productId: id }) } return (

Cart ({cart.items.length})

Total: ${total.toFixed(2)}

{cart.items.length === 0 ? (

Your cart is empty.

) : ( cart.items.map(item => (

{item.name} {" — "} ${item.price}

)) )}

) } ``` Now the component mostly describes **what happened**: ```jsx dispatch({ type: "remove_item", productId: id }) ``` while the reducer contains the rules for **how state changes**. --- # Why `useReducer` Can Be Easier to Manage Without a reducer, complicated state logic can become spread across many handlers: ```text handleAdd() handleRemove() handleQuantity() handleClear() handleDiscount() handleShipping() ``` Each function directly manipulates state. With a reducer: ```text Event handler ↓ dispatch action ↓ Reducer ↓ All update rules in one place ``` That makes reducers especially useful when: * several state fields change together * many different actions update the same state * update rules are becoming complicated * you want state transitions to be easier to test * you want event handlers to describe what happened instead of containing all update logic --- # `useState` or `useReducer`? Don't think: ```text Beginner → useState Professional → useReducer ``` That's nonsense. Experienced React developers use `useState` constantly. Use `useState` when the update logic is simple: ```jsx const [isOpen, setIsOpen] = useState(false) ``` Use `useReducer` when managing related transitions becomes clearer with actions: ```jsx dispatch({ type: "submitted_form" }) ``` A useful guideline is: ```text Simple state ↓ useState Many related transitions or complicated update logic ↓ consider useReducer ``` --- # `useReducer` Mental Model ⚙️ Think of the reducer as a state update machine: ```text Current state + Action describing what happened ↓ Reducer ↓ Next state ``` For example: ```text Current cart + "remove product 42" ↓ cartReducer() ↓ New cart ``` That's the heart of `useReducer`. --- # 3. `useMemo` — Caching a Calculation 🧮 Now we move into performance-related Hooks. This is where developers occasionally discover `useMemo` and immediately start wrapping everything with it like they're bubble-wrapping furniture before moving house. Please don't. 😂 First understand the problem. --- # Components Run Again When They Render Suppose: ```jsx function ProductList({ products, category }) { const visibleProducts = products.filter( product => product.category === category ) return (

{product.name}

) } ``` Whenever `ProductList` renders, this calculation runs again: ```jsx products.filter(...) ``` Usually, that's perfectly fine. JavaScript filtering a small list is generally not something to panic about. React rendering code is expected to perform calculations. But imagine the calculation is genuinely expensive. Maybe you have thousands of records and you're performing filtering, sorting, grouping, scoring, or another expensive transformation. If the component renders because of something unrelated, recalculating that result may be unnecessary. That's where `useMemo` can help. --- # What Does `useMemo` Do? `useMemo` caches the **result of a calculation** between renders. Basic syntax: ```jsx const value = useMemo( () => { return calculateSomething() }, [dependencies] ) ``` React calculates the value during the initial render. On later renders, if the dependencies haven't changed, React can reuse the previously cached result. If a dependency changes, React calculates the value again. --- # A More Realistic Product Catalog Imagine: ```jsx function ProductCatalog({ products, search, category }) { // ... } ``` We need to: 1. filter by category 2. search by name 3. sort by price With a large catalog, this transformation may become meaningful. ```jsx function getVisibleProducts( products, search, category ) { return products .filter(product => { const matchesCategory = category === "all" || product.category === category const matchesSearch = product.name .toLowerCase() .includes( search.toLowerCase() ) return ( matchesCategory && matchesSearch ) }) .sort( (a, b) => a.price - b.price ) } ``` Now use it: ```jsx import { useMemo, useState } from "react" function ProductCatalog({ products, search, category }) { const [showDetails, setShowDetails] = useState(false) const visibleProducts = useMemo(() => { return getVisibleProducts( products, search, category ) }, [ products, search, category ]) return (

{showDetails && (

Showing{" "} {visibleProducts.length}{" "} products.

)}

{product.name} {" — "} ${product.price}

) } ``` If: ```jsx showDetails ``` changes, the component renders again. But: ```text products search category ``` haven't changed. So React can reuse the previously memoized `visibleProducts` instead of recalculating the product transformation. --- # Understanding the Dependency Array This: ```jsx [ products, search, category ] ``` means that the calculation depends on those values. If: ```text search changes ``` recalculate. If: ```text category changes ``` recalculate. If: ```text products changes ``` recalculate. If only: ```text showDetails changes ``` there is no reason to recalculate this particular value. That's the purpose of memoization. --- # `useMemo` Caches the Result This distinction will matter when we compare it with `useCallback`. Suppose: ```jsx const total = useMemo(() => { return calculateTotal(items) }, [items]) ``` `useMemo` caches: ```text THE RESULT ``` of: ```jsx calculateTotal(items) ``` If that result was: ```text 249.95 ``` then React may reuse: ```text 249.95 ``` until `items` changes. So: ```text useMemo ↓ runs calculation ↓ caches returned VALUE ``` --- # Should Every Calculation Use `useMemo`? Definitely not. This: ```jsx const fullName = firstName + " " + lastName ``` does not need: ```jsx const fullName = useMemo( () => firstName + " " + lastName, [firstName, lastName] ) ``` The second version is harder to read and probably provides no meaningful benefit. Likewise: ```jsx const doubled = number * 2 ``` does not need optimization. The calculation is trivial. --- # When Is `useMemo` Actually Useful? Traditionally, `useMemo` has been most useful when: ### A calculation is genuinely expensive For example: ```text large filtering operation complex sorting data transformation heavy mathematical calculation large derived structure ``` ### You need a stable object or array reference Sometimes a memoized object is passed to an optimized component or used as a dependency elsewhere. For example: ```jsx const options = useMemo( () => ({ sort, category }), [sort, category] ) ``` Because creating: ```jsx { sort, category } ``` normally produces a new object every render. But don't reach for this automatically either. It should solve an actual identity/performance problem. --- # `useMemo` Is a Performance Optimization This is perhaps the most important thing to remember. Your application should still work correctly if a memoized calculation runs again. Don't use `useMemo` as if it were permanent storage. If you need to remember information as part of your application's actual behavior, state or refs may be more appropriate. Think: ```text useMemo ↓ "Recalculating this may be wasteful." ``` not: ```text useMemo ↓ "I need React to permanently store this." ``` --- # 4. `useCallback` — Caching a Function Reference 📞 `useCallback` is closely related to `useMemo`, but it caches something different. It caches a **function definition/reference** between renders. Consider: ```jsx function Parent() { const handleSave = () => { console.log("Saved!") } return ( ) } ``` Whenever `Parent` renders, JavaScript creates a new function: ```jsx () => { console.log("Saved!") } ``` Even though the code looks identical, the function object itself is new. Conceptually: ```text Render 1 handleSave → Function A Render 2 handleSave → Function B Render 3 handleSave → Function C ``` That usually isn't a problem. Creating functions during rendering is normal JavaScript and normal React. But function identity can matter in certain performance-sensitive situations. --- # Basic `useCallback` Syntax ```jsx const handleSave = useCallback(() => { console.log("Saved!") }, []) ``` Now React can return the same function reference while the dependencies remain unchanged. Conceptually: ```text Render 1 handleSave → Function A Render 2 handleSave → Function A Render 3 handleSave → Function A ``` If one of its dependencies changes, React returns the new function supplied during that render. --- # `useCallback` Does NOT Automatically Prevent Re-Renders This is a very important correction to many beginner tutorials. Consider: ```jsx const handleClick = useCallback(() => { console.log("Clicked") }, []) return ( ) ``` Using `useCallback` does **not automatically mean**: ```text HeavyChild will never re-render ``` If the parent renders normally, child components normally render too. A stable callback becomes particularly useful when the receiving child is being memoized or when function identity matters for another reason. For example: ```jsx import { memo, useCallback, useState } from "react" const HeavyChild = memo( function HeavyChild({ onSave }) { console.log( "HeavyChild rendered" ) return ( ) } ) function Parent() { const [count, setCount] = useState(0) const handleSave = useCallback(() => { console.log( "Saving document..." ) }, []) return (

Count: {count}

) } ``` Now the relationship makes more sense. --- # Why Function Identity Matters Here `memo()` tells React that the child can skip a render when its props haven't changed. Imagine we don't use `useCallback`: ```jsx function Parent() { const handleSave = () => { console.log("Saving") } return ( ) } ``` Every parent render creates a new function. So from the child comparison's perspective: ```text Previous onSave: Function A New onSave: Function B ``` Those are different references. Even though they do the same thing. So the memoized child sees a changed prop. With: ```jsx const handleSave = useCallback(() => { console.log("Saving") }, []) ``` the reference can remain stable: ```text Previous onSave: Function A New onSave: Function A ``` Now a memoized child has a better chance of skipping unnecessary work when its other props are also unchanged. --- # Dependencies Still Matter Suppose your callback uses: ```jsx productId ``` Then: ```jsx const handleBuy = useCallback(() => { buyProduct(productId) }, [productId]) ``` If: ```text productId = 10 ``` the callback corresponds to product `10`. When: ```text productId = 20 ``` the function needs to change because its logic now depends on a different value. That's why `productId` belongs in the dependency array. --- # Don't Lie to `useCallback` This is wrong: ```jsx const handleBuy = useCallback(() => { buyProduct(productId) }, []) ``` if `productId` can change. The function uses `productId` but the dependency array claims nothing relevant changes. That can leave the callback holding onto an outdated value. Instead: ```jsx const handleBuy = useCallback(() => { buyProduct(productId) }, [productId]) ``` The dependency array isn't: > "How often would I like this function to change?" It's about the reactive values the function depends on. --- # `useCallback` With Functional State Updates Suppose: ```jsx const [todos, setTodos] = useState([]) ``` You might write: ```jsx const addTodo = useCallback( text => { setTodos([ ...todos, { id: crypto.randomUUID(), text } ]) }, [todos] ) ``` Because the callback reads `todos`, it depends on it. But we can often remove that dependency by using a functional state update: ```jsx const addTodo = useCallback(text => { setTodos(previousTodos => [ ...previousTodos, { id: crypto.randomUUID(), text } ]) }, []) ``` Now the function doesn't need to read `todos` from the current render. React gives the updater the latest state. You've already seen this pattern with `useState`, and it becomes particularly useful when working with memoized callbacks. --- # Another Use of `useCallback`: Effect Dependencies Function identity can also matter when a function is used by an Effect. For example: ```jsx function ChatRoom({ roomId }) { function createOptions() { return { roomId } } useEffect(() => { const options = createOptions() // connect using options }, [createOptions]) } ``` Because: ```jsx createOptions ``` is recreated each render, the Effect may see a changed dependency each time. One possible solution is: ```jsx const createOptions = useCallback(() => { return { roomId } }, [roomId]) ``` However, before automatically reaching for `useCallback`, ask whether the function could simply live inside the Effect instead: ```jsx useEffect(() => { const options = { roomId } // connect using options }, [roomId]) ``` Often that's simpler. Optimization Hooks shouldn't be used to rescue unnecessarily complicated code when restructuring the code solves the problem more clearly. --- # `useMemo` vs `useCallback` These Hooks look similar because both involve dependencies. But what they cache is different. ### `useMemo` ```jsx const visibleProducts = useMemo(() => { return filterProducts( products ) }, [products]) ``` Caches the **result**: ```text Array of filtered products ``` ### `useCallback` ```jsx const handleSave = useCallback(() => { saveDocument() }, []) ``` Caches the **function reference itself**. So: ```text useMemo ↓ CACHE A VALUE ``` ```text useCallback ↓ CACHE A FUNCTION ``` That's the simplest distinction. --- # Why Not Use `useCallback` for Every Function? Because most functions don't need stable identity. This is perfectly normal: ```jsx function handleClick() { setCount( previous => previous + 1 ) } ``` You do **not** automatically improve the application by changing it to: ```jsx const handleClick = useCallback(() => { setCount( previous => previous + 1 ) }, []) ``` Now you've added another Hook and another dependency array that developers must understand. If there is no actual optimization or identity requirement, you've mostly optimized your code's ability to look more complicated. 😂 --- # A Modern React Note: React Compiler 🤖 Modern React also has the **React Compiler**, which can automatically perform memoization optimizations in compiled applications. That changes how you should think about: ```jsx useMemo() ``` and: ```jsx useCallback() ``` Historically, developers often added manual memoization to performance-sensitive components. With React Compiler enabled, React can automatically memoize many values and functions for you. That doesn't mean `useMemo` and `useCallback` disappeared. They still exist and can be useful when you need explicit control. But for new code, don't start with: > "Where can I add `useMemo`?" Start with: > "Is there actually a performance or identity problem here?" Write clear code first. Then optimize where needed. --- # Don't Optimize Based on Vibes™ This deserves a section. 😂 Suppose you have: ```jsx const filtered = products.filter( product => product.active ) ``` and there are twelve products. Do you need: ```jsx useMemo(...) ``` because `.filter()` sounds computational? Probably not. Modern JavaScript engines can perform an enormous amount of simple work very quickly. Performance optimization should solve an actual problem. If a page feels slow, tools such as React DevTools and browser performance profiling can help you find where time is actually being spent. The expensive part may not be the calculation you assumed. Maybe it's rendering 5,000 DOM nodes. Maybe it's an unnecessary Effect. Maybe a giant component tree is updating. Maybe you're downloading a 14 MB hero image and blaming `.filter()`. 😭 Measure first. Optimize second. --- # Putting All Four Hooks Side by Side These Hooks solve completely different problems. ```text useRef ↓ Remember something without causing a re-render useReducer ↓ Organize complicated state transition logic useMemo ↓ Cache the result of a calculation useCallback ↓ Cache a function reference ``` Let's make the differences even clearer. --- # `useState` vs `useRef` Use state: ```jsx const [count, setCount] = useState(0) ``` when: ```text count changes ↓ UI should update ``` Use a ref: ```jsx const intervalRef = useRef(null) ``` when: ```text value changes ↓ React needs to remember it ↓ UI does NOT need to update ``` --- # `useState` vs `useReducer` Use `useState`: ```jsx const [name, setName] = useState("") ``` when the state and updates are straightforward. Use `useReducer`: ```jsx const [cart, dispatch] = useReducer( cartReducer, initialCart ) ``` when many related actions modify a piece of state and centralizing those rules makes them easier to understand. --- # `useMemo` vs `useRef` This comparison can confuse beginners because both can retain something across renders. But they have different purposes. `useMemo`: ```jsx const result = useMemo( () => expensiveCalculation(data), [data] ) ``` means: > "Cache this computed result while its dependencies haven't changed." A ref: ```jsx const connectionRef = useRef(null) ``` means: > "Keep this mutable value between renders without making it part of rendering." One is primarily memoizing a calculation. The other is persistent mutable storage outside React's rendering state. --- # `useMemo` vs `useCallback` This one is straightforward: ```text useMemo ↓ Caches the VALUE returned by a function ``` ```text useCallback ↓ Caches the FUNCTION itself ``` Or: ```jsx const value = useMemo( () => calculate(), [] ) ``` versus: ```jsx const fn = useCallback( () => calculate(), [] ) ``` The first calls the function as part of calculating the memoized value. The second gives you a cached function you can call later. --- # Practical Decision Guide 🧠 Imagine you're building something and wondering which Hook you need. Ask these questions. ### "Should changing this value update the UI?" Yes? Use state: ```jsx useState() ``` or perhaps: ```jsx useReducer() ``` No? Maybe: ```jsx useRef() ``` --- ### "Is my state logic becoming difficult to manage?" If you have many related actions and state transitions: ```jsx useReducer() ``` may organize it better. --- ### "Is an expensive derived calculation repeating unnecessarily?" Consider: ```jsx useMemo() ``` But verify that there's actually a meaningful performance reason. --- ### "Do I specifically need a function reference to remain stable?" Consider: ```jsx useCallback() ``` especially when interacting with memoized children or APIs where function identity matters. --- # A Combined Practical Example Let's build a simplified product dashboard using several of these ideas. ```jsx import { memo, useCallback, useMemo, useReducer, useRef } from "react" const initialState = { products: [ { id: 1, name: "Laptop", price: 999 }, { id: 2, name: "Phone", price: 699 }, { id: 3, name: "Keyboard", price: 89 } ], search: "" } function reducer( state, action ) { switch (action.type) { case "search_changed": return { ...state, search: action.value } case "product_deleted": return { ...state, products: state.products.filter( product => product.id !== action.productId ) } default: throw new Error( `Unknown action: ${action.type}` ) } } const ProductRow = memo( function ProductRow({ product, onDelete }) { return (

{product.name} {" — "} ${product.price}

) } ) function ProductDashboard() { const [state, dispatch] = useReducer( reducer, initialState ) const searchRef = useRef(null) const visibleProducts = useMemo(() => { const search = state.search .trim() .toLowerCase() return state.products.filter( product => product.name .toLowerCase() .includes(search) ) }, [ state.products, state.search ]) const handleDelete = useCallback(productId => { dispatch({ type: "product_deleted", productId }) }, []) function focusSearch() { searchRef.current?.focus() } return (

Product Dashboard

dispatch({ type: "search_changed", value: event.target.value }) } placeholder="Search products..." />

Found{" "} {visibleProducts.length}{" "} products.

) )}

) } ``` This one example contains all four Hooks. Let's see what each one is doing. --- # What `useRef` Is Doing ```jsx const searchRef = useRef(null) ``` gives us access to the actual search input. Then: ```jsx searchRef.current?.focus() ``` allows us to focus it. The DOM reference doesn't belong in state because changing the ref itself doesn't need to render anything. --- # What `useReducer` Is Doing The reducer manages related product dashboard state: ```text products search ``` Instead of spreading update rules throughout the component, we describe actions: ```jsx dispatch({ type: "search_changed", value: ... }) ``` and: ```jsx dispatch({ type: "product_deleted", productId }) ``` The reducer decides how those actions change state. --- # What `useMemo` Is Doing ```jsx const visibleProducts = useMemo(() => { // filter products }, [ state.products, state.search ]) ``` represents derived product data. If the real filtering calculation is expensive enough to justify memoization, React can reuse the result until the relevant dependencies change. For a tiny three-product example, `useMemo` isn't actually necessary—we're using it here to demonstrate where the Hook fits. That distinction matters. Tutorial examples need small datasets so you can read them. Performance optimizations usually become valuable on much larger workloads. --- # What `useCallback` Is Doing ```jsx const handleDelete = useCallback(productId => { dispatch({ type: "product_deleted", productId }) }, []) ``` keeps the callback reference stable. Our child: ```jsx const ProductRow = memo(...) ``` is memoized. So keeping props stable can help that optimization work as intended. Again, don't read this as: ```text Every event handler ↓ useCallback ``` That's not the lesson. The lesson is: ```text Memoized child + Function prop + Function identity matters ↓ useCallback may help ``` --- # Common Beginner Mistakes 🚨 ## Mistake 1: Using a Ref for Visible State Don't do: ```jsx const countRef = useRef(0) function increment() { countRef.current++ } ``` and expect: ```jsx

{countRef.current}

``` to automatically update. Use: ```jsx const [count, setCount] = useState(0) ``` if the count should control the UI. --- ## Mistake 2: Mutating Reducer State Wrong: ```jsx case "add_item": state.items.push( action.product ) return state ``` Correct: ```jsx case "add_item": return { ...state, items: [ ...state.items, action.product ] } ``` Reducers should calculate and return new state. --- ## Mistake 3: Using `useReducer` for Everything This: ```jsx const [isOpen, setIsOpen] = useState(false) ``` is excellent. You probably don't need: ```jsx dispatch({ type: "modal_visibility_toggled" }) ``` for one simple boolean unless the surrounding logic genuinely warrants it. Sometimes simple is professional. --- ## Mistake 4: Memoizing Cheap Calculations This: ```jsx const total = price * quantity ``` probably doesn't need: ```jsx useMemo( () => price * quantity, [price, quantity] ) ``` You have now asked React to manage memoization for arithmetic that your calculator could finish before you completed reading this sentence. 😭 --- ## Mistake 5: Assuming `useCallback` Prevents Child Renders This: ```jsx const handleClick = useCallback(() => { // ... }, []) ``` does not magically freeze every child component receiving it. `useCallback` only stabilizes the function reference while dependencies remain unchanged. Whether that saves meaningful rendering work depends on how that function is being used. --- ## Mistake 6: Missing Dependencies Wrong: ```jsx const handleBuy = useCallback(() => { buyProduct(productId) }, []) ``` if `productId` changes. Better: ```jsx const handleBuy = useCallback(() => { buyProduct(productId) }, [productId]) ``` The same principle applies to `useMemo`. Dependencies should reflect the reactive values used by the calculation or callback. --- # Quick Hook Cheat Sheet 🚀 ## `useRef` ```jsx const inputRef = useRef(null) ``` DOM access: ```jsx ``` Then: ```jsx inputRef.current?.focus() ``` Non-rendering memory: ```jsx const timerRef = useRef(null) timerRef.current = setInterval(...) ``` Use it when: > You need to remember something without making its changes trigger renders. --- ## `useReducer` ```jsx const [state, dispatch] = useReducer( reducer, initialState ) ``` Dispatch: ```jsx dispatch({ type: "item_added", item }) ``` Reducer: ```jsx function reducer( state, action ) { switch (action.type) { case "item_added": return { ...state, items: [ ...state.items, action.item ] } default: throw new Error( "Unknown action" ) } } ``` Use it when: > Related state updates are becoming complicated enough that putting their transition logic in one reducer makes the code clearer. --- ## `useMemo` ```jsx const visibleProducts = useMemo(() => { return expensiveFilter( products ) }, [products]) ``` Use it when: > You have a calculation worth caching between renders and its dependencies don't change every time. Remember: ```text useMemo ↓ caches a VALUE ``` --- ## `useCallback` ```jsx const handleSave = useCallback(() => { saveDocument() }, []) ``` Use it when: > You specifically need a function reference to remain stable between renders, commonly for an optimized child or another identity-sensitive API. Remember: ```text useCallback ↓ caches a FUNCTION ``` --- # Which Hook Should I Reach For? Here's the most useful version of the decision table: | Situation | Hook | | --------------------------------------- | ------------- | | Value changes and UI should update | `useState` | | Complex related state transitions | `useReducer` | | Need direct access to DOM element | `useRef` | | Need persistent value without re-render | `useRef` | | Expensive derived calculation | `useMemo` | | Need stable function reference | `useCallback` | And remember that: ```text "I can use this Hook here" ``` is not the same as: ```text "I should use this Hook here." ``` That distinction becomes increasingly important as your React skills improve. --- # Chapter Summary 🎯 This chapter introduced four Hooks that solve very different problems. `useRef` gives your component persistent mutable storage that doesn't trigger rendering when `.current` changes. ```jsx const ref = useRef(initialValue) ``` Use refs primarily when you need direct DOM access or when you need to remember something that doesn't directly affect the UI. ```text useRef ↓ DOM references timer IDs mutable non-visual values ``` --- `useReducer` provides another way to manage state when update logic becomes more complicated. ```jsx const [state, dispatch] = useReducer( reducer, initialState ) ``` Instead of directly setting state everywhere, components dispatch actions: ```jsx dispatch({ type: "item_removed", itemId }) ``` and the reducer calculates the next state: ```text Current State + Action ↓ Reducer ↓ Next State ``` It's especially useful when many related actions affect the same state. --- `useMemo` caches the result of a calculation. ```jsx const result = useMemo( () => expensiveCalculation(data), [data] ) ``` Its purpose is primarily optimization. Don't use it for calculations that are already cheap just because memoization sounds fast. ```text useMemo ↓ Cache calculated VALUE ``` --- `useCallback` caches a function reference. ```jsx const handleSave = useCallback(() => { save() }, []) ``` It becomes useful when stable function identity actually matters, such as passing callbacks into certain memoized children. ```text useCallback ↓ Cache FUNCTION reference ``` And importantly: ```text useCallback ≠ "Automatically prevent child renders" ``` It's one piece of a possible optimization strategy. --- # The Bigger Mental Model 🧠 At this stage, you can start thinking about [React Hooks](/courses/reactjs) based on the problem you're solving instead of trying to memorize a giant list. ```text I need UI-changing state ↓ useState State transitions are getting complex ↓ useReducer I need to remember something without rendering ↓ useRef I need DOM access ↓ useRef A genuinely expensive calculation repeats unnecessarily ↓ useMemo A function reference specifically needs to remain stable ↓ useCallback ``` That's much more useful than memorizing definitions. And remember: you don't get bonus React developer points for squeezing the maximum possible number of Hooks into one component. If this: ```jsx const total = price * quantity ``` solves the problem, use it. You don't need to turn it into: ```jsx useMemo(...) ``` just so your code looks like it has completed an advanced React course. 😂 Clear code first. Correct code second. Measure performance when performance actually matters. Then optimize intentionally. --- # What We'll Explore in the Dedicated Articles 🔬 This chapter gives you enough knowledge to start recognizing and using these Hooks, but each one has much more depth. In the dedicated **`useRef`** article, we can explore DOM manipulation, focusing, scrolling, measuring elements, previous values, timers, third-party libraries, refs on custom components, and when refs become an escape hatch you should avoid. In the dedicated **`useReducer`** article, we can go deeper into action design, reducer architecture, complex forms, todo applications, shopping carts, reducer initialization, combining reducers, reducers with Context, and testing reducer logic. In the dedicated **`useMemo`** article, we can explore expensive calculations, referential equality, objects and arrays as props, dependency mistakes, profiling, when memoization costs more than the calculation itself, and how React Compiler changes the optimization story. And in the dedicated **`useCallback`** article, we can properly explore function identity, `memo`, dependencies, stale closures, functional updates, custom Hooks, Effects, profiling, and situations where `useCallback` adds complexity without improving performance. For now, the important thing is that when you encounter: ```jsx useRef() useReducer() useMemo() useCallback() ``` they should no longer look like four random React spells. You should be able to ask: > **What problem is this Hook solving here?** If you can answer that, you're learning React the right way. --- # Keep Learning With asif.to 🚀 Your React toolbox is getting considerably larger now: ```text Components 🧩 Build reusable UI Props 📦 Pass information State 🧠 Store changing information Events ⚡ Respond to users Lists 📋 Render collections Conditional Rendering 🤔 Control what appears Effects 🔄 Synchronize external systems Lifting State ⬆️ Share nearby state Context 🌍 Share values through a subtree React Router 🧭 Connect URLs to UI useRef 📌 Remember non-rendering values and access DOM nodes useReducer ⚙️ Organize complex state updates useMemo 🧮 Memoize calculated values useCallback 📞 Memoize function references ``` The important next step isn't trying to use every Hook in your next project. It's learning to recognize **when you don't need one**. A good React developer isn't the person who writes the most Hooks. It's the person who can look at a problem and choose the simplest tool that makes the code correct and understandable. Build a stopwatch to practice `useRef`. Build a shopping cart or task manager to practice `useReducer`. Experiment with a large searchable list when learning `useMemo`. Then combine `useCallback` with a genuinely memoized child and use React DevTools to understand whether the optimization actually changes anything. That's where these concepts start becoming real. For more beginner-friendly React explanations, practical examples, and dedicated deep dives into each of these Hooks, visit **asif.to**. Follow **asif.to** on its social handles too for shorter React tips, programming explanations, and practical examples that focus on understanding *why* something exists before telling you to add another dependency array. 😄 **Learn the simple solution first. Reach for advanced Hooks when the problem actually asks for them. 🚀** — **asif.to**