React Hooks in 2026: A Complete Guide with Real-World Examples

Why Hooks Still Matter in 2026

Hooks shipped in React 16.8 back in 2019 and people thought it was just a syntax preference. It wasn't. It fundamentally changed how you split logic out of your components — and seven years later, the patterns have matured into something genuinely elegant if you know what you're doing.

Honestly, the class component era created a lot of accidental complexity. Lifecycle methods like componentDidMount and componentDidUpdate were doing different conceptual things but living in the same place. Hooks let you co-locate logic by *concern*, not by lifecycle phase. That one shift changed everything.

In 2026 you're almost certainly writing function components exclusively. Server Components, React Compiler, concurrent features — all of it assumes you're on hooks. If you're still maintaining legacy class components, that's a separate problem. For everyone else, this guide is about getting the hook patterns *right*, not just functional.

useState: More Depth Than You Think

You know useState. But do you know when *not* to use it? That's the actual skill. Every time you add a useState, you're buying a re-render on every write. For a single input field that's fine. For a 20-field form that re-renders the entire tree on every keystroke, it's not.

Worth noting: the functional updater form — setState(prev => ...) — exists for a reason. If you're updating state based on previous state inside an async callback or event handler, you *need* it. Plain setState(count + 1) inside a stale closure gives you a bug that only shows up under fast clicks.

function Counter() {
  const [count, setCount] = React.useState(0);

  // Correct: functional updater avoids stale closure bugs
  const increment = () => setCount(prev => prev + 1);

  // Incorrect in async contexts: reads stale count
  // const increment = () => setCount(count + 1);

  return (
    <button onClick={increment}>
      Clicked {count} times
    </button>
  );
}

One more thing — lazy initialization. If your initial state is expensive to compute (parsing a large JSON blob, reading from localStorage), pass a *function* to useState, not the value. useState(() => JSON.parse(localStorage.getItem('data'))) runs once. useState(JSON.parse(...)) runs on every render. One character difference, huge performance gap.

useEffect: The Hook Everyone Gets Wrong

Look, useEffect is probably responsible for more subtle bugs in React apps than any other API. The mental model people have — "it runs after render" — is incomplete. The full picture is: it runs after every render *where the dependencies changed*, and the cleanup function runs before the *next* effect fires, not when the component unmounts.

The dependency array is a contract. You're telling React "re-run this effect when any of these values change." Leaving something out doesn't mean it won't affect the effect — it means your effect will read a stale version of that value. The ESLint plugin eslint-plugin-react-hooks catches most of these, and you should have it enabled with zero exceptions.

function useDocumentTitle(title) {
  useEffect(() => {
    const previous = document.title;
    document.title = title;

    // Cleanup restores the title when the component unmounts
    // or before the next effect run if title changes
    return () => {
      document.title = previous;
    };
  }, [title]); // title is the dep — don't omit it
}

Quick aside: if you're fetching data in useEffect, you should probably not be. In 2026, React Query, SWR, or React Server Components handle data fetching better in almost every case. useEffect for data fetching is a footgun — you have to handle race conditions, loading states, and cleanup manually. Libraries do all of that for free.

useMemo and useCallback: Use Them Less Than You Think

The instinct when you learn useMemo and useCallback is to wrap everything. Inline function? Wrap it. Derived value? Memoize it. Resist that instinct. Both hooks have a cost — the comparison itself, the memory to store the previous value, the cognitive overhead when reading the code later.

In practice, useMemo earns its place in two situations: expensive computations (think filtering a 10,000-item list on every keystroke) and stable object references for downstream React.memo() or useEffect dependencies. For everything else, you're adding complexity for no measurable gain. React's reconciler is fast. A cheap re-render costs maybe 0.1ms. Premature memoization costs your team's readability.

// Good use of useMemo — expensive filter on large dataset
const filteredItems = useMemo(
  () => items.filter(item => item.name.toLowerCase().includes(query)),
  [items, query] // only recomputes when items or query changes
);

// Pointless useMemo — simple addition
// const total = useMemo(() => a + b, [a, b]); // don't bother

That said, useCallback has one genuinely important use case: event handlers passed as props to memoized child components. If ParentComponent re-renders and passes a new function reference to React.memo(ChildComponent), the memo is broken. Wrapping the handler in useCallback fixes that — but only if the child is actually wrapped in React.memo. Otherwise you're just adding lines.

Custom Hooks: Where the Real Power Lives

Custom hooks are the feature that quietly makes everything else worth it. You can extract any stateful logic into a function that starts with use and call it from any component. No HOC gymnastics. No render props contortion. Just a function.

A hook like useMediaQuery('(max-width: 768px)') can handle its own event listener setup, teardown, and return a clean boolean. A useLocalStorage hook wraps useState and syncs to localStorage transparently. These aren't theoretical — they're the patterns that make large codebases actually maintainable. You write the logic once, test it once, and every component that needs it just calls the hook.

If you're building UI components and want to see how custom hooks integrate with rich visual patterns, browse the components on Empire UI — most of the interactive ones expose a hook-friendly API. Worth studying just to see how hook design scales.

One thing to keep in mind: a custom hook doesn't need to be general-purpose to be worth extracting. A hook that's only used by one component but manages 40 lines of effect and state logic is still worth pulling out. It keeps the component readable and the logic testable in isolation.

useRef and useReducer: The Underused Ones

Everyone knows useRef for DOM access. Fewer people use it for what it's actually great at: mutable values that *don't* trigger re-renders. Need to store a previous value? useRef. Need an interval ID to clear later? useRef. Need to track whether a component is mounted inside an async callback? useRef. It's a box that persists across renders without causing them.

function usePrevious(value) {
  const ref = React.useRef();
  useEffect(() => {
    ref.current = value;
  }); // no dep array: updates after every render
  return ref.current; // returns the *previous* render's value
}

useReducer is the one people reach for too late. If your useState logic has grown to 4-5 related pieces of state with complex transitions between them — you're writing an informal reducer already. Making it explicit with useReducer gives you a clear action surface, makes state transitions testable, and often simplifies the component significantly. Think of it as useState with a schema.

Hooks in the Context of Modern React UI

In 2026, hooks don't exist in isolation. They're the runtime layer under React Server Components, and they're what makes the React Compiler's auto-memoization work properly. If you have hooks that break the rules of hooks — conditional calls, hooks inside loops — the compiler won't be able to optimize your component. The rules aren't arbitrary.

When you're building visual-heavy UIs — animations, glassmorphism effects, theme switching — hooks handle the stateful parts cleanly. Tracking whether a glassmorphism generator panel is open, managing the CSS variable values a user has configured, debouncing preview updates — all of that lands naturally in custom hooks without polluting your render logic.

The gradient generator pattern is a good mental model: you've got real-time preview state, debounced output, clipboard interactions, and URL sync. Each of those is a hook. Stack them in a custom useGradientEditor() and your component becomes 30 lines of JSX instead of 150 lines of tangled state.

Hooks have won. Not because they're fashionable but because the mental model actually scales — from a simple toggle to a full design tool. Master the primitives, build the right custom hooks, and you'll spend a lot less time debugging and a lot more time shipping.

FAQ

Read next