React Hooks: State and Effects

Hooks let function components hold state and interact with the React runtime. Two rules make them work:

1. Only call hooks at the top level. Not inside loops, conditions, or nested functions. React identifies each hook by its call order within a render; conditional calls break that order and you'll see Rendered fewer hooks than expected errors.
2. Only call hooks from React functions. Components, or other custom hooks. Not from regular utility functions, not from event handlers' inner async callbacks.

The React 19 compiler (still optional in 2026) loosens the second rule for some patterns, but the first one is hard. Lint with eslint-plugin-react-hooks and the rules-of-hooks rule on — it catches almost every violation.

useState gives you a value and a setter. The value is a snapshot of this render, not a live reference.

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => {
      setCount(count + 1);
      setCount(count + 1);   // still 1, not 2!
    }}>{count}</button>
  );
}

Both setCount(count + 1) calls see count = 0 because the closure captured that render's value. To stack updates, pass the updater form: setCount(c => c + 1). Now React threads the previous state through and you actually get +2.

React 19 batches all setState calls that happen during the same event, effect, or microtask into one re-render. So this:

function onClick() {
  setA(1);
  setB(2);
  setC(3);
}

results in one re-render, not three. Batching used to apply only inside React event handlers; in React 18+ it covers everything — setTimeout, async fetches, Promises. If you ever genuinely need to opt out (rare), flushSync from react-dom forces a synchronous flush. You almost never want it; reach for it only when something measurement-related (like focusing the new element after layout) absolutely needs the DOM to settle before the next line runs.

useEffect(fn, deps) runs fn after React commits the DOM and any time the values in deps change. Use it for synchronizing with something outside React — subscriptions, manual DOM, document title, analytics.

useEffect(() => {
  document.title = `Inbox (${unread})`;
}, [unread]);

Do NOT use useEffect to compute derived state from props. Just compute it during render:

// ❌ pointless effect + double render
const [full, setFull] = useState('');
useEffect(() => setFull(`${first} ${last}`), [first, last]);

// ✅ derive during render
const full = `${first} ${last}`;

The React docs literally have a section called "You might not need an effect." Read it. It is the most common React mistake.

Every value from the render scope that the effect uses must be in deps. Forget one and you'll capture a stale value forever.

function Search({ query }: { query: string }) {
  useEffect(() => {
    fetch(`/api/search?q=${query}`);  // uses query
  }, []);                              // ❌ but [] says 'never re-run'
}

The effect captures the first render's query and ignores every later change. Fix: include [query]. The react-hooks/exhaustive-deps ESLint rule catches this — keep it on, fix the deps it suggests, don't disable it. If a dependency makes the effect re-run too often, the bug is usually that the dependency itself is being recreated each render (a fresh object/function literal); fix that with useMemo/useCallback or by moving the value out of the component.

If your effect subscribes to anything, return a cleanup function. React runs it before the next effect AND when the component unmounts.

useEffect(() => {
  const ctrl = new AbortController();
  fetch(`/api/users/${id}`, { signal: ctrl.signal })
    .then(r => r.json())
    .then(setUser);
  return () => ctrl.abort();   // cancel if id changes or we unmount
}, [id]);

Without cleanup you get classic bugs: stale subscriptions firing into unmounted trees, memory leaks, two responses racing to set state where the slower (older) one wins and shows wrong data.

Each render commits the DOM, then runs effects whose deps changed. Cleanup of the previous run fires first.

When state has more than 2-3 fields or transitions are non-trivial, useReducer keeps logic out of your handlers.

type Action =
  | { type: 'add'; title: string }
  | { type: 'toggle'; id: string }
  | { type: 'remove'; id: string };

function reducer(state: Todo[], action: Action): Todo[] {
  switch (action.type) {
    case 'add':    return [...state, { id: crypto.randomUUID(), title: action.title, done: false }];
    case 'toggle': return state.map(t => t.id === action.id ? { ...t, done: !t.done } : t);
    case 'remove': return state.filter(t => t.id !== action.id);
  }
}

function App() {
  const [todos, dispatch] = useReducer(reducer, []);
  return <button onClick={() => dispatch({ type: 'add', title: 'walk dog' })}>+</button>;
}

It's useState + Redux without the Redux. Tests get easier because the reducer is a pure function.

Prop drilling is when you thread a value through 5 components that don't care about it just to reach the one that does. useContext short-circuits that.

const ThemeCtx = createContext<'light' | 'dark'>('light');

function App() {
  return (
    <ThemeCtx.Provider value="dark">
      <Page />
    </ThemeCtx.Provider>
  );
}

function Button() {
  const theme = useContext(ThemeCtx);   // any depth, any descendant
  return <button className={theme}>OK</button>;
}

Gotchas: every consumer re-renders when the provider's value changes by reference. Don't pass a fresh {} each render — memoize it. And don't use context as a global store for everything; for cross-cutting client state (selection, theme, locale) it's perfect; for server data, use a data-fetching library or RSC instead.

When two sibling components need to share state, move it to their nearest common parent and pass it down. This is the same principle that makes useReducer tidy and props one-way.

function Filters() {
  const [query, setQuery] = useState('');
  return (
    <>
      <SearchBox value={query} onChange={setQuery} />
      <Results query={query} />
    </>
  );
}

If 'the nearest common parent' is way up the tree, you have two reasonable choices: lift it anyway and accept the prop chain (often fine), or put it in context (when many descendants need it). What you should NOT do is duplicate the state in both siblings and sync them via effects — that's the bug factory we warned about.