You might not need an effect

If you can compute it from props and state during render, it is not state — and it must not live in an effect. The classic anti-pattern stores a derived value in useState and keeps it current with an effect. That’s two renders per change (set the source, effect runs, set the derived, render again), a window where the two disagree, and a whole dependency array to get wrong. The fix is to compute it inline while rendering.

// ❌ derived state synced by an effect: extra render, can go stale
function FullName({ first, last }: { first: string; last: string }) {
  const [full, setFull] = useState("");
  useEffect(() => { setFull(`${first} ${last}`); }, [first, last]);
  return <h2>{full}</h2>;
}

// ✅ just compute it — always consistent, one render
function FullName({ first, last }: { first: string; last: string }) {
  const full = `${first} ${last}`;
  return <h2>{full}</h2>;
}

The render is the synchronization. Any time you catch yourself writing setSomething inside an effect whose only inputs are other props/state, you almost certainly want a plain const.

Transforming data for display is the same anti-pattern with a list instead of a string — and the same fix. Filtering, sorting, mapping a fetched array into view-models: none of that touches an external system, so none of it belongs in an effect. Compute it in render. If — and only if — profiling shows the transform is genuinely expensive and runs on every unrelated render, wrap it in useMemo. useMemo is a render-time cache, not an effect; it never causes the double-render-then-flash that the effect version does.

// ❌ effect mirrors a derived list into state
const [visible, setVisible] = useState<Todo[]>([]);
useEffect(() => {
  setVisible(todos.filter((t) => t.status === filter));
}, [todos, filter]);

// ✅ derive in render; memoize only if profiling says the filter is hot
const visible = useMemo(
  () => todos.filter((t) => t.status === filter),
  [todos, filter],
);

Reach for useMemo because a measurement told you to, not reflexively. An un-memoized .filter() over a few hundred rows is fine, and a useMemo everywhere is just noise that hides the one that matters.

To reset state when a prop changes, give the component a key — don’t reset it from an effect. A common shape: a profile editor holds draft state, and an effect clears the draft whenever userId changes. That effect renders the old user’s draft for one frame before the reset lands, and it has to enumerate every piece of state to clear. React already has a primitive for “this is conceptually a different instance now”: change the key, and React unmounts the old subtree and mounts a fresh one with initial state. No effect, no stale frame, no enumeration.

// ❌ effect resets local state on identity change — flashes the old draft
function Editor({ userId }: { userId: string }) {
  const [draft, setDraft] = useState("");
  useEffect(() => { setDraft(""); }, [userId]); // also: forgot the other 3 fields
  /* ... */
}

// ✅ key makes React remount a fresh instance — all state resets, atomically
function EditorBoundary({ userId }: { userId: string }) {
  return <Editor key={userId} userId={userId} />;
}
function Editor({ userId }: { userId: string }) {
  const [draft, setDraft] = useState(""); // starts clean per userId, no effect
  /* ... */
}

The key lives one level up, on the parent that decides identity. This is the single highest-leverage effect to delete: it removes an entire class of “why is the form showing the previous record’s data” bugs.

Notify the parent, run side effects, and chain updates inside the event handler — not in an effect that watches state. Two related smells live here. First, notifying a parent: an effect that calls onChange(value) after value changes fires on every cause of the change (including parent-driven ones) and lands a render late. Put the call in the handler that caused the change, where you already know the new value. Second, chained updates: setting state A in an effect that watches state B, which sets C in an effect that watches A, is a cascade of extra render passes that’s impossible to follow. Compute the whole next state in the handler and set it in one place.

// ❌ effect mirrors the change up to the parent — extra render, fires on every path
function Toggle({ onChange }: { onChange: (on: boolean) => void }) {
  const [on, setOn] = useState(false);
  useEffect(() => { onChange(on); }, [on]); // and onChange isn't even in deps
  return <button onClick={() => setOn((v) => !v)}>{on ? "On" : "Off"}</button>;
}

// ✅ do both things in the one place that has the new value: the handler
function Toggle({ onChange }: { onChange: (on: boolean) => void }) {
  const [on, setOn] = useState(false);
  function handleClick() {
    const next = !on;
    setOn(next);
    onChange(next); // parent learns immediately, in the same event
  }
  return <button onClick={handleClick}>{on ? "On" : "Off"}</button>;
}

Event handlers run because the user did something; effects run after rendering, for any reason. When the cause is a specific interaction, the handler is the correct home — it’s earlier, it has the new value in hand, and it won’t fire on unrelated re-renders.