Misconceptions about Virtual DOM. If you believe Virtual DOM is a “lightweight copy” of a real DOM helping to speed up the updates by batching them together— continue reading. How many instances of Virtual DOM exist in your app? Is it a single component tree per app, or maybe one Virtual DOM.
If you believe Virtual DOM is a “lightweight copy” of a real DOM helping to speed up the updates by batching them together—_ continue reading_. Albeit being correct, it’s a highly misleading answer. Surprisingly, it’s also the most popular one: googling for “react virtual DOM” leads you to very similar descriptions: 1, 2, and you get ~ the same results even if you stick to the top answers on StackOverflow: 1, 2, 3;
The content below equally applicable to React and Blazor.
#1. It doesn’t highlight the key problem Virtual DOM solves — namely, the elimination of unnecessary re-renders. And when I say “re-renders”, it’s not about re-rendering of certain DOM elements on browser UI update cycles. It’s about not calling
render() methods of React components which are known to produce the same output, which effectively eliminates re-rendering of the whole subtrees of components.
If you know JS and React, check out this example. It logs
"TimeString.render(): ..." message every second, even though
Clock component re-renders itself 10 times per second (see
setInterval call on line 16) and produces an output with
TimeString component on every render. So why
TimeString logs its render just once per second rather than 10? That’s because
PureComponent, which overrides
shouldComponentUpdate to ensure re-rendering happens only once
state changes, and
time property is a string that changes just once per second. If you change
TimeString’s base type to
Component, it will start reporting 10 renders per second.
Now, notice that to make it work, something should call
shouldComponentUpdateon existing component. In other words, Virtual DOM diffing algorithm has to conclude that
TimeString component used in prev. render is actually the same component as we’ve just rendered. And this is exactly what happens during the reconciliation:
Below is an illustration of how diffing works in Blazor (which copies React component model almost exactly):
Article covers: How native is react native?, React Native vs (Ionic, Cordova), Similarities and difference between React Native and Native App Development.
This post is the start of a series about Blazor vs React. The main purpose of this series is not to compare Blazor and React, but instead to show how things can be done in both technologies. Hopefully, this will be helpful for React developers that want to try/switch to Blazor.