Common Custom-Hook Patterns

## The value version ```js import { useState, useEffect } from 'react'; function useDebouncedValue(value, delay) { const [debounced, setDebounced] = useState(value); useEffect(() => { const id = setTimeout(() => setDebounced(value), delay); return () => clearTimeout(id); }, [value, delay]); return debounced; } ``` The elegance is that the debouncing falls out of the effect lifecycle rather than being coded. Every time `value` changes, React runs the cleanup of the previous effect — cancelling the pending timer — and then runs the new effect, starting a fresh one. Type six characters quickly and you get six starts and five cancellations; only the last timer survives to fire. Note that the timer id is an ordinary local `const`: the cleanup closure captures it, so no ref is needed here at all. Claiming otherwise is a common over-engineering tell. Cleanup also fires on unmount, which matters: without it the callback would run on a component that no longer exists, and in a data-fetching context that is how you get a request fired for a screen the user has already left. The hook returns `value` immediately on the first render (state is initialised from it), which is normally what you want — the delay applies to *changes*, not to the initial paint. ## When to use the value version A debounced value is the right shape when the consumer is declarative: a search box where you render results for `useDebouncedValue(query, 300)` while the input itself stays fully responsive on the undebounced `query`. It is worth naming the alternative here, because interviewers probe it: `useDeferredValue` solves the adjacent problem of keeping the UI responsive under heavy rendering by letting React render the stale value at a lower priority, and it adapts to how fast the device actually is. A debounce is a fixed wall-clock delay — the right tool when the cost is *downstream* (a network request, an expensive external call), not when the cost is React rendering. ## Why the callback version is different ```js import { useRef, useEffect, useCallback } from 'react'; function useDebouncedCallback(fn, delay) { const fnRef = useRef(fn); const timerRef = useRef(null); useEffect(() => { fnRef.current = fn; }); useEffect(() => () => clearTimeout(timerRef.current), []); return useCallback((...args) => { clearTimeout(timerRef.current); timerRef.current = setTimeout(() => fnRef.current(...args), delay); }, [delay]); } ``` Two constraints collide here. **The wrapper must be stable.** Debouncing works by a single pending timer being repeatedly cancelled. If a new wrapper with its own fresh timer variable is produced on each render, each call starts an independent timer and every one of them eventually fires — the opposite of debouncing. So the wrapper is memoized, and the timer id is held in a ref precisely because it must outlive the individual call and be reachable from the next one. **But a stable wrapper freezes its closure.** `useCallback(..., [delay])` means the function is created once and keeps the `fn` from that render. If `fn` is `() => save(draft)`, the wrapper will still be saving the first `draft` an hour later. This is the stale-closure trap, and the standard cure is the latest-ref pattern: keep the changing thing in a ref that is refreshed after every commit, and read `fnRef.current` at *call* time rather than capturing `fn` at *creation* time. Because refs are mutable boxes that do not participate in rendering, updating one does not invalidate the memoized wrapper. The write to `fnRef.current` goes in an effect rather than the body for the same purity reason that applies to any render-time mutation: a render can be abandoned or, in StrictMode, double-invoked. (React has an in-progress `useEffectEvent` hook intended to make this pattern a first-class API; until it is stable in your React version, the latest-ref pattern is the portable way to express "read this at call time, do not depend on it".) ## Unmount and leading edge The second effect returns a cleanup that clears any pending timer on unmount. Without it a debounced save fires after the user navigates away, touching state on a dead component and confusing the user about what got persisted. A leading-edge variant fires immediately on the first call and then suppresses for the delay window; it is the right choice for actions that must feel instant, like a button, while trailing-edge debounce is right for text input. Throttling is the neighbouring idea — trailing debounce fires once after the storm ends, whereas throttling fires at most once per interval *during* the storm. Choosing wrong is a real bug: a scroll handler that only reports after the user stops scrolling is useless for a progress indicator. ## What interviewers listen for That cleanup is what makes debouncing work rather than an afterthought; that the value version needs no refs at all; that the callback version needs exactly two refs and why each one exists; and that a timer must be cancelled on unmount.