Almost every developer we onboard onto a React codebase asks some version of the same question in their first week: when do I use props, and when do I use state?
The explanation that seems to click fastest is ownership. Props are handed down from a parent — a component receiving props should treat them as read-only input, the same way a function treats its arguments. State is something a component owns and manages itself, and only that component (or its children, via callbacks) should ever change it. If you find yourself wanting to reassign a prop inside a component, that is usually a sign the value should have been copied into local state in the first place, or that the change belongs in the parent instead.
A good rule of thumb we give new hires: if a value can be computed from props, it should not be state at all. A component that receives a list of items as a prop and wants to display a filtered version of that list does not need filtered items in state — it needs a plain variable computed on every render, or a memoized value if the computation is expensive. Storing a derived value in state invites it to drift out of sync with the props it was derived from, which is one of the most common sources of stale-UI bugs we see in code review.
If two sibling components both need the same piece of data, that data usually belongs in their common parent's state, passed down as props to both. We walk new developers through a concrete example: a shopping cart total needed by both a mini-cart icon in the header and a full cart page. Duplicating that total in both components' own state, updated independently, is exactly the kind of setup that quietly drifts out of sync the first time someone forgets to update one of the two copies. Lifting the total (or the cart items it is computed from) up to the nearest common ancestor and passing it down removes the possibility of drift entirely.
Getting this distinction right early saves a lot of debugging later, when state that should have lived in one place is instead duplicated across three components and quietly drifting out of sync. We have started using this exact framing — "could this be a prop instead?" — as one of our standard code review questions, and it catches a meaningful number of these issues before they ship rather than after a support ticket comes in about a UI that shows two different numbers for the same thing.