Detailed explanation
Lifting state up means moving state from a child component into the closest common ancestor of all components that need to read or update it. That ancestor becomes the single source of truth and passes the current value down through props. Children request updates by calling callback props supplied by the ancestor. This matters when sibling components must stay synchronised: keeping separate copies of the same value creates opportunities for inconsistent UI and unnecessary synchronisation logic.
In your example, Parent owns q using useState(''). Search receives q as its value prop and setQ as its onChange callback, while Results receives q to determine what to display. Search should call onChange with the new string, for example through <input value={value} onChange={e => onChange(e.target.value)} />. This detail matters because a native input's onChange handler receives an event, whereas this custom Search interface expects a string. Search is controlled with respect to its query value: Parent, rather than Search's own state, determines that value.
When the user types, Search calls the callback, which schedules a state update in Parent. React renders Parent again with the updated q and ordinarily renders its children with their new props. React then commits any necessary DOM changes. Both Search and Results therefore use the same query for that render. State is not literally passed upward; an update request travels through a function prop, while data continues to flow downward. This preserves React's one-way data flow and makes ownership and debugging easier to understand.
Lift state only as far as necessary. If only Search needs a local UI detail, such as whether its suggestion panel is open, that state can remain inside Search. Values computable from existing props or state usually should not become additional state. For deeper trees, Context can distribute the shared value and update functions without passing them through every intermediate component, but it does not remove the need for clear ownership. Interviewers typically check whether you can identify the correct owner, explain controlled components, and avoid duplicating shared state or moving everything to the application root.
Key points to remember
- Place shared state in the closest common ancestor of its consumers.
- Keep one authoritative copy of each shared value.
- Pass values downward through props and update callbacks to children.
- A controlled child displays the value supplied by its parent.
- Keep unrelated local state near the component that uses it.
Common mistakes candidates make
- Keeping duplicate query state in Search and Parent, then using effects to synchronise them.
- Moving all state to the application root instead of the nearest suitable ancestor.
- Passing the native input event to setQ instead of extracting event.target.value.
Likely follow-up questions
How is lifting state up different from prop drilling?
Lifting state up decides which ancestor owns shared state. Prop drilling describes passing props through intermediate components that do not themselves need those values; it can result from lifting state across a deep tree.
Should Results store its own copy of q?
Usually not: Results can read q directly from props. Copying it into local state creates a second source of truth and requires extra logic to keep the copies synchronised.
When should you use Context instead?
Consider Context when many descendants need the same value and passing props through intermediate components becomes cumbersome. State can still live in a common ancestor, with Context distributing its value and update functions.
Interview tip: Use the Search and Results example to trace ownership, props, the callback, and the resulting render in that order.