Is Virtual Dom A Difference Maker In React JS?

4 Mins read
Is Virtual Dom A Difference Maker In React JS?

When it comes to modern-day websites, one undeniable and persistent challenge is the issue of Response Time. In particular, it is about how fast users can navigate to various webpages and subsequently complete their tasks.

With the introduction of multiple UI libraries, all of them are attempting to address this concern effectively.

In this post, you will understand how React addresses this problem using an exclusive concept known as virtual DOM, as well as how this distinct algorithm has transformed React JS as a favorite UI library, among many others available.

Virtual DOM: What is it?

Before we get into it, it is vital first to help you understand that virtual DOM is an ideal approach of interfacing with DOM as opposed to being a mere specification.

In a simple definition, Virtual Dom is typically a JavaScript object representation of a whole HTML document.

To successfully interface with this unique object model, every library features its distinctive way to implement this in order to enhance the re-rendering and rendering performance of webpages.

Real DOM vs. Virtual DOM

Think of this: if appraising a DOM object is typically slow, then why is updating virtual DOM quicker? The pertinent question here is, isn’t virtual DOM simply another DOM item?

Well, Virtual DOM is, of course, another DOM item. However, the difference is that Virtual DOM is not tightly united with the webpage in which it is rendered. To get a better understanding, let’s check out what goes on in the background.

All webpages have a corresponding DOM representation that is basically a tree structure that holds every UI component. With every change (however minor) to the UI’s state, its equivalent DOM representation must be changed in addition to the UI needing re-rendering.

Ideally, although it is not as expensive to update the DOM itself, it gets rather pricey because of the rendering and re-rendering the UI.

Typically, taking into consideration the size of many of the popular Single Page Applications (SPAs), it is the tree structure’s size as opposed to the complexity of the components that hold these components, something that makes rendering the UI a taxing and time-consuming affair.

Using Virtual DOM to Optimize

For many individuals, there is a pertinent misunderstanding and confusion over the perks of using Virtual DOM in React.js offers. Generally, the thrill on React’s Virtual DOM revolves around the fact that it is an efficient approach to updating the view in web applications.

Unfortunately, many of us have no idea how they influence the rendering times of web pages.

Essentially, at a given point in time, the React library usually maintains two Virtual DOM copies. For better understanding, we can name them the Clean version and Dirty version respectively.

Any time there is a variance in the state of the UI, React keeps track of these variations and begins to batch them. Usually, these variations are applied to the dirty version (Virtual DOM) as opposed to the actual DOM.

At a specific React determined period, it will perform an exclusive diff operation between the Clean and Dirty version and in consequence, a delta is worked out.

Afterward, this delta is applied to the actual DOM to ensure that only the necessary part of a webpage is updated, rather than repainting of the whole web page.

To help you understand this explanation better, here are some crucial operations that are part of the distinct React rendering algorithm.

Efficient Diff Algorithm

Ideally, any calls of rendering () method will establish a tree of distinct React components. In the event the change changes and the render () method is subsequently invoked once more, it will produce a different tree of (React) elements.

The problem here is efficiently updating the UI to correctly match the newly produced tree. As such, for a tree featuring ‘n’ elements, the complexity is in O (n3) order. Basically, React applies an enhanced O (n) algorithm mainly based on two key assumptions:

Different Types of Elements Generate Different Tree Structures

Where the root elements feature different types, React effectively replaces the old tree components with the new tree. Similarly, where two React components boast the same type, React will compare their attributes and accordingly update the modified attributes only.

Utilizing a Crucial Prop in Hinting the Child Components Which Might be Stable Across Different Renders

As React generates the diff between the Clean and Dirty virtual DOM, it simply recapitulates over the tree parallelly as well as produces a mutation if it identifies a difference.

As such, if a developer can hint React through the utilization of key attributes to identify a component, React will subsequently use this particular key to correctly match the components between two trees in addition to decreasing redundant mutations.

The Breadth-First Search Algorithm

This is the algorithm that React uses to traverse the DOM tree. With the breadth-first algorithm, nodes are usually traversed both from left to right and top to bottom.

On finding any components that are modified, React will by default re-render this subtree without continuing to check the tree’s depth.

Batched Update Operations

It is important to note that JavaScript defines a solitary thread model and every event that occurs against a DOM tree is usually added to call stack with the event loop executing the added calls.

The crucial thing here is that notwithstanding the number of times setState () is called against an element within a (React) event handler, only a single re-render will be generated ultimately.

Final Word

In the end, through leveraging the algorithms outlined above effectively, it is safe to state that React boasts a near-perfect UI rendering using standard Virtual DOM.

This can be proven by the numerous organizations that have continued to adopt React as well as the resurgence in its popularity and adoption over the years.

Leave a Reply

Your email address will not be published. Required fields are marked *