Lesson 80 of 80

Props vs. State: A Decision Guide

Q: How do you decide whether a given piece of data in a component should be a prop, state, or something else entirely?

A strong answer covers: Frames it as an ownership question first: does a parent already have it, or would multiple components need it — if so, it's a prop; Checks whether the value can be fully computed from other props/state already available — if so, derive it inline instead of storing it; Only reaches for state when the value changes within the component itself, in response to something happening there, and the UI needs to reflect that change; Names refs as a distinct third category for values that must persist across renders without triggering one.

Props vs. state isn't a technical distinction — it's a question of who owns a piece of data, and whether it even needs to be stored at all.

12 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 Props vs. State: A Decision Guide

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

How do you decide whether a given piece of data in a component should be a prop, state, or something else entirely?

A strong answer covers

Frames it as an ownership question first: does a parent already have it, or would multiple components need it — if so, it's a prop
Checks whether the value can be fully computed from other props/state already available — if so, derive it inline instead of storing it
Only reaches for state when the value changes within the component itself, in response to something happening there, and the UI needs to reflect that change
Names refs as a distinct third category for values that must persist across renders without triggering one

Likely follow-ups

Give me a concrete example of a value that looks like it should be state at first glance, but is actually derivable and shouldn't be stored.
You said state is for anything that 'changes' — a ref's value can change too. What's actually different?
If two sibling components both need to read and update the same value, where does that value end up living, and why?

Practice these with the AI interviewer →

The plain-language idea

"Should this be a prop or state?" is really three separate questions, and answering them in order avoids most of the back-and-forth: Does a parent already own this value, or would more than one component need it? Then it's a prop — lift it up, pass it down. Can this value be computed entirely from props or state you already have? Then it's neither — derive it inline, and don't give it a slot of its own. Only if the value changes within this component, in direct response to something happening here — a keystroke, a timer, a response coming back — does it earn a useState call.

See it in a real thing: a filtered product list

function ProductList({ products }) {                // prop: owned by the parent, read-only here
  const [searchTerm, setSearchTerm] = useState("");  // state: changes here, from this component's own input

  const filteredProducts = products.filter((p) =>    // derived: recomputed every render, never stored
    p.name.toLowerCase().includes(searchTerm.toLowerCase())
  );

  return (
    <>
      <input value={searchTerm} onChange={(e) => setSearchTerm(e.target.value)} />
      <ul>{filteredProducts.map((p) => <li key={p.id}>{p.name}</li>)}</ul>
    </>
  );
}

All three categories are visible in five lines. products is a prop because ProductList never creates or changes the list itself, only reads what it was handed — some parent component owns the real list. searchTerm is state because it changes in direct response to this component's own user interaction, and nothing outside ProductList needs to know about it moment-to-moment. filteredProducts is neither: it's a pure function of products and searchTerm, both of which already exist. Giving it its own useState would create a second, independent copy of information that's supposed to always match the other two — and the moment someone changes searchTerm through a code path that forgets to also update a filteredProducts state variable, the list on screen and the search box disagree.

What people usually miss

Watch out

The same value can be state in one component and a prop in another — ownership is what decides the category, not something intrinsic to the value. searchTerm is state inside ProductList; the moment a parent needs to read it too, lifting it up turns it into a prop passed down, with the state now living one level higher.
Storing a derived value in state is the single most common mistake this decision guide exists to prevent. It always looks reasonable in the moment — "I'll just cache the filtered list" — and it always creates a second source of truth that state and props alone don't have.
Refs are a real third category, not just "state without a re-render." A value that must persist across renders but should never itself trigger one — a timeout ID, a previous value for comparison — belongs in a ref, not state, precisely because updating it shouldn't cause a re-render at all.

The genealogy: two lessons, one flowchart

This lesson is a practical index into two ideas this track already teaches separately: this track's derived-state lesson covers the "don't store what you can compute" half in depth, and this track's composition lesson covers the "lift it instead of duplicating it" half. Treat this one as the decision tree that ties both principles into a single question to ask before reaching for useState.