Lesson 77 of 80

Common React Anti-Patterns

Q: I'm going to describe a component: it takes a user prop and copies user.name into local state with useState, mutates an items array directly before calling setItems, and renders list rows keyed by their array index. What's wrong with each part, and how would you fix it?

A strong answer covers: Copying a prop into state creates a stale duplicate that doesn't update when the prop changes later — read the prop directly, or key the component to intentionally reset it; Mutating state before calling the setter passes back the same reference, so React's change check bails out and skips the re-render; Index-based keys break identity tracking across reorders/insertions/deletions, misattributing local row state to the wrong item; Names the general principle underlying all three: React decides what to keep or discard by reference/type identity, not by inspecting the data.

Most React bugs aren't exotic — they're the same handful of habitual mistakes, worn smooth by repetition. Recognizing the shape is most of the fix.

14 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.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

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 Common React Anti-Patterns

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

I'm going to describe a component: it takes a user prop and copies user.name into local state with useState, mutates an items array directly before calling setItems, and renders list rows keyed by their array index. What's wrong with each part, and how would you fix it?

A strong answer covers

Copying a prop into state creates a stale duplicate that doesn't update when the prop changes later — read the prop directly, or key the component to intentionally reset it
Mutating state before calling the setter passes back the same reference, so React's change check bails out and skips the re-render
Index-based keys break identity tracking across reorders/insertions/deletions, misattributing local row state to the wrong item
Names the general principle underlying all three: React decides what to keep or discard by reference/type identity, not by inspecting the data

Likely follow-ups

For the stale prop-into-state bug specifically, when would keying the component actually be the right fix versus the wrong one?
Would spreading into a new array fix the mutation bug even if you forgot to also change the objects inside it? Why or why not?
What's a case where index-as-key is actually fine, not an anti-pattern?

The plain-language idea

A small set of habits causes a disproportionate share of React bugs, and they tend to look reasonable while you're writing them. None of these require you to know something obscure — they require noticing a familiar shape and reaching for the fix instead.

See it in a real thing: syncing a prop into state

// Anti-pattern: copying a prop into state
function UserPanel({ user }) {
  const [name, setName] = useState(user.name); // only read once, on mount

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

// Fix: let the key decide when to reset, don't duplicate the source of truth
function UserPanel({ user }) {
  return <input defaultValue={user.name} key={user.id} />;
}

useState(user.name) looks like it keeps name in sync with the prop, but useState's argument is only read on the component's first render. If the parent later passes a different user, name silently keeps the old value — the input looks broken, and nothing in the code obviously says why. The fix depends on what you actually want: if the input should reset whenever a genuinely different user is shown, keying the component by user.id tells React to unmount and remount it — a clean reset, not a stale copy. If local edits need to survive the parent re-rendering, that's what an uncontrolled input with defaultValue is for in the first place.

What people usually miss

Watch out

Mutating state directly doesn't trigger a re-render, even though the data technically changed. items.push(newItem); setItems(items) passes back the exact same array reference — React's bail-out check sees no change and skips the update. setItems([...items, newItem]) creates a new reference, which is what the check actually needs to see.
Using an array index as a list key breaks the moment the list reorders, inserts, or deletes — React matches elements by key across renders, and an index doesn't travel with the item it was assigned to. A row's local state (an open dropdown, a focused input) can end up attached to the wrong row after a reorder, even though nothing else about the code looks wrong.
Defining a component function inside another component's body creates a brand-new component type on every single render. React decides "is this the same component as last time" by identity, not by name — a new function reference each render means React treats it as a completely different component, unmounting and remounting it, along with any state or focus it held.

The genealogy: three lessons this track already teaches you to reach for

The stale-name bug is the same problem this track's derived-state lesson names directly: don't duplicate a value you could just read. The index-as-key bug is the direct subject of this track's keys-and-lists lesson. And the remounting component is a consequence of how this track's reconciliation lesson says React actually decides what to keep versus throw away between renders — by type identity, not by what the code visually looks like.