How to Store Previous Values with useRef

Some UI needs to know how a value changed, not just what it is now. A "moved up" or "moved down" label compares the current value with the one before it, and that previous value has to come from somewhere. A ref paired with an Effect is a lightweight way to store previous values so you can compare them.

The usePrevious pattern

The idea is simple: keep the old value in a ref, and copy the new value into the ref after every render.

App.jsx

import { useRef, useEffect } from "react";
 
function usePrevious(value) {
  const ref = useRef();
 
  useEffect(() => {
    ref.current = value;
  }, [value]);
 
  return ref.current;
}

During a render, the Effect has not run yet, so ref.current still holds the value from the previous render. The function returns that stale value on purpose.

After React commits, the Effect runs and stores the new value for next time. The first render returns undefined because nothing came before it.

Show a trend as a counter changes

A counter can display whether the number went up or down since the last change, using the usePrevious helper defined above.

App.jsx

import { useState } from "react";
 
function TrendCounter() {
  const [count, setCount] = useState(0);
  const prevCount = usePrevious(count);
  const trend = prevCount === undefined ? null : count > prevCount ? "up" : count < prevCount ? "down" : "same";

The hook returns the value from the previous render, which is exactly what the component needs. The trend then compares the fresh count with that older value.

App.jsx

  return (
    <>
      <p>Count: {count}</p>
      {trend && <p>Moved {trend}</p>}
      <button onClick={() => setCount(count + 1)}>Increase</button>
      <button onClick={() => setCount(count - 1)}>Decrease</button>
    </>
  );
}

After the first click, the label shows whether the count moved up or down. On the first render there is no previous value, so no trend appears. Each later render compares the fresh count with prevCount, which is one render behind by design.

Why the update belongs in an Effect

Writing ref.current = value during render would break the rules of pure rendering, because render output would depend on a write that happens partway through. Moving the write into an Effect keeps render pure and guarantees the ref holds the value of the last completed render.

The Effect has no cleanup because it stores a value rather than starting a subscription or timer. The [value] dependency ensures the ref is refreshed whenever the tracked value changes.

When this pattern is the wrong tool

The ref version is fine for comparing values inside Effects and event handlers. It is awkward when the previous value must drive the screen, because the returned value lags one render behind.

The core tradeoff is the same one covered in useRef vs useState: reach for the ref when nothing visible depends on it.

Common mistakes

• Reading or writing ref.current during render instead of in an Effect.
• Forgetting the dependency array, so the ref is updated on every render even when the value did not change.
• Expecting the first returned value to equal the initial value. The first call returns undefined.
• Using the ref value to render UI, which leads to a one-render lag.

What to learn next

The ref toolkit grows from here. See how to access and measure DOM elements to apply refs to real browser layout.