[Jcampuzano2]

This is categorically false. If you want to update props in a stateful component it is exactly the same - just pass new props.

If you instead are talking about syncing props with state, there are ways to do this as well without changing the key, but this is considered an anti-pattern in the first place.

This sounds more like bashing react without even knowing it very well in the first place.

[interlocutor]

> This is categorically false. If you want to update props in a stateful component it is exactly the same - just pass new props.

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

[ratww]

This whole article is about an edge case where components have an internal "draft" state and an external "final" state, where both represent the exact same thing, and you want internal state to change when props change. This, in itself, would be an anti-pattern in any kind of programming, reactive or not.

What the author is trying to convey is that using getDerivedStateFromProps is not the best idea, and there are two simpler ways of doing it. The first solution (only keeping the state in one place) is the better one.

About the solution you're repeating all over the thread, anyone using React will notice that the "key" change solution you're talking about only works for trivial cases: it doesn't work in practice if you have more internal state in the component. It does work perfectly fine if you only have one single piece of internal data.

This is of course a past worry. All this is much simpler to solve by using Hooks.

But the important lesson here is maybe that one shouldn't judge whole Frameworks by advanced articles about edge cases written 4 years ago that require more experience with the framework than you have.

[interlocutor]

Nothing has changed in the last 4 years. Any time you have props and state, updating props is best done by replacing the component by changing the key. If you think hooks has fixed this, you are welcome to point to an article or code that demonstrates that.

All of this complexity is completely unwarranted, which is the point of the article at the subject of this thread. You can do it with simple vanilla js and it is easier. Javascript developers tend to buy into frameworks too easily without realizing the framework is making some things more complicated than without any framework.

[ratww]

> Any time you have props and state, updating props is best done by replacing the component by changing the key

No, it isn't. This is a ludicrous statement.

Replacing the key will RESET the internal state of children objects. Meaning you can't use this workaround for any component that has any kind of internal state does not come from props.

See for yourself: https://codesandbox.io/s/compassionate-williamson-qezsw5?fil...

On the other hand, it is completely trivial to update props that don't affect internal state. This article is only about updating props that affect internal state of components that don't have any other internal state.

> All of this complexity is completely unwarranted

No. All of this complexity you're complaining about exists for one very specific edge case, and this edge case exists in non-reactive frameworks too. You're just extrapolating the complexity of one single edge case to the whole framework.

[recursive]

If you pass new props, it swaps out the whole instance of the element in the document. Probably.

[droidist2]

What's more, if you want it to only do this when passed new props and not at other times, you have to use things like React.memo:

"If your component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result."

https://reactjs.org/docs/react-api.html#reactmemo

[Jcampuzano2]

But it doesn't do this is my whole point. React will not blow away the entire DOM in the document even if props change.

It will correctly keep your scroll position, caret position, etc. if you use React the way it's intended to be used, which is very easy to do and learn. Of course if you use the `key` prop to blow away the entire DOM with every change all these benefits are lost, but thats not react's fault, its your own.