Props, State, and Who Owns the Value
What’s the difference between props and state in React, and how do you decide which component should own a value? When would you lift state up or avoid state entirely?
what they're testing: The interviewer is testing whether you can place data deliberately and keep one clear source of truth as a component tree grows.
Props are inputs from a parent, while state is memory tied to a component's position in the UI. Treat both as read-only during a render. A parent can pass different props later; to update state, call its setter and React schedules another render.
An owner can pass a value down as a prop with an event handler that lets a child request a change. The child calls the handler, the owner updates its state, and the new value flows back down. When siblings need to stay in sync, lift the value to their closest common parent so they share one source of truth. Otherwise, keep state close to the component that uses it.
Before adding state, ask whether the value must be remembered between renders. If it can be calculated from current props or state, calculate it during render. Storing firstName, lastName, and fullName, for example, creates duplicate facts that can drift apart. Copying a prop into state has a similar risk because later prop changes will not reset that state. It only makes sense when the prop deliberately supplies an initial value and later edits are local.
Why it lands
- Frames the difference around ownership instead of slogans about mutability.
- Explains the full down-and-back update path through props and callbacks.
- Connects lifting state up to a single source of truth.
- Rules out redundant and mirrored state with a concrete example.
Where people slip
- "Props never change, while state does." This misses that a component can receive new props on a later render.
- "The child can update the prop when the input changes." Props are read-only; the owner must handle the change.
- "Anything that changes belongs in app-level state." Local state should stay near its consumers unless it needs sharing.
- "Store `fullName` too so the render is simpler." That duplicates data already derived from `firstName` and `lastName` and can get out of sync.
If they push further
How can a child update a value owned by its parent?
The parent passes the value and an event callback as props. The child calls the callback, and the parent updates its own state.
Where should shared state live?
Start at the closest common ancestor of every component that needs the value. Move it higher only when the sharing boundary genuinely grows.
When is initializing state from a prop reasonable?
It is reasonable when the prop is explicitly an initial value and later edits are intentionally local. Name it accordingly, such as `initialColor`, so later prop changes are not expected to sync.
Sources
- React: Passing Props to a Component ↗react.dev
- React: State: A Component's Memory ↗react.dev
- React: Choosing the State Structure ↗react.dev
- React: Sharing State Between Components ↗react.dev
- React: Components and Hooks Must Be Pure ↗react.dev
Now answer it yourself.
Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.
beta
The interviewer part is in the works.
The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.