Hacker News new | ask | show | jobs
by bryanrasmussen 2242 days ago
I believe the argument is as follows:

If you have a React Tree that outputs the HTML that is your full page some of your components in that tree will not be re-rendered because the virtual DOM tells you you do not need to re-render them (where we us re-render to mean the React render function is called for that particular part of the tree) but the last render of that component is still saved somewhere and when your whole tree is ready to re-render the HTML of your page (where re-render means actually sending changes to the DOM and causing all the page to re-render)

I don't know enough about how React internals work but I suppose if you have a parent that re-renders but a child does not (React render called again), both will still render (HTML render) at the time of updating the DOM, as I cannot see a logical way that it could not be so.

1 comments

If I understand you correctly, you have it backwards.

If a component renders in React, that is, the render function is called, then ALL children's render() function are also called, unless you do specific optimizations such as React.memo.

So the whole tree is rerendered.

When it comes time to apply those changes to the DOM, that is, generating HTML on the page, wherever your render() functions returned the same result as before, the DOM is not touched.

> So the whole tree is rerendered.

As you said yourself, only children components will be re-rendered. This is relative to the component that had it's state changed (using setState or the useState hook). So not the whole tree rerenders, only the affected component and it's children. And again, when we speak as "re-render", the render() functions of the components are called and then the VDOM diffing happens. That is, even if child components got -rerendered (in react terms), there might not be a DOM update at all (which is the slow, costly operation).

> That is, even if child components got -rerendered (in react terms), there might not be a DOM update at all (which is the slow, costly operation).

Crawling a large React tree's render stack is also a costly operation. Not as much as DOM manipulation but it is still costly, and React is created in such a way that it requires you to include everything in that stack, even if it never changes. Which is one reason we have Portals.

As the component tree grows in size, even the render call and diffing become a wasteful, costly operation.
(i hope i'm not spreading misinfo, i'm not super experienced with React)

it may be that way with regular Components, but afaik Pure components are smarter - the idea of Pure components is that react only rerenders the components when the props change. (or something in a hook, if you're using those). though i guess a Pure component is basically equivalent to what you'd get with memo?

Yes, PureComponent, React.memo and shouldComponentUpdate are all the same mechanism.
Yes, of course, I realized how the html re-render part works just now reading your reply, which I had known before but forgotten. sort of embarrassing.