React Hooks:
The Mental Models You're Missing

1. What Are Hooks, Really? (The "Array" Model)

Hooks are functions that let you "hook into" React's internal systems. But here is the key insight that most tutorials miss: React relies strictly on call order.

Imagine React keeps a clipboard for every component. On that clipboard is a simple list of values.

• The first useState you call is Index 0.
• The second useState is Index 1.
• The useEffect is Index 2.

*(Technically, under the hood, React uses a linked list of Fiber nodes, not a simple array. But the "Array Mental Model" is the best way to visualize why breaking the order crashes your app.)*

2. useState and the "Stale Closure" Trap

The useState hook gives your component memory. But there is one bug that catches every single developer at least once. I call it the Stale Closure Trap.

Picture this: You have a counter. You click a button that sets a timeout to update that counter. You click it 5 times fast. You expect the count to go up to 5. Instead, it stays at 1.

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

  const handleClick = () => {
    // If count is 0 when this function runs, 
    // it effectively captures "0" forever in this scope.
    setTimeout(() => {
      setCount(count + 1);  // Always sets to 0 + 1 = 1
    }, 1000);
  };

  return <button onClick={handleClick}>Add after 1s</button>;
}

3. useEffect: Synchronization, Not Lifecycle

This is the hardest mental shift. We want to think in terms of "Mount," "Update," and "Unmount." Stop it.

Think about Synchronization. The mental model is: "Keep this external thing (API, Title, DOM) in sync with this React state."

useEffect(() => {
  // This runs after render to synchronize the document title
  document.title = `You clicked ${count} times`;
}, [count]); // Only re-sync when 'count' changes

The Strict Mode "Gotcha" (React 18+)

If you are running this in development, you might notice your API calls firing twice. You might panic. "Is my code broken?"

No. React is doing that on purpose. It mounts, unmounts, and mounts again immediately to see if you wrote a cleanup function.

useEffect(() => {
  let cancelled = false;

  async function fetchData() {
    const data = await api.get();
    if (!cancelled) setUser(data);
  }
  
  fetchData();

  // The Cleanup Function
  return () => { cancelled = true; };
}, [userId]);

If your effect breaks when it runs twice, your synchronization logic is flawed. Don't fight the framework; let it teach you resiliency.

4. useRef: The Silent Storage (Bonus)

useState is great, but every time you change it, you ring the doorbell and force the component to re-render. Sometimes, you want to store a value without the re-render.

Enter useRef. Think of useRef as a "Secret Pocket." You can put things in it and take things out, but the component doesn't know you did it, so it doesn't update the UI.

function Timer() {
  const [count, setCount] = useState(0);
  const intervalRef = useRef(null); // The secret pocket

  const start = () => {
    // We store the ID, but we don't need a re-render just to store a number
    intervalRef.current = setInterval(() => {
      setCount(c => c + 1);
    }, 1000);
  };
  
  const stop = () => clearInterval(intervalRef.current);
  // ...
}

5. The Performance Myth (useCallback & useMemo)

I need to have some real talk with y'all. I see so many codebases where every single function is wrapped in useCallback "just in case."

Stop it. useCallback alone does nothing. It does not make your app faster. In fact, it adds memory overhead. It is only useful if the child component you are passing it to is wrapped in React.memo.

// ❌ POINTLESS: Child isn't memoized, so it re-renders anyway
function Parent() {
  const handleClick = useCallback(() => {}, []);
  return <Child onClick={handleClick} />; 
}

// ✅ EFFECTIVE: Child is memoized AND callback is stable
const Child = React.memo(({ onClick }) => <button onClick={onClick}>Click</button>);

function Parent() {
  const handleClick = useCallback(() => {}, []);
  return <Child onClick={handleClick} />; // Child skips re-render ✓
}

6. The Hidden Cost of useContext

We love useContext. It saves us from prop-drilling hell. But there is a hidden cost that nobody talks about.

Context is a nuclear option for state updates. When a Context value changes, every single component that consumes that context re-renders. Even if they only use a tiny slice of data that didn't change.

// ⚠️ WARNING
const AppContext = createContext();

function ThemeToggle() {
  // If 'searchQuery' changes in the Provider, THIS component re-renders
  // even though it only cares about 'theme'.
  const { theme } = useContext(AppContext); 
  return <button>{theme}</button>;
}

The Logic Behind The Magic

1. The Array Model (Why Hooks Can’t Be Conditional)

You can't call hooks conditionally because React relies on call order to identify state. React has a clipboard with a list: [State A, State B, Effect A]. If you hide State A behind an if (false), React tries to assign State B's data to State A's slot. The entire index mapping shifts, causing data corruption.

2. Stale Closures (Why Your State Isn’t Updating)

JavaScript functions "capture" variables when they are created. This is called a Closure. Think of a render as a "frame" in a movie. When you click a button, that function runs inside Frame 1. Even if the movie moves to Frame 10, that function is still holding onto the data from Frame 1.

3. Synchronization (Why Effects Run Twice)

useEffect is a machine that keeps external systems (DOM, API) in sync with internal state. React 18+ intentionally mounts, unmounts, and remounts your component to ensure your cleanup function works. If your effect creates a subscription but doesn't clean it up, the double-fire exposes the memory leak immediately.

4. useRef (The Secret Pocket)

useState is a doorbell, it rings (re-renders) every time you change it. useRef is a secret pocket. You can put things in and take them out, and React’s rendering engine doesn't even know you did it.

5. The Memoization Equation

useCallback stabilizes the reference of a function. But if the Child component isn't checking for stable references (via React.memo), it re-renders anyway because the Parent re-rendered. Formula: useCallback (Parent) + React.memo (Child) = Performance. One without the other is waste.

6. The "Nuclear" Context

There is no way to "subscribe" to just part of a Context. If the Provider updates value, every consumer re-renders. Don't put currentUser (rare change) and mousePosition (fast change) in the same Context.