Building Custom Hooks in React

A custom hook is just a JavaScript function. Nothing magic — no special API to register it. Two conventions make it a "hook" React recognizes: its name starts with use, and it calls other hooks (useState, useEffect, etc.) inside itself.

The entire point is reusing stateful logic — not UI. If you've ever copy-pasted the same useState + useEffect combo into three different components, that logic wanted to be a custom hook.

// This IS a custom hook — starts with "use", calls other hooks
function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", handleResize);
    return () => window.removeEventListener("resize", handleResize);
  }, []);

  return width;
}

// Any component can now reuse this logic in one line
function Header() {
  const width = useWindowWidth();
  return <p>Window is {width}px wide</p>;
}

The simplest possible custom hook wraps a single useState call with a bit of convenience logic. It still pays off immediately: every component that needs a boolean toggle gets the exact same, tested behavior.

A custom hook is the natural place to bridge React state with a non-React API — here, localStorage. Read once on mount (lazily, via useState's initializer function), then write back on every change.

Debouncing — waiting for input to "settle" before acting on it — is exactly the kind of fiddly useEffect + timer logic you don't want to rewrite in every search box.

Custom hooks can call other hooks — including other custom hooks. useFetch below composes useState and useEffect into a single reusable data-fetching hook with loading/error/success states baked in.

Custom hooks still have to follow the same Rules of Hooks as built-in ones, because under the hood they're calling useState/useEffect just like any component would:

• Only call hooks (custom or built-in) at the top level — never inside conditions, loops, or nested functions
• Only call hooks from React function components or other custom hooks — never from a plain utility function
• Name every custom hook starting with use so linters and other developers can enforce these rules on it too

// ❌ BAD: the linter can't tell this calls hooks, rules won't be enforced
function toggle(initial) {
  const [value, setValue] = useState(initial); // breaks the rules silently
  return [value, () => setValue(v => !v)];
}

// ✅ GOOD: the "use" prefix is what makes it a recognized hook
function useToggle(initial) {
  const [value, setValue] = useState(initial);
  return [value, () => setValue(v => !v)];
}

// ❌ BAD: every remount adds another listener that's never removed
function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);
  useEffect(() => {
    window.addEventListener("resize", () => setWidth(window.innerWidth));
  }, []);
  return width;
}

// ✅ GOOD: return the cleanup function from useEffect
useEffect(() => {
  const handler = () => setWidth(window.innerWidth);
  window.addEventListener("resize", handler);
  return () => window.removeEventListener("resize", handler);
}, []);

// ❌ BAD: one hook handling auth AND theme AND cart — hard to reuse or test
function useEverything() { /* ...200 lines... */ }

// ✅ GOOD: small, focused hooks that compose
function useAuth() { /* ... */ }
function useTheme() { /* ... */ }
function useCart() { /* ... */ }

Build a useOnlineStatus() custom hook that:

• Returns a boolean tracking navigator.onLine
• Subscribes to the browser's online and offline window events
• Cleans up both listeners when the component using it unmounts
• Is reused in two places at once — a header badge and a "you're offline" banner — to prove they share nothing but the pattern

Keep practicing! 💪 Custom hooks are where React composition really shines — once you start noticing repeated useState/useEffect pairs, extracting them makes every component that uses them shorter and easier to trust.