[capableweb]

Yeah, I also don't think that's correct, in most cases. React updates the entire tree internally when anything changes, but actually only changes DOM nodes who's prop or state has changed. The problem is, the check of props and state that React does by default is naive, in that it doesn't check if something is deeply equal, only shallow. So using numbers in props works correctly, but not array of numbers. So if you use anything other than booleans, numbers, strings and so on, where equality works as expected, only changed components will render to the DOM. But if you have arrays or objects, the checks React does will always trigger an update of the DOM, as `[] === []` or `[] == []` will never return true, even though they are the same. The way to work around this is to implement your own `shouldComponentUpdate(newProps, newState) <boolean>` and do your own equality checks.

Maybe a side-effect of the poor equality we have in JS-land.

[sfvisser]

> Yeah, I also don't think that's correct, in most cases.

Actually, stupidcar assessment is completely correct.

> React updates the entire tree internally when anything changes, but actually only changes DOM nodes who's prop or state has changed.

Sorry, but you're mixing up a lot of concepts here!

When you tell react(-dom) to render, it recursively calls all the render() methods of your entire component hierarchy and updates the entire virtual DOM, but only mutates the actual browser's DOM for the parts that are changed.

Yes, there are ways to block a render based on prop staleness using shouldComponentUpdate/PureComponent/React.memo. These are explicit optimisations on top of the default render-everything model.

Props and State play into this story quite a bit differently. When a component-local state changes react only renders that specific component (with everything below it). Props are passed down on every render and are by default not compared for staleness so don't prevent re-renders. Props and DOM updates have nothing to do with each other: props are properties of components, not the DOM! Sure, the DOM can be directly or indirectly be influenced by those props.

> Maybe a side-effect of the poor equality we have in JS-land.

Yes, this is true. A lot of reacts's quirks are a result of JS's poor notion of equality.

[deckard1]

> A lot of reacts's quirks are a result of JS's poor notion of equality.

God, yes. And I'm amazed everyday to run into senior engineers that do not understand how equality works in JS.

People are also easily confused if they happen to use Redux, because Redux also adds a layer of memoization for you and will not re-render if none of the state (props) or dispatch functions change.

[quantummkv]

> Yeah, I also don't think that's correct, in most cases. React updates the entire tree internally when anything changes, but actually only changes DOM nodes who's prop or state has changed.

That internal tree update is the root cause of all the problems. During that update, React runs all the javascript in the component, and that of all of it's child components, which then run their child components till the entire tree is done.

Sure, only a small part of the actual DOM will change. But the sheer wastage that happens to update that small part is criminal.