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