5 ms·

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

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

tentacleuno 4y ago
> 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 4y ago
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 4y ago
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.
- recursive 4y ago
  If you pass new props, it swaps out the whole instance of the element in the document. Probably.
  - droidist2 4y ago
    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 https://reactjs.org/docs/react-api.html#reactmemo
  - Jcampuzano2 4y ago
    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.
- interlocutor 4y ago
  > 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-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
  - ratww 4y ago
    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.
kikki 4y ago
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 4y ago
  > 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-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key 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.
  - deleted 4y ago
    [deleted]
dragonwriter 4y ago
> 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 4y ago
  > Where do you find this recommendation? https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key 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 4y ago
    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.

tentacleuno 4y ago

> 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 4y ago

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 4y ago

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.

recursive 4y ago
If you pass new props, it swaps out the whole instance of the element in the document. Probably.
- droidist2 4y ago
  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 https://reactjs.org/docs/react-api.html#reactmemo
- Jcampuzano2 4y ago
  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.
interlocutor 4y ago
> 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-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
- ratww 4y ago
  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.

kikki 4y ago

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 4y ago
> 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-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key 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.
- deleted 4y ago
  [deleted]

dragonwriter 4y ago

> 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 4y ago
> Where do you find this recommendation? https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key 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 4y ago
  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.