[interlocutor]

React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might as well use vanilla js instead of React.

What does using Vanilla JS look like? Here's an example: https://github.com/wisercoder/eureka It uses two tiny 500-line libs. It uses TSX files, just like React. It has components, just like React. It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.

[kikki]

This is either a fundamental misunderstanding of React, or you're actually talking about a different library.

> React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React

React components are designed with state in mind. When state changes, components passed that state in the form of props are re-rendered. Don't take my word for it though, from the first paragraph on the reactjs.org website; "React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes."

> At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish.

I have never heard these spouted as the benefits of React. The main fundamental philosophy of React is that only components that have state changing "react" to changes - in other words, the benefits of React are: no unnecessary re-rendering (hence the virtual DOM).

> If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key

This part just threw me, if you are doing it this way - you are doing it wrong.

[interlocutor]

> When state changes, components passed that state in the form of props are re-rendered.

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

> I have never heard these spouted as the benefits of React.

You will find this if you read enough of React developers' blogs. JavaScript and DOM these days are fast enough that most pages can completely re-render the page and replace the whole DOM in one shot and you won't be able to tell the difference. The downside of doing that is that you lose focus, selection, scroll position, etc. So preserving those things is the benefit of React.

[tentacleuno]

> Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key.

Do you have any concrete examples for this? I'm not sure I agree: I've made plenty of stateful components in React and they are just fine. If anything, they're a lot cleaner than what I could do in plain JavaScript, thanks to the framework.

Further, could you expand on what you mean re: recommending changing the key? I have never heard the React team suggesting to do this, although maybe I missed something in the documentation :-)

[kall]

Wait isn't state the whole point of react? What level of interactivity are you talking about? State and props, that's it's thing: you can always update them.

I've only need the "change key to flush components" trick very few times, and most of those where rush fixes for bugs that had a better "doing it right" fix at a different level.

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

[dragonwriter]

> Stateful components don't work so well in React.

They work fine, though managing state outside of components via a state management library is common.

> If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key.

Where do you find this recommendation? I’ve never seen anything like it, and keys are usually only used for repeating sets of elements, and you would generally only use a different key if something is not the same logical entity as the thing that previously had the key.

There might be some cases where you want to force a new rather than updated component by the kind of key manipulation you describe, but it's not the general case of prop updates for stateful components.

> It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.

React does have incremental updates for interactive, stateful components. You can deliberately negate it the way you’ve described, but you should not, generally.

[interlocutor]

> Where do you find this recommendation?

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

> keys are usually only used for repeating sets of elements

Not true at all!

[Lutger]

From the blog you posted:

> In most cases, this is the best way to handle *state that needs to be reset*

You are talking about updating state, react author is talking about resetting. That's a big difference.