Detailed explanation
Props and state both provide data that a React component uses to render its interface, but they differ in ownership and how updates happen. Props are inputs supplied by a parent, such as labels, configuration values, objects, or callback functions. The receiving component treats them as read-only. This makes components reusable: the same Counter can increase by one or five depending on its step prop. Read-only does not mean props never change; a parent can supply different values on a later render.
State is a component’s memory across renders. In a function component, useState declares a state value and provides a setter to request updates. In the example, step is a prop, while n is state initialised to zero. Clicking the button requests that n increase by step. Importantly, state should not be described as data that the component directly mutates. Use setN to replace the value; for objects and arrays, create updated copies instead of changing the existing state object.
Under the hood, React preserves state between renders and processes queued state updates to calculate subsequent render output. Each render sees a snapshot of props and state, so calling setN does not immediately change n inside the currently running event handler. React may batch updates, and an update to the same value can be skipped using an Object.is comparison. Because the counter’s next value depends on its previous value, setN(previous => previous + step) is the safer pattern when updates may be queued together. Rendering also does not necessarily mean changing the DOM; React commits only the changes needed.
In interviews, explain the distinction through data flow: parents pass props down, and components request changes through state setters or callbacks. If multiple components need the same changing data, move that state to their closest common ancestor and pass values and handlers as props. Interviewers usually look for clear ownership, immutable updates, and awareness that both new props and state updates can affect rendered output.
Key points to remember
- Props are parent-supplied inputs; the receiving component must not modify them.
- State is component memory preserved by React between renders.
- Props can change when a parent supplies new values; read-only does not mean constant.
- State setters queue updates rather than changing the current render’s state snapshot.
- Use functional updates when next state depends on previous state, and lift shared state to a common ancestor.
Common mistakes candidates make
- Saying state is directly mutated, or modifying state objects and arrays in place.
- Assuming props never change because they are read-only.
- Expecting a setter to immediately change the state variable inside the current event handler.
Likely follow-up questions
Can a child component change a parent’s state?
A child can invoke a callback passed by its parent as a prop. The parent’s callback updates the parent-owned state, preserving clear ownership and one-way data flow.
Why prefer setN(previous => previous + step) over setN(n + step)?
The functional form receives the pending state when React processes the update queue. It avoids losing increments when several updates depend on the previous value, although the original form works for the single update in this example.
Should a component copy props into state?
Usually not: derive values directly from props when possible to avoid duplicated data becoming inconsistent. Copying a prop into initial state can be appropriate for an independently editable draft, but later prop changes do not automatically update that state.
Interview tip: Start with ownership and read-only props, explain step versus n in the Counter example, and finish with the functional setter pattern.