Lesson 18 of 80

State Colocation & Derived State

Q: Why is 'syncing state with useEffect' usually an anti-pattern, and what is state colocation?

A strong answer covers: If a value can be computed from existing props/state, computing it during render is correct — storing it separately and syncing via useEffect causes a stale render plus an extra re-render; State colocation: keep state in the lowest/most specific component that needs it, rather than lifting it unnecessarily high; Colocation reduces re-render scope without needing memoization, since unrelated ancestors/siblings aren't forced to re-render.

The single highest-leverage React habit: if a value can be computed from state you already have, it isn't state — computing it during render beats syncing it with an effect, every time.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

What's the test for whether a value should be its own useState, versus computed during render?

Can it be computed from state/props you already have, right now, during render?Is the value a number rather than an object?Will the value change more than once per session?

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on State Colocation & Derived State

What interviewers actually ask about this, and what a strong answer has to cover.

Why is 'syncing state with useEffect' usually an anti-pattern, and what is state colocation?

A strong answer covers

If a value can be computed from existing props/state, computing it during render is correct — storing it separately and syncing via useEffect causes a stale render plus an extra re-render
State colocation: keep state in the lowest/most specific component that needs it, rather than lifting it unnecessarily high
Colocation reduces re-render scope without needing memoization, since unrelated ancestors/siblings aren't forced to re-render

Likely follow-ups

When would useMemo be appropriate for a derived value, versus just computing it inline?
Give an example of a value that genuinely must be its own state, not derived.
How does lifting state up too eagerly hurt performance, concretely?

Practice these with the AI interviewer →

The plain-language idea

Derived state is a value that can be calculated from other state or props. The mistake is storing it as its own useState and then writing an effect to keep it "in sync":

// 🐛 unnecessary state + effect
function Cart({ items }) {
  const [total, setTotal] = useState(0);
  useEffect(() => {
    setTotal(items.reduce((sum, i) => sum + i.price, 0));
  }, [items]);
  return <p>{total}</p>;
}

// ✅ just compute it during render
function Cart({ items }) {
  const total = items.reduce((sum, i) => sum + i.price, 0);
  return <p>{total}</p>;
}

The first version has a real bug hiding in it: after items changes, there's a render where total is still the old value (state hasn't caught up yet), followed by an effect firing, followed by a second render with the correct value. The second version is simply always correct, has no extra render, and has no state to keep in sync in the first place.

Derived state: compute it, don't store and sync itStep 1 of 3

useState for items, then ANOTHER useState for total kept in sync via useEffect — two sources of truth that can drift.

Colocation: state lives as close as possible to where it's used

State colocation is the related habit of keeping state in the lowest (most specific) component that needs it, rather than lifting everything to a shared ancestor "just in case." A search box's isFocused flag belongs in the search box, not in the page-level state — lifting it up only means more of the page re-renders on every keystroke, for no benefit.

Watch out

"Syncing state with an effect" is one of the most common real anti-patterns in React codebases — React's own docs specifically call this out as a case where useEffect is very likely the wrong tool.
Colocating state reduces re-render scope for free — no memoization needed, because the state that changes simply doesn't live high enough in the tree to force unrelated siblings to re-render.
Not everything can be derived. State that came from a user action and isn't computable from anything else (the actual text a user typed) is genuinely state — the anti-pattern is specifically storing something that's a pure function of other state.

Why this matters in interviews

"Why would you avoid using useEffect to sync one piece of state with another?" is a question that separates candidates who've only used hooks from ones who've internalized React's actual mental model — computing during render, not syncing after the fact.