Hacker News new | ask | show | jobs
by dragonwriter 1730 days ago
> When the component needs to manage user interactions it needs state, and then if you need to update props you have to make a new instance of the component

That would suck and make React completely unusable, but it isn't true at all. Assuming that there are necessary state/prop interactions to track (sometimes the two arr largely orthogonal, so you don't need this) you might need to add additional state variables to do last value tracking for props, and then do (with useEffect hooks in a function component, for instance) state updates based on prop changes as needed, but you don't need a new instance on prop changes, generally.

1 comments

You made a “you have to do X” claim, and then point to a documentation page that shows you don’t have to, even though it is the recommended pattern.

React works fine with components that don't follow the recommendation, though if you freely mix internal state updates and external updates via props that shouldn't represent instance changes, you can very easily make something unnecessarily difficult to reason about. So the recommended pattern of either doing a fully-controlled or fully-uncontrolled component is a sensible recommendation that makes sense to guide design. But nothing will break and the React cops won't arrest you if you use props driving state, though if you do too much of that whoever had to maintain your code may be upset.

I am assuming you're debating in good faith (and not just trying to win an argument). The recommendation made in the docs is very well justified. All other techniques are a mess, and lead to maintenance problems and bugs. Just replace the component by changing the key... you can thank me later.