> React would be responsible for which elements need to be created and which can be updated in place.
That works for simple, read-only components. The moment the component starts managing its own interactivity you end up needing state, and at that point things break down. If you need to change props, you have to essentially recreate the component by changing key [1], and at that point, what is the benefit of React?
> 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.
> 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.
> Things like button's text, color, visibility is nicely controlled via adding/removing classes
Isn't the whole point of using React that I don't have to manually manage state like this? When text, color, visibility are all changed independently in different places for more than a handful of states, suddenly it isn't so nicely controlled.
> 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.
> Let's say your UI changes, like a redesign... you can rewrite your component and probably need to change most of them.
This is exactly what React does especially for stateless components that purely consume data. The component declartively says this is the data I need. The component doesn't care how that data is retrieved, that's an implementation detail separate from React.
For stateful components, this is also achievable but requires a little engineering and some good architecture (this is IMO the hardest part of 'React' - and this isn't even a concern of React - since React doesn't prescribe any specific approach).
If you define all the functionality for a component well, you should be able to easily rewrite just the view (the return value of a fucntional component or of the render method for class components) without changing any of the existing functionality.
This can be done by defining your component's behaviors via hooks (custom or builtin). Those hooks should provide any functionality and data your view needs and exposes that to the component. If no new data or functionality is needed, then nothing in these hooks (and more broadly code external to the render/return value) changes.
All that changes is the return value of your component and any css you want.
If you change the view, yeah you might have to update some event handlers for buttons that are now inputs, but that's not a UI only change, thats changing functionality too.
> What we settled on, for the most part, is components declaring and fetching the data they need themselves, except for some small, more generic components.
How does this interact with shouldComponentUpdate? Generally it seems that when moving data out of props/state, it's harder to take advantage of the performance hooks that React gives you because you don't have the old and new data to compare when rerendering.
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.
Just replied in the other spot -- I understand the similarities now, but I think this points to react still not being as simple as it could be -- if components were really as simple as being functions from state to UI, reacts API would be drastically smaller.
My point is that it's not that simple (for better or for worse, some of the added complexity in the API IS essential IMO), but people still say things like "components are just functions" like it really is that simple.
> Note that if a parent component causes your component to re-render, this method will be called even if props have not changed. You may want to compare new and previous values if you only want to handle changes.
Things like that are indications of hidden complexity, in my experience.
> 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.
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.
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.
> Is there some reason you can't use a `get(key)` and `set(key,value)` between class components. I don't really grok react, despite trying, so maybe there's a reason that doesn't work.
You can and the hooks way is better.
The class based components way is to wrap component in a HOC. The common state is stored in the HOC. The HOC passes the state to the component via props. This can include functions, so maybe your component can call `this.props.reloadApi()`, which changes HOC state, which results in new props sent to your component.
The hooks way is described here. [0]
What's wrong with Higher-Order Components?
One answer is that it's weird to call something a "component" which doesn't render any UI. In other words, why is an interface to access remote data a "component"?
Another answer is that HOCs break the diff algorithm without special care see. [1]
>but note that then there’s no way of accessing updates values (in callbacks)
This is by design. When you start making a component worry about what it needs to do on an update, rather than just rendering its data, you are introducing a whole new level of complexity. That's why class based React components could turn into these unwieldy confusing things where you never knew for certain what was going to render every time, because the shouldComponentUpdate method gets stuffed full of business logic.
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.
> Doesn't state grow unmanageably large for complex GUIs?
Yes, and there are various ways to make this less of a problem. Still, React generally favors explicitly passing props down the component hierarchy, keeping the actual UI bits pure functions and composing them in various ways that is typical of FP.
Perhaps I should've specified that React, as a very popular 'GUI' library, is much more functional than many of the very popular libraries that came before it.
Anyways, my point was not that it's the first of its kind, or 'fully' FP, but rather that it's an example of how FP-style UI libraries can be a good solution, and even be popular because they're less OO in nature.
> so it would be nice to be able to get into the standard shouldComponentUpdate
Is there such thing? You at least need to choose between value and ref equality for various props?
Also not clear to me if these functions are turned into full React components with lifecycle methods and async rendering, or are just synchronously invoked in the same render stack frame as the closest up-stack actual React component.
That works for simple, read-only components. The moment the component starts managing its own interactivity you end up needing state, and at that point things break down. If you need to change props, you have to essentially recreate the component by changing key [1], and at that point, what is the benefit of React?
[1] https://legacy.reactjs.org/blog/2018/06/07/you-probably-dont...
reply