Controlled vs uncontrolled Modal component

WHAT THIS TESTS The interviewer wants to see whether you understand state ownership and how it ripples into a public component API. A Modal is a perfect probe because dismissal can be triggered from many places: a close button, the backdrop, the Escape key, or the parent reacting to navigation or a save completing.

A GOOD ANSWER COVERS Start by naming the two models. An uncontrolled Modal owns its open state internally and exposes imperative or trigger-based opening; it is convenient for simple cases but the parent cannot force it closed or react to its state. A controlled Modal takes an open prop plus an onClose callback, making the parent the single source of truth. Controlled wins when the parent must coordinate closing on route change, after an async save, or when only one modal may be open at a time. The strongest answer proposes a hybrid: accept defaultOpen for uncontrolled use and an optional open prop that, when provided, switches to controlled mode, mirroring how native inputs work.

COMMON WRONG ANSWERS Saying controlled is always superior ignores ergonomics for trivial cases. Storing the prop value into internal state on mount creates a stale copy that desyncs from the parent. Driving the same render from both internal state and a prop causes flicker because two sources of truth fight.

LIKELY FOLLOW-UPS How do you detect controlled versus uncontrolled at runtime? Check whether the open prop is undefined. How do you warn a consumer who switches modes between renders? How does this pattern generalize to inputs, accordions, and tabs?

ONE CONCRETE EXAMPLE Imagine a checkout flow where saving the address should close the modal only on success. A controlled Modal lets the parent keep open true until the API resolves, then set it false, while showing a spinner inside. An uncontrolled Modal that closed itself on button click would dismiss before the save confirmed, hiding errors from the user.