React Custom Hooks — Stale Data from Missing Dependencies

React custom hooks are arguably the most powerful pattern introduced since the Hooks API landed in React 16.8. In production codebases, the difference between a component file that is 500 lines long and one that is 80 lines long often comes down to whether the team knew how to extract logic into custom hooks. They are not syntactic sugar — they fundamentally change how you architect a React application.

Before custom hooks, sharing stateful logic between components required contorted patterns like Higher-Order Components (HOCs) or render props. Both approaches wrapped your components in extra layers, made debugging a nightmare in DevTools, and created 'wrapper hell' — a tree of nested HOCs that made the component hierarchy almost unreadable. Custom hooks solve this by letting you pull stateful logic out of a component entirely, without changing the component hierarchy at all.

By the end of this article you will know exactly how custom hooks work under the hood, when to reach for them versus other patterns, how to avoid the subtle bugs that senior engineers still trip over, and how to build hooks that are genuinely reusable across projects. You will walk away with production-ready patterns you can apply immediately.

Why Custom Hooks Are the Only Way to Share Stateful Logic in React

A custom hook is a JavaScript function that uses one or more built-in hooks (useState, useEffect, etc.) to encapsulate reusable stateful logic. Unlike a regular function, a custom hook can call other hooks, which means it can manage component lifecycle and local state. The core mechanic is simple: extract repeated logic into a function whose name starts with 'use', and React will treat it as a hook, enforcing the rules of hooks (no conditional calls, call at top level).

In practice, custom hooks are pure functions that return values (state, callbacks, or derived data) to the calling component. They do not share state between components — each call to a custom hook creates an isolated instance of its internal state. This is critical: if you need shared state across components, you must lift state up or use context, not a custom hook. Custom hooks also compose naturally; you can call one hook inside another, building complex behavior from simple primitives.

Use custom hooks whenever you find yourself copying the same useEffect + useState pattern across multiple components. Common examples include form handling, API fetching, debounced input, or window resize listeners. The real value is not just code reuse — it's that you can test and reason about that logic in isolation. Without custom hooks, React components become tangled with infrastructure concerns; with them, components stay declarative and focused on rendering.

The Core Philosophy of Custom Hooks

A custom hook is a JavaScript function whose name starts with 'use' and that may call other hooks. The 'magic' of custom hooks isn't in React's source code, but in the Rules of Hooks. When you extract logic into a function, React treats the hooks inside that function as if they were written directly inside the component calling it. This means state is isolated: if two components use the same custom hook, they do not share state; they share the logic for managing their own independent state.

At TheCodeForge, we treat hooks as the 'Service Layer' of the frontend. Just as a Java backend might have a UserService to handle business logic, a React frontend uses custom hooks to handle stateful logic, leaving components to focus solely on the UI (the 'View' layer).

import { useState, useEffect } from 'react';

/**
 * io.thecodeforge standard useFetch hook
 * Extracts the boilerplate of loading states and error handling
 */
export function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true;
    
    async function fetchData() {
      try {
        const response = await fetch(url);
        if (!response.ok) throw new Error('Network response was not ok');
        const json = await response.json();
        if (isMounted) setData(json);
      } catch (err) {
        if (isMounted) setError(err.message);
      } finally {
        if (isMounted) setLoading(false);
      }
    }

    fetchData();
    return () => { isMounted = false; };
  }, [url]);

  return { data, loading, error };
}

Enterprise Integration: Hooking into the Backend

In a full-stack environment, your hooks often act as the bridge between React's reactive state and your enterprise infrastructure. Whether you are fetching data from a Spring Boot microservice or managing a local Dockerized database for development, your hooks must be resilient. Below is an example of how a custom hook might interface with a Java-based API following our internal naming conventions.

package io.thecodeforge.api;

import org.springframework.web.bind.annotation.*;
import java.util.Map;

@RestController
@RequestMapping("/api/v1/users")
public class UserController {

    @GetMapping("/{id}")
    public Map<String, String> getUser(@PathVariable String id) {
        // Production-grade response structure for useUser hook
        return Map.of(
            "id", id,
            "status", "ACTIVE",
            "role", "SENIOR_ENGINEER"
        );
    }
}

Containerizing the Development Environment

To ensure your custom hooks work consistently across the team, we use Docker to standardize the environment. This prevents the 'it works on my machine' syndrome when testing stateful logic that depends on specific Node.js versions.

# io.thecodeforge Standard React Environment
FROM node:20-alpine

WORKDIR /app

# Standard caching for node_modules
COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["npm", "start"]

When to Extract a Custom Hook — The Mental Model

Not every piece of logic deserves its own hook. The rule of thumb: if a component contains stateful logic that you might reuse in another component OR the logic makes the component harder to read (e.g., a 50-line block of state initialisation + side effects), extract it. If the logic is a pure computation (e.g., formatDate), use a regular function. A custom hook is justified when it uses React hooks (useState, useEffect, useContext, etc.) or when you want to encapsulate a repeating pattern of state + side effects.

A good test: if you can name the pattern (e.g., 'useDebounce', 'useMediaQuery', 'useLocalStorage'), it's a candidate. If the hook would only ever be used in one component and is less than 15 lines, keep it inline.

import { useState, useEffect } from 'react';

/**
 * io.thecodeforge useDebounce hook
 * Debounces a value by the given delay (ms)
 */
export function useDebounce(value, delay = 300) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

Advanced Patterns: Composing Hooks

Custom hooks can call other custom hooks. This is composition — the most powerful aspect of the pattern. For example, you can build a useUserProfile hook that internally uses useFetch and useLocalStorage to cache results. The consumer component sees a single hook call but gets the combined behaviour. This keeps your component tree flat while logic is layered.

Here's a pattern: a hook that fetches data and automatically caches it. It composes useFetch and useLocalStorage. The cache is per-user, so each profile call gets its own storage key.

import { useState, useEffect, useCallback } from 'react';
import useFetch from './useFetch'; // io.thecodeforge useFetch
import useLocalStorage from './useLocalStorage'; // Assume exists

/**
 * io.thecodeforge useCachedFetch hook
 * Fetches data and caches result in localStorage
 */
export function useCachedFetch(url, cacheKey) {
  const { data, loading, error } = useFetch(url);
  const [cachedData, setCachedData] = useLocalStorage(cacheKey, null);

  useEffect(() => {
    if (data) {
      setCachedData(data);
    }
  }, [data, setCachedData]);

  const clearCache = useCallback(() => {
    setCachedData(null);
  }, [setCachedData]);

  // Return cached data immediately if available, then live data
  return { data: data || cachedData, loading, error, clearCache };
}

Performance Traps and Memoization Inside Hooks

Custom hooks are functions that run on every render of the calling component. This means every variable, function, or object you define inside the hook body is recreated on every render. If you return those objects to the component, they change references each time, causing any downstream effect that depends on them to re-fire — even if the logical value didn't change.

To prevent this, wrap stable return values in useMemo and stable callback functions in useCallback. This is especially important when the hook is consumed by a component that is wrapped in React.memo.

import { useState, useEffect, useCallback } from 'react';

/**
 * io.thecodeforge useMousePosition hook
 * Tracks mouse position and returns stable references
 */
export function useMousePosition() {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  const handleMouseMove = useCallback((event) => {
    setPosition({ x: event.clientX, y: event.clientY });
  }, []);

  useEffect(() => {
    window.addEventListener('mousemove', handleMouseMove);
    return () => window.removeEventListener('mousemove', handleMouseMove);
  }, [handleMouseMove]);

  return position;
}

The Hidden Complexity: Browser API Hooks Without Third-Party Bloat

You don't need npm install for clipboard, intersection observer, or device detection. But rolling your own browser API hooks is where 90% of developers introduce bugs that only surface in production.

Let's talk about useCopyToClipboard. Every junior grabs copy-to-clipboard and calls it done. That works until your app runs in an iframe, a service worker context, or a browser that's locked clipboard behind a user gesture requirement. The real hook doesn't just copy text; it signals success, failure, and the transient state between.

Here's why you need this: when a user clicks "copy" they expect visual feedback. If your hook returns a boolean after the async write, you'll re-render unnecessarily. Instead, return the actual transient state — idle, copying, copied, error. That lets your component render exactly one class change, not a cascade.

And the timer? Don't hardcode it. Expose it as a parameter so your team can override it per use case without touching hook internals.

// io.thecodeforge — javascript tutorial

import { useState, useCallback } from 'react';

type CopyStatus = 'idle' | 'copying' | 'copied' | 'error';

export function useCopyToClipboard(resetMs = 2000) {
  const [status, setStatus] = useState<CopyStatus>('idle');

  const copy = useCallback(async (text: string) => {
    setStatus('copying');
    try {
      await navigator.clipboard.writeText(text);
      setStatus('copied');
      setTimeout(() => setStatus('idle'), resetMs);
    } catch {
      setStatus('error');
      setTimeout(() => setStatus('idle'), resetMs);
    }
  }, [resetMs]);

  return { copy, status };
}

// output:
// { copy: ƒ, status: 'idle' }
// On call: status -> 'copying' -> 'copied' (2s) -> 'idle'
// On error: status -> 'copying' -> 'error' (2s) -> 'idle'

SSR is the Silent Killer: Building `usePageBottom` That Survives the Server

Every infinite scroll hook breaks in SSR because window doesn't exist. But the worst pattern is checking typeof window !== 'undefined' at render time — that's a code smell that will cause hydration mismatches and layout shift.

The correct pattern: defer DOM access to useEffect. Yes, your hook won't fire on the server. That's fine. The server doesn't need to know where the bottom of the page is. It delivers HTML; the client hydrates and runs the hook.

But here's the deeper issue: performance. Attaching a scroll listener to window fires on every pixel change. For an infinite scroll, you only need to know when the user is within 200px of the bottom. Use passive event listeners and check scrollHeight - scrollTop - clientHeight — that's a single calculation per frame, not a layout thrash.

And resize? That's a separate concern. Don't put resize listeners inside a scroll listener. Extract them into a useWindowSize hook that returns only width/height, then compose it with usePageBottom . That way each hook has one reason to change.

// io.thecodeforge — javascript tutorial

import { useState, useEffect } from 'react';

export function usePageBottom(bottomOffset = 200) {
  const [isBottom, setIsBottom] = useState(false);

  useEffect(() => {
    function handleScroll() {
      const { scrollHeight, scrollTop, clientHeight } = document.documentElement;
      const reached = scrollHeight - scrollTop - clientHeight <= bottomOffset;
      setIsBottom(reached);
    }

    window.addEventListener('scroll', handleScroll, { passive: true });
    handleScroll(); // check initial state

    return () => window.removeEventListener('scroll', handleScroll);
  }, [bottomOffset]);

  return isBottom;
}

// output:
// false (page not at bottom)
// true (within 200px of bottom)
// false (user scrolled up)

How to Add SSR Support Without Breaking Hydration

Server-side rendering silently breaks hooks that assume a browser environment. The root cause is simple: during SSR, window, document, and EventTarget do not exist. Your hook must detect its environment before touching the DOM. The "how" is a single condition: check typeof window !== 'undefined' or globalThis?.document. Place this check early, and return safe defaults for server render. For hooks like useWindowSize, return { width: 0, height: 0 }. For scroll listeners, return null or a no-op. The trap: developers conditionally run effects but still declare state with browser APIs — hydration mismatches follow. Use useSyncExternalStore from React 18+ for state derived from browser APIs; it naturally handles SSR by returning the initial snapshot on the server. Always test with renderToString or a framework like Next.js before production. This pattern turns SSR from a silent killer into a non-issue.

// io.thecodeforge — javascript tutorial

import { useState, useEffect } from 'react'

export function useWindowSize() {
  const isServer = typeof window === 'undefined'
  const [size, setSize] = useState(() => {
    if (isServer) return { width: 0, height: 0 }
    return { width: window.innerWidth, height: window.innerHeight }
  })

  useEffect(() => {
    if (isServer) return
    const onResize = () => setSize({ width: window.innerWidth, height: window.innerHeight })
    window.addEventListener('resize', onResize)
    return () => window.removeEventListener('resize', onResize)
  }, [isServer])

  return size
}

Wrapping Up: The One Rule for Every Custom Hook

After building hooks for fetching, scroll detection, event listeners, and browser APIs, one rule separates clean code from unmaintainable spaghetti: a custom hook must return only what its consumer needs, never expose implementation details. If you return raw fetch state like { data, loading, error }, name it useFetch. If you return a DOM ref, name it useElementSize. The why is simple — consumers should not need to know if your hook uses useState, useReducer, or useRef. This encapsulation makes refactoring trivial: swap useState for useReducer without touching any component. Second rule: every hook must handle cleanup. If it registers an event listener, it must remove it. If it creates an interval, it must clear it. No exceptions. These two constraints — minimal return values and mandatory cleanup — eliminate 90% of the bugs seen in production React codebases. Your hook is a contract; keep it tight.

// io.thecodeforge — javascript tutorial

import { useState, useEffect } from 'react'

export function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(navigator.onLine)

  useEffect(() => {
    const handleOnline = () => setIsOnline(true)
    const handleOffline = () => setIsOnline(false)

    window.addEventListener('online', handleOnline)
    window.addEventListener('offline', handleOffline)

    return () => {
      window.removeEventListener('online', handleOnline)
      window.removeEventListener('offline', handleOffline)
    }
  }, [])

  return isOnline // only a boolean — consumer never sees navigation or event managers
}

Reusability: The Unseen Engine of Custom Hooks

Reusability in React isn't just about copying less code; it's about abstracting behavioral contracts. A custom hook like useSaveButton encapsulates the state machine of saving: idle, saving, success, error. Without a hook, every save button in your enterprise app repeats the same useState and useEffect logic with a useOnlineStatus check. The result is inconsistent UI behavior across features. By extracting this into a single hook, you enforce a predictable surface area. Every component consuming useSaveButton inherits the same debouncing strategy, retry logic, and offline fallback. This eliminates subtle divergences where one developer forgets the loading spinner or fails to disable the button during an API call. Reusability here means a single source of truth for an entire interaction pattern. The WHY is clear: consistency reduces cognitive load for the next developer who expects every save button to behave identically.

// io.thecodeforge — javascript tutorial
const useSaveButton = ({ onSave }) => {
  const [state, setState] = useState('idle');
  const isOnline = navigator.onLine;
  useEffect(() => {
    const handleOnline = () => setState('idle');
    const handleOffline = () => setState('offline');
    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);
    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []);
  const save = async () => {
    if (!isOnline || state === 'saving') return;
    setState('saving');
    try { await onSave(); setState('success'); }
    catch { setState('error'); }
  };
  return { state, disabled: !isOnline, save };
};

API Requests: The Hidden Tax of Duplicated Fetch Logic

Every save button in a dashboard app typically calls a different API endpoint. Without a custom hook, each developer writes their own fetch call with ad-hoc error handling and loading states. This creates a maintenance nightmare when API response formats change or authentication headers need updating. A custom useSaveButton hook centralizes the request lifecycle: you pass a saveFn (the actual API call) and the hook handles everything else. The WHY is about API standardization. When your backend migrates from REST to GraphQL, you only change the hook's internal request logic, not every button component. Additionally, authentication tokens often expire during a save. By handling token refresh inside the hook, you prevent a class of bugs where the save silently fails because the component forgot to re-authenticate. The hook becomes the single place where API contracts, retry policies, and status codes are managed.

// io.thecodeforge — javascript tutorial
const useApiSave = (saveFn) => {
  const [state, setState] = useState('idle');
  const offline = !navigator.onLine;
  const save = async (data) => {
    if (offline) return setState('offline');
    setState('saving');
    try {
      const token = await getFreshToken();
      const res = await saveFn(data, token);
      if (!res.ok) throw new Error(res.status);
      setState('success');
    } catch { setState('error'); }
  };
  return { state, disabled: offline, save };
};