React custom hooks: How to fix stale closures for good

We’ve all been there: you build a slick custom hook to handle an API poll or a socket connection, but the internal callback keeps logging state values from three renders ago. It’s the classic "stale closure" trap, and it’s the most common reason developers end up fighting React useEffect dependencies until they just disable the linter.

When you define a function inside a hook, it captures the variables from that specific render scope. If that function is passed to a timer or an event listener, it stays "frozen" in time, oblivious to any state updates that happen later.

Why Stale Closures Happen in Custom Hooks

The issue isn't React being "broken"; it's how JavaScript closures work. When you write a useEffect that depends on a piece of state, the hook creates a closure over that state variable. If you don't include that variable in the dependency array, the effect never re-runs, and the closure remains locked to the initial value.

We first tried solving this by simply adding every missing variable to the dependency array, but that triggered infinite loops in our state management logic. It's a common hook pitfalls moment where you realize that "fixing the linter" isn't the same as "fixing the architecture."

Fixing Stale Closures with useRef

The most reliable way to ensure your hook always sees the "current" state without re-triggering effects is the useRef pattern. By keeping a mutable reference to the latest state, your callbacks can always reach into that ref to grab the most recent data.

Here is how we typically implement a "latest value" pattern in our production hooks:

JAVASCRIPT
import { useState, useEffect, useRef } from CE9178">'react';

function useLatest(value) {
  const ref = useRef(value);
  
  useEffect(() => {
    ref.current = value;
  }, [value]);
  
  return ref;
}

By wrapping your state in useLatest, you can call latestValue.current inside any callback, and it will always point to the most recent render's data. This is particularly useful when you're dealing with React hooks stale closures in complex event handlers.

When to Use Functional Updates

Sometimes, you don't need a ref at all. If you're updating state based on a previous value, React’s functional state updates are your best friend. Instead of relying on a variable that might be stale, you pass a function to your setter:

JAVASCRIPT
// Avoid this:
setCount(count + 1); 

// Do this instead:
setCount((prev) => prev + 1);

This functional approach is much cleaner for simple react state management scenarios. It effectively bypasses the stale closure issue because React guarantees that the prev argument is the most current state available at the time of the update.

Comparing Closure Fixes

Designing Better Hooks

If you find yourself constantly battling stale closures, it’s often a sign that your react custom hooks are trying to do too much. Keep your hooks focused on a single responsibility. If you need to coordinate multiple pieces of state, consider whether a useReducer might be a better fit than managing five individual useState calls.

I’m still experimenting with custom "event-aware" hooks that automatically track the latest callback via a ref, but I’m cautious about over-engineering. For now, the useRef pattern combined with functional updates handles about 95% of the cases we see in our codebase. Don't be afraid to keep it simple—sometimes the best fix for a stale closure is just restructuring the component so the closure isn't needed in the first place.