[flowerlad]

That works well... until you have stateful components and you want to send in new props. At that point the recommended approach is to replace the entire component by using the key property.

For simple components, especially stateless ones, React works well. 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, and that point React has failed in its promise.

[lucasmullens]

> At that point the recommended approach is to replace the entire component by using the key property.

Where did you hear that? React.Component has both props and state and both seem to work pretty well together, and you definitely don't need to destroy the component by changing the key property just because props changed.

[flowerlad]

> Where did you hear that?

https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...

[dragonwriter]

> 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.

[flowerlad]

Please read React documentation:

https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...

[dragonwriter]

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.

[flowerlad]

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.

[econnors]

I'm not sure what you mean, could you clarify? Having a stateful component render something different based on a prop change is core to react. Using the key property "resets" the component by rendering a new one, but just because you use state doesn't mean you can't change props.

[flowerlad]

It is recommended by FB:

https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...

[paavohtl]

What do you expect to happen? You ultimately have to store the state somewhere. Either it lives in the component, or outside of it, or you figure out some strategy to combine the two.

[flowerlad]

Once you realize React doesn't work for complex components it loses its attraction. Web Components are conceptually way simpler and work well. See example:

https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

[crooked-v]

Simpler? I don't see it. That looks way more verbose than a React equivalent component I would write.

[paavohtl]

I don't really see anything here that would be massively more complex in React. And besides, I've been hurt enough times by manual DOM manipulation to never want to do it again for interactive UI. It's a maintainability nightmare.