Not exactly. This is the "mental model" but not how the algorithm works internally. There are a lot of optimizations to do as little work as possible while "appearing" to rerender everything.

This is not to say one is better than the other - each has its own benefits. But that's not a reason to choose Vue over React.

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

For high frequency updates such as reacting to mouse interactions, you can compose components in such a way that only one small component handles the high-frequency update, while it's siblings and children remain static.

In this way, React-components are closer to Vue's computed properties than Vue-components.

If your whole tree is recalculating on every mousemove event, that is a giant code smell to say the least. You’d have to architect the app to work that way.