Effect-as-derived-state

The shape to recognize: an effect whose only job is setState from other state or props. No subscription, no fetch, no DOM API, no timer — just one piece of React state being mirrored into another. The moment you see this, the effect is a candidate for deletion.

function ProfileForm({ user }: { user: User }) {
  const [firstName, setFirstName] = useState(user.firstName);
  const [fullName, setFullName] = useState("");

  // anti-pattern: this effect's only job is setState-from-state
  useEffect(() => {
    setFullName(firstName + " " + user.lastName);
  }, [firstName, user.lastName]);

  return <input value={firstName} onChange={(e) => setFirstName(e.target.value)} />;
}

fullName is not independent state — it is fully determined by firstName and user.lastName. Storing it separately and re-syncing it in an effect is the bug. The test: if you can write the value as a pure expression of props and current state, it is derived, not state.

Why it’s wrong, mechanically: an extra render and a stale tick. React renders with the new firstName, then paints, then runs the effect, which calls setFullName, which schedules a second render. Between those two renders there is a frame where firstName is “Taylor” but fullName still reads “Jordan Smith”. For a fraction of a second the UI is internally inconsistent — a real, observable flash of stale data, plus double the renders.

// render 1: firstName="Taylor", fullName="Jordan Smith"  ← stale, painted
// effect runs → setFullName("Taylor Smith")
// render 2: firstName="Taylor", fullName="Taylor Smith"  ← finally correct

It gets worse the moment a second derived value depends on the first, because each effect adds another tick of delay, and the deps arrays start to drift out of sync with each other. This is not a performance nitpick — it is a correctness bug that happens to also be slow.

Fix #1 — compute it during render. No state, no effect. A value that is a pure function of props and state should be calculated inline. There is no stale tick because there is no second render: the value is always derived from the inputs that produced the current render.

function ProfileForm({ user }: { user: User }) {
  const [firstName, setFirstName] = useState(user.firstName);
  const fullName = firstName + " " + user.lastName; // derived, always fresh

  return <input value={firstName} onChange={(e) => setFirstName(e.target.value)} />;
}

Two useState became one, the effect is gone, and the inconsistency window is gone with it. If the computation were genuinely expensive (sorting ten thousand rows on every keystroke), you’d wrap it in useMemo — but useMemo is still render-time derivation, not an effect. Reach for it only when profiling shows the cost is real; for string concatenation and ordinary filters, plain render-time computation is correct and cheaper than the memo bookkeeping.

Fix #2 — when a prop change should reset internal state, use a key, not an effect. A close cousin of the anti-pattern is “when userId changes, clear the draft and selection.” People reach for an effect that resets several useStates. That has the same stale-tick problem and is easy to get partially wrong. Instead, give the subtree a key tied to the identity that should reset it — React unmounts and remounts it, resetting all its state in one shot, during the same commit.

// anti-pattern: effect mirrors prop change into a state reset (stale tick + partial-reset bugs)
useEffect(() => { setDraft(""); setSelection(null); }, [userId]);

// fix: identity change → remount → all internal state resets atomically
<ProfileEditor key={userId} userId={userId} />

The key approach scales: it resets all state in the subtree, including state you’d forget to reset by hand, with no extra render and no flash. Use it whenever “this prop changed, so start fresh” is the real intent.