Every Core React Hook, Visualized — An Interactive Walkthrough

A fiber is React’s internal record of a component instance. Think of it as a JavaScript object that holds everything React needs to remember between renders: the current props, the type of component, pointers to parent/sibling/child fibers, and — crucially — a linked list of hook records. There is one fiber per mounted component instance, and the entire tree of fibers mirrors the tree of components in your app.

When you call useState, useEffect, or any hook, React looks at the currently-rendering fiber and walks down its hook list to slot N (where N = “the Nth hook called this render”). The hook record at slot N stores the hook’s state — for useState, that’s the value and its update queue; for useEffect, the deps array and the cleanup function; for useMemo, the cached result and the deps used to produce it.

A render in React is split into two phases:

1. Render phase (pure) — React calls your component function. It walks the hook list in source order, returning whatever’s in each slot. If setState was called previously, the slot’s pending queue is drained and a new value is computed. Your component returns JSX (a description of what should be on screen). React diffs this against the previous tree to produce a list of mutations. Nothing has touched the DOM yet — this phase can be paused, resumed, or thrown away (it’s how concurrent rendering works).

2. Commit phase (synchronous, side-effecting) — React applies the mutations to the real DOM and runs useLayoutEffect callbacks. This phase is uninterruptible. The browser then paints. After paint, React fires useEffect callbacks in a separate, asynchronous passive-effects flush. (The post lumps “render → commit → paint → effects” into one mental pipeline, but strictly: only the DOM mutate + layout effects bit is “the commit phase”.)

This separation is the entire conceptual win of React: you write a pure function that says “given this state, the UI should look like this”, and React figures out the minimum diff to reach that state from whatever was there before. Hooks are the API by which a stateless function gains access to per-instance state — without you ever having to write class extends Component or wire up this.state.

The “Rules of Hooks” — call them at the top level, in the same order, every render — exist because React identifies hooks by slot index, not name. If you wrap a hook in an if, the slot indices shift on whichever render takes the other branch, and React reads the wrong values from the wrong slots. Catastrophic and silent. The eslint plugin react-hooks/rules-of-hooks catches this statically.

Why batching is the default (and what that means)

Before React 18, batching only happened inside React-managed event handlers. State updates inside setTimeout, Promise.then, native event listeners, or async functions each triggered their own render — death by a thousand reconciliations. React 18 introduced “automatic batching”: any number of setState calls within the same JavaScript task are batched into a single render, regardless of where they originate.

Functional updater: the closure trap, solved

When you write setN(n + 1), the value n is captured from the render that produced this closure. If you fire three setters in a row, all three see the same captured n (say 0) — and so all three compute 0 + 1, not 0 + 1 then 1 + 1 then 2 + 1. The result: only +1.

The functional form setN(prev => prev + 1) instead receives the latest pending value from the slot’s queue. Three increments now produce +3. Use the functional form whenever the new value depends on the old one — it’s the ergonomic equivalent of an atomic compare-and-swap.

// Bug: captures n=0 three times
setN(n + 1);
setN(n + 1);   // still computing 0 + 1
setN(n + 1);   // still computing 0 + 1

// Fix: each sees the latest pending
setN(prev => prev + 1);   // 0 → 1
setN(prev => prev + 1);   // 1 → 2
setN(prev => prev + 1);   // 2 → 3

useState vs useReducer — the decision matrix

Lazy initial state

useState accepts a function for expensive initialisation: useState(() => computeInitial()) — the function runs once on mount, never again. Without the function form, computeInitial() is called every render and its return value thrown away. Same trick for useReducer(reducer, initialArg, init) — the optional third arg.

Identity rules React relies on

State updates are committed only if Object.is(oldValue, newValue) === false. So setItems(items) (passing the same reference) is a no-op — React skips the render. This is why mutating an array in place and calling setItems(items) doesn’t update the UI — the reference didn’t change. Always create a new array ([...items, x]) or object ({ ...obj, k: v }).

Why your effects fire twice in dev

In React 18+ with <StrictMode>, every effect runs setup → cleanup → setup again on mount. That’s not a bug — it’s React deliberately stress-testing your code. The contract is: your effect must be safe to run twice. If running setup-cleanup-setup leaks a subscription, opens two sockets, or fires two analytics events, your effect has a bug that would also bite you in production the moment React decides to remount the component (which it now reserves the right to do for offscreen rendering, suspense recovery, fast-refresh, and future features).

The fix is always the same: make cleanup idempotent and complete. If setup adds a listener, cleanup removes it. If setup starts a timer, cleanup clears it. If setup makes an HTTP request, cleanup aborts it (modern fetch supports AbortSignal). Once your effect survives setup-cleanup-setup, it survives anything React throws at it.

The five most common cleanup bugs

// 1) Forgot to clean up an interval
useEffect(() => {
  const id = setInterval(tick, 1000);
  // BUG: no cleanup → multiple intervals stack up
}, []);
// Fix: return () => clearInterval(id)

// 2) Forgot deps array → effect runs every render
useEffect(() => {
  fetchData();
});
// Fix: useEffect(() => { fetchData(); }, [/* relevant deps */])
// (note the braces — the body must NOT return the Promise from fetchData,
//  or React will warn that the cleanup return value isn't a function.)

// 3) Async function as the effect body — wrong shape
useEffect(async () => {
  const data = await fetch(url);
}, [url]);
// async fn returns a Promise. useEffect expects undefined or a cleanup fn —
// React warns and your "cleanup" silently never runs.
// Fix: declare an inner async function and call it
useEffect(() => {
  let cancelled = false;
  (async () => {
    const data = await fetch(url);
    if (!cancelled) setData(data);
  })();
  return () => { cancelled = true; };
}, [url]);

// 4) Effect that mutates state on every render → infinite loop
useEffect(() => {
  setCount(count + 1);
}); // re-renders, runs again, re-renders…
// Fix: don't useEffect for derivation. Compute during render, or memoize
// the value with useMemo. See "When NOT to use useEffect" below.

// 5) Stale closure in an event listener
useEffect(() => {
  const handler = () => console.log(count);  // captures stale count
  window.addEventListener("scroll", handler);
  return () => window.removeEventListener("scroll", handler);
}, []);  // ← deps wrong; this captures count=0 forever
// Fix: include count in deps, or read from a ref

When NOT to use useEffect

The single biggest improvement to most React codebases is deleting effects. The React team’s guidance in You Might Not Need an Effect is worth reading carefully. Common bad patterns:

The mental rule: effects exist to synchronise with external systems (DOM measurements, browser APIs, network, third-party libs). They are NOT a place to derive state from props or run logic that “needs to happen after some action”.

useLayoutEffect vs useEffect — the deciding question

Ask: if the user sees the result of the effect for one frame before it runs, is that bad?

• Yes, it would flicker → useLayoutEffect (synchronous, blocks paint, pays the perf cost).
• No, it’s invisible → useEffect (async, no perf cost).

Tooltip positioning, scroll restoration on navigation, focus trapping in a modal — all are useLayoutEffect. Subscriptions, analytics, debounced saves, network requests — all are useEffect.

The propagation algorithm, in one sentence

When a provider’s value changes, React walks down the tree and bails out of components that don’t consume the context — but never bails out at a React.memo boundary if anything inside still consumes it. Memo is checked against props; context is checked against subscriptions. They’re orthogonal.

The mental model: context is a broadcast channel, not a prop. Subscribers tune in directly to the provider — the tree shape between them is irrelevant.

Three fixes for “everything re-renders”

1) Split the context. This is the cheapest, most effective fix. Don’t put { user, theme, cart, settings } in one mega-context. Make UserContext, ThemeContext, CartContext, SettingsContext, and consumers only re-render when their slice changes.

// Bad: one context, every change cascades
<AppContext.Provider value={{ user, theme, cart }}>

// Good: parallel providers, surgical re-renders
<UserContext.Provider value={user}>
  <ThemeContext.Provider value={theme}>
    <CartContext.Provider value={cart}>
      {children}
    </CartContext.Provider>
  </ThemeContext.Provider>
</UserContext.Provider>

2) Memoise the value. A new object literal in the provider’s value prop = new reference every render = every consumer re-renders even when the underlying data didn’t change.

// Bad: new object every render of the parent
<MyContext.Provider value={{ user, login, logout }}>

// Good: stable object
const value = useMemo(
  () => ({ user, login, logout }),
  [user, login, logout]
);
<MyContext.Provider value={value}>
// (Note: if `login` / `logout` are inline arrows in the parent,
//  they're new each render and this useMemo never hits.
//  Wrap them in useCallback first.)

3) Selector pattern (advanced). When you can’t split the context (e.g., it’s a giant store from a third-party library), reach for a selector hook. Libraries like use-context-selector let consumers subscribe to a slice of the context value and only re-render when that slice changes. This is what Redux’s useSelector does. React core may eventually ship this, but as of React 19 it doesn’t.

When context is the wrong tool entirely

Context is for truly app-wide concerns that change rarely: theme, locale, current user, feature flags. It is NOT a state-management library. If your context value updates every keystroke, every scroll, every animation frame — you’ve turned the entire subtree into a re-render storm. Use:

Ref vs state — a decision flowchart

The simplest test: if you read the value in JSX (or in a derivation that becomes JSX), you need state. If you only read it from event handlers, effects, or imperative APIs, a ref is enough.

What goes in a ref (concrete checklist)

• Timer / interval IDs → ref. You only need them in cleanup.
• AbortController for in-flight fetches → ref. You need to cancel from the next call site.
• The DOM node of an <input>, <canvas>, <dialog> → ref. You call methods on it.
• A WebSocket / EventSource / non-React library instance → ref. You initialise once, dispose on unmount.
• The “previous” value of a prop or state, for change detection → ref + useEffect.
• A flag like mountedRef.current = true to skip work on the first render → ref.
• Anything you’d put on this in a class component, that doesn’t drive UI → ref.

Refs and DOM nodes — the timing rules

When you write <input ref={inputRef} />, React assigns inputRef.current to the DOM node during commit, before any effects run. Reading order:

1. In useLayoutEffect → safe. The ref is set, the DOM is mutated, the browser hasn’t painted yet.
2. In useEffect → safe. Same as above, plus the browser has painted.
3. In the render body → unsafe. The ref is null on the first render and stale on subsequent ones (until commit). Never read ref.current from render-phase code.
4. On unmount → both useLayoutEffect cleanup and useEffect cleanup run before React detaches the ref, so ref.current is still readable in either. The trap is the update case: when a child element is re-keyed or replaced between renders, React detaches the old ref before re-running the effect, so a useEffect cleanup that fires for a mid-life update may see ref.current === null. The robust pattern is to capture the node in a local variable inside setup and close over that — your cleanup gets the right node regardless of when it runs.

forwardRef + useImperativeHandle

By default, refs only attach to host elements (<div>, <input>, etc.). To pass a ref through a function component to a child in React ≤ 18, wrap the component in forwardRef:

const FancyInput = forwardRef(function FancyInput(props, ref) {
  return <input ref={ref} className="fancy" {...props} />;
});

// Now the parent can do:
const r = useRef(null);
<FancyInput ref={r} />;
r.current?.focus();  // forwarded all the way to <input>

In React 19+, forwardRef is no longer required — ref is just a regular prop on function components:

function FancyInput({ ref, ...props }) {
  return <input ref={ref} className="fancy" {...props} />;
}

forwardRef still works for backward compatibility, but new code should prefer the prop form.

useImperativeHandle adds a layer of curation between parent and child: instead of exposing the raw DOM node, the child decides what methods are available.

// React 19+: ref is a regular prop, no forwardRef wrapper.
function Modal({ ref, children }) {
  const [open, setOpen] = useState(false);
  // Stable handle — closures see the latest setOpen (its identity is stable
  // across renders), so empty deps are correct.
  useImperativeHandle(ref, () => ({
    open:  () => setOpen(true),
    close: () => setOpen(false),
  }), []);
  return open ? <dialog>{children}</dialog> : null;
}

When is this worth it? Almost never in app code. It’s an escape hatch for component libraries that need to expose a controlled imperative API (think: a <Modal />, a <Toast /> system, a video player). If you reach for it in regular product code, you’re probably fighting React’s data flow — lift state up instead.

Callback refs — the underused alternative

ref doesn’t have to be a useRef object. It can be a function. React calls your function with the DOM node on mount and null on unmount. If the callback’s identity changes between renders (e.g. an inline arrow without useCallback), React calls the old function with null and the new function with the node on every render — which is why wrapping the callback in useCallback matters.

function MeasuredBox() {
  const [height, setHeight] = useState(0);
  const measureRef = useCallback((node) => {
    if (node) setHeight(node.getBoundingClientRect().height);
  }, []);
  return <div ref={measureRef}>height: {height}</div>;
}

Callback refs are the cleanest way to measure a node when it mounts (no extra effect needed, no race conditions) or to wire up to a node whose presence is conditional. In React 19+, a callback ref can return a cleanup function instead of being called again with null — mirroring useEffect:

const measureRef = useCallback((node) => {
  // React 19+ guarantees `node` is the DOM node here; the cleanup
  // returned below replaces the legacy "called again with null" path.
  const ro = new ResizeObserver(/* … */);
  ro.observe(node);
  return () => ro.disconnect();
}, []);

The official docs page ref callbacks covers the lifecycle in detail.

The cost you don’t see

Every useMemo and useCallback is itself work. On every render, React must:

1. Read the hook record from the slot list.
2. Run Object.is on every cell of the deps array, comparing with the previous tuple.
3. Either skip the function (cache hit) or run it and store the new value + new deps tuple (cache miss).

For a function that returns a primitive or runs a few lines of code, steps 1-2 cost more than just running the function unconditionally. Memoising useMemo(() => a + b, [a, b]) is a strict performance loss. The official React docs are blunt about this in Should you add useMemo everywhere?: the answer is no.

When to use it

Use useMemo when at least one of these is true:

1. The computation is genuinely expensive — sorting/filtering thousands of items, parsing a large string, deep traversal of a tree, image processing.
2. The result is passed as a prop to a React.memo child and you need referential stability for that child to skip its own render.
3. The result is used as a dep in another hook (useEffect, useMemo, useCallback) where reference instability would cause spurious re-runs.

Anything else is cargo-cult premature optimisation. Profile first.

Use useCallback only when:

1. The function is passed to a React.memo child as onClick / onChange / similar handler.
2. The function is used as a dep in another hook (the most common legitimate case — useEffect that depends on a callback).
3. You’re building a custom hook and need to expose a stable function reference to consumers.

The decision matrix

The React Compiler changes the math

React 19 was designed to pair with the React Compiler (formerly “React Forget”) — a separate Babel/SWC plugin (babel-plugin-react-compiler, stable 1.0 since late 2025) that you opt into in your build. It automatically inserts memoisation at compile time, based on a static analysis of which values change and which children depend on them. With the compiler enabled, most hand-written useMemo/useCallback calls become noise — the compiler does it better and at the right granularity.

If you’re on React 19+ with the compiler enabled, the new rule of thumb is: don’t write useMemo/useCallback unless the compiler can’t reason about your code (rare — usually involves dynamic indirections or escape hatches). If you haven’t enabled the compiler, the matrix above still applies.

Spotting useless memo in code review

Look for these signs:

• useMemo(() => ({ ... }), [...]) where the object is consumed by a non-memo’d child → useless.
• useCallback(() => ..., []) for a handler passed to <button> → useless.
• useMemo(() => primitiveExpression, [...]) → almost always useless.
• A long chain of useCallbacks wrapping each other “for stability” → likely fighting symptoms; move state up or use a reducer.
• useMemo with [] as deps for something that doesn’t depend on render → use useRef with the lazy-init idiom (if (ref.current === null) ref.current = init()), not a memo. (useRef(init()) would call init() on every render — same trap as useState(init()).)

What “concurrent” actually means

In legacy React, a render was a single synchronous task. Once it started, it ran to completion — even if it took 100ms, the main thread was blocked the whole time. Click events queued. Scroll stuttered. Input lagged.

Concurrent React (since React 18) splits a render into time-slices. The scheduler asks “do I have more high-priority work?” between slices. If yes — say, the user typed — it pauses the in-flight render, handles the urgent work, and either resumes or throws away the partial work and starts over. From the user’s perspective, the input never blocks. From your code’s perspective, render must be safe to be paused, replayed, or discarded — which is why React enforces purity: no side effects in the render phase.

Two priority levels (today)

React internally has many lanes, but as an app developer you mostly think in two:

• Urgent — anything not wrapped in startTransition. Includes: input updates from controlled <input>, click handlers, default setState. Must commit ASAP.
• Transition — work wrapped in startTransition or driven by useDeferredValue. Interruptible. The scheduler runs transition work only when no urgent work is pending.

useTransition vs useDeferredValue — pick one

// useTransition — you own the setState
const [pending, startTransition] = useTransition();
function onChange(e) {
  setText(e.target.value);          // urgent
  startTransition(() => {
    setHeavyList(filter(items, e.target.value));  // transition
  });
}

// useDeferredValue — you only have the value
function ResultsView({ query }) {
  const deferred = useDeferredValue(query);  // lags during heavy work
  const list = useMemo(() => filter(items, deferred), [deferred]);
  const isStale = deferred !== query;
  return <List items={list} className={isStale ? "stale" : ""} />;
}

Suspense and transitions are best friends

The killer feature of transitions is what happens when the new render suspends (hits a <Suspense> boundary because data is loading). Without transitions, React shows the boundary’s fallback — your beautiful page is replaced by a spinner. With transitions, React keeps the previous UI on screen and only swaps in the new one when it’s ready, with isPending true the whole time so you can show a subtle pending indicator.

const [pending, startTransition] = useTransition();
function navigate(href) {
  startTransition(() => {
    setRoute(href);   // triggers a Suspense'd data fetch
  });
}
// While loading: previous page stays visible, isPending=true,
// no fallback flash. When data arrives: smooth swap.

This is the entire mechanism behind modern router transitions in Next.js App Router and Remix — they wrap navigation setStates in startTransition.

Common antipatterns

• Wrapping trivial setStates in startTransition. Setting a boolean toggle in a transition adds overhead with no benefit; the scheduler has nothing to optimise. Use it only when the resulting render is genuinely heavy.
• Wrapping the input update itself in startTransition. The input THEN lags. The whole point is that the input stays urgent and the result is the transition. Pattern: setText urgent, setFiltered transition.
• Using useDeferredValue and useTransition together on the same data path. Pick one. They’re alternative APIs for the same scheduling primitive.
• Putting effects-based work in transitions and expecting it to be interruptible. Effects run in the commit phase, after a render commits. They’re not part of the time-sliced render. If your bottleneck is an effect, move the work into render and memoise it (or move it out of React entirely with a worker).

What concurrent rendering does NOT solve

Concurrent rendering keeps the main thread responsive; it does not make slow code fast. If your filter function takes 500ms, the transition lane will still take 500ms — the user just won’t notice the lag in the input. For genuinely heavy compute, the answer is a Web Worker. Concurrent React only buys you better scheduling of the work React itself does.