Derived State in React: What Not to Store

Derived state in React is any value you can compute from props or existing state during render. Do not store it in its own state variable, because two sources of truth will drift apart. Compute it instead, and it stays correct automatically.

The mistake is common because it feels convenient. A stored copy looks like it saves work, but it creates two values that must be kept in sync by hand, and every edit has to update both.

What derived state is

State should hold only the essential values the UI must remember. Anything that follows from those values is derived, not stored.

A full name is the classic example. It follows from a first name and a last name, so it has no business being its own state variable.

Storing it means every update to either name must also update the full name, and forgetting one update leaves a stale value on screen. The same applies to totals, filtered lists, and anything that is a function of other values.

Compute a value instead of storing it

Derive the full name during render. When either input changes, the next render computes a fresh full name from the new values, with no extra setter call.

App.jsx

function Form() {
  const [firstName, setFirstName] = useState("");
  const [lastName, setLastName] = useState("");
 
  const fullName = firstName + " " + lastName;
 
  return <p>Ticket for {fullName}</p>;
}

Type a name and the ticket line updates immediately. There is no fullName setter to call, because fullName is recalculated on every render from the two names that actually matter. Removing the redundant state also removes an entire class of bugs, because the two halves can no longer disagree.

Do not mirror props in state

A common trap is copying a prop into state so it can be changed later. The state captures only the prop's first value, so later prop changes are ignored and the two copies drift.

App.jsx

function Message({ color }) {
  return <p style={{ color }}>Hello</p>;
}

The broken version copies the prop into state with useState(color), so a new prop value is silently ignored and the first color sticks forever. Reading the prop directly keeps the component in sync with its parent.

If you truly need to freeze the first value, name the prop initialColor so readers understand that later updates are ignored. Otherwise, skip the copy and use the prop.

Keep one copy of shared data

Duplication also appears when you store a whole object alongside a list that already contains it. If a list item can be edited, a separately stored copy of that item goes stale, because only the list version changes.

Store the selected id instead of the selected object. The object is then found from the list during render, so an edit to the list is reflected everywhere at once.

App.jsx

const [selectedId, setSelectedId] = useState(0);
 
const selectedItem = items.find((item) => item.id === selectedId);

The id is the only essential value. The selected item itself is derived from the list, so editing an item updates the selection automatically. This is the same grouping instinct behind one state object vs multiple hooks.

When to recompute or lift

Some derived values are expensive, but that alone does not make them state. Compute first, and only reach for memoization after measuring a real problem.

Do not store the result just to avoid recalculating it. Deriving during render is cheap for nearly every real UI, because React already re-renders when the inputs change.

If a value depends on state that changes together with it, an updater function keeps the calculation tied to the latest value instead of a second stored copy. The fewer stored values, the fewer places that can disagree.

What to learn next

The rule is simple: useState holds what changes on its own, and everything else is computed. Keep the stored values minimal, and the derived values will take care of themselves, staying correct on every render.