When should data in a reusable component be a prop or state?

What's really being asked

This question checks whether you can distinguish between data that a reusable component owns and data its parent owns. Interviewers want to see that you think about single-source-of-truth and controlled versus uncontrolled patterns rather than defaulting to convenience. At the senior level, they also care that you consider API stability and how the decision affects the entire application architecture.

The full answer

First, ask who needs to know about the data. If the parent must initialize, read, or react to the value, it should be a prop, often paired with an onChange callback so the parent remains the source of truth. Second, reserve internal state for details that are truly private and ephemeral, such as tracking hover, focus, or internal animation phase. Third, mention that mixing both is valid: a component can accept a prop while maintaining internal state as a fallback, but it should never keep a separate copy that drifts out of sync. Fourth, emphasize that props enable predictable APIs and testability because behavior is explicit, while hidden state creates implicit contracts that break when multiple teams consume the component.

The mistakes people make

A red flag is claiming that reusable components should always use internal state to stay self-contained. This traps data inside the component and prevents parents from controlling it, leading to duplicate state and bugs where the UI does not reflect the application state. Another red flag is suggesting you mirror a prop into state with useEffect, which creates a lagging source of truth and unnecessary complexity. A third red flag is ignoring the possibility of derived state, where you compute values directly from props instead of storing them.

What usually comes next

The interviewer may ask how you handle a component that supports both controlled and uncontrolled modes, or how you prevent prop drilling when many layers sit between the state owner and the leaf component. They might also ask how you test a purely state-driven component versus a prop-driven one, or how TypeScript types change when a prop is optional because the component can manage its own fallback state.

A concrete example

Consider a Modal. Its open or closed status should almost always be a prop, such as isOpen, controlled by the parent, because the parent typically knows when to show it based on routing, form submission, or user clicks. The Modal may still use internal state to track its 300 millisecond closing animation phase or focus trap initialization, but those are implementation details the parent never needs to see. A Tooltip is similar: its visibility might be internal state if triggered purely by mouse enter and leave, but if the product requires showing it programmatically, it should expose an isVisible prop. In both cases, the boundary is simple: if the outside world cares, use a prop; if only the component cares, use state.