This is the virtual DOM mental model of react, and it is pretty much entirely wrong.
- React doesn't really distinguish between DOM components and your own components in how it evaluates. It's all part of the same "VDOM" tree. Creating and updating HTML tags doesn't flow differently from updating the props on your own components.
- React does sparse updates, starting at the topmost component(s) whose state changed. Frequently this is just one widget or a button. Full tree re-evaluation is rare.
- If a component has the _exact_ same `children` prop as before (`===`), as is often the case with e.g. context providers, because it was assigned by a parent, then React will skip re-rendering the children entirely with no effort from the developer.
- If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before. This means even if your state lives high up in the tree, judicious use of memo can make it zippy af.
TLDR: If your react app is re-calculating the entire tree, you suck at react and you never bothered to learn it. Skill issue, git gud, etc. You're welcome.
> If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before
This works only with immutable data structures. Am I wrong? Because a modified array will pass the identity test (=== operator). If you are using mutable data structures, you cannot use identity operator to detect changes.
Also if "memo" optimization is that good why does one have to add it manually?
> If your react app is re-calculating the entire tree, you suck at react
The point of UI framework is to do the optimization for me and not require me to use some special style of coding like immutable structures or manually write functions like componentShouldUpdate. What I write is how UI variables depend on model variables and the rest is framework's job. I don't want to use weird patterns like a function with a giant switch that processes update events and clones the whole model graph to change a single variable.
Vue of course has its own set of issues, caused by using proxies (for example when adding on object to the set you must "unwrap" it manually to prevent adding a proxy to the set).
Yes, immutability is a requirement. And if you think that's a "special style of coding" then you probably haven't run into situations where that is a necessity, like optimistic updates with rollback, or undo/redo systems.
Mutable code is code that destroys the paper trail of what happened.
>The point of UI framework is to do the optimization for me
No, the point of the UI framework is to allow you to build applications that work correctly and perform well. The React style of coding is designed to scale up to large applications of e.g. a Figma or Excel caliber, while eliminating entire categories of subtle bugs. If you've never coded something like that, React will seem like it is getting in your way.
>Also if "memo" optimization is that good why does one have to add it manually?
Because the compute vs memory trade-off isn't always free, especially in a world where CPU computations are much faster than accessing uncached memory.
- React doesn't really distinguish between DOM components and your own components in how it evaluates. It's all part of the same "VDOM" tree. Creating and updating HTML tags doesn't flow differently from updating the props on your own components.
- React does sparse updates, starting at the topmost component(s) whose state changed. Frequently this is just one widget or a button. Full tree re-evaluation is rare.
- If a component has the _exact_ same `children` prop as before (`===`), as is often the case with e.g. context providers, because it was assigned by a parent, then React will skip re-rendering the children entirely with no effort from the developer.
- If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before. This means even if your state lives high up in the tree, judicious use of memo can make it zippy af.
TLDR: If your react app is re-calculating the entire tree, you suck at react and you never bothered to learn it. Skill issue, git gud, etc. You're welcome.