React interview questions

Props are inputs a component receives from its parent and does not change. State is data the component owns and updates with a setter, which triggers a re-render. For example, a ProductCard gets the product as a prop, while a quantity picker inside it keeps the chosen quantity in state.

The setter schedules a new render; it does not change the variable in the current one. The current function call keeps its snapshot. If I need the new value straight away I compute it into a local variable first, and if the update depends on the previous value I use the updater form.

I use it to sync with something outside React, such as fetching data, subscribing to events or starting a timer, and I return a cleanup. I avoid it for deriving values from props or state, because those can be calculated during render without an extra render pass.

Keys let React match items between renders so it can keep their state and DOM nodes. If I use the index and the list is sorted or filtered, state can stay at a position rather than with the item. I use a stable id from the data.

First I lift it to their nearest common parent and pass it down. If many levels in between only pass it along, I consider context for that value. I reach for a separate state library only when the app has a lot of shared, frequently changing state.

I measure first with the React profiler to see which components render often or take long. Typical fixes are moving state closer to where it is used, memoising an expensive calculation with useMemo, or wrapping a heavy child in React.memo with stable props. I avoid adding memoisation everywhere without evidence.