State, props and how React re-renders

Almost every React bug in a screening comes down to one idea: a component is a function that React calls again whenever its state or its parent changes. Each call is a render, and each render sees a fixed snapshot of state.

Props down, events up

Props are inputs from the parent and should be treated as read-only. State is data a component owns and changes with its setter. When a child needs to change something, the parent passes a callback:

<SearchBox value={query} onChange={setQuery} />

If two siblings need the same data, lift the state to their closest common parent. Keeping two copies in sync with effects is a common mistake reviewers look for.

State updates are scheduled

Calling setCount(count + 1) does not change count on the next line. It asks React to render again with a new value. Inside one event handler, three calls of setCount(count + 1) all use the same snapshot, so the result is 1. When the new value depends on the old one, use an updater: setCount(c => c + 1).

Never mutate state

React decides whether to re-render by comparing references. Pushing into an array or changing an object field keeps the same reference, so React may skip the update. Create new values instead:

• Add: setItems([...items, newItem])
• Remove: setItems(items.filter(i => i.id !== id))
• Update a field: setUser({ ...user, city: 'Pune' })

Controlled inputs and what renders

A controlled input takes its value from state and updates it in onChange. Set value without onChange and the field becomes read-only. When a component re-renders, all its children render too unless wrapped in React.memo with unchanged props. That is normal and usually cheap; measure before optimising. Also watch conditional rendering: {count && <List />} prints 0 when count is 0, so compare with count > 0.

Habit: when a value looks wrong, ask which render you are looking at and what the state snapshot was in that render. That one question explains most surprises.