Virtual Dom — JS: React

One of the previous courses involved a first look at changing the DOM when interacting with a page. This method is drastically different from the one used in the JS: DOM API course. The most important difference has to do with how the state of the screen that's rendered changes. If you want to manipulate the DOM directly, you need to do the following:

1. Remove the elements that have become irrelevant for the next state.
2. If necessary, change the elements that are present on the screen and must stay in the new one.
3. Add the new elements to the page (point by point).

In other words, in order to move to a new state, you have to change the old one. So you have to know about him.

In React, it's very different. After any change and call to setState React creates a new state and draws all components as if from scratch. In fact, the rendering really is done from scratch. It doesn't matter what was on the screen up to that point or how it was positioned. Any change in React causes the application to be rerendered.

The creators of React call this approach one-way data flow:

1. A user action changes the state of the application (via setState).
2. React starts the rendering loop. Starting from the component where the state was changed (usually the root component), the data gradually propagates through the props, starting from the higher-level components and going down to the deepest components.
3. The resulting html is integrated into the page.

Those familiar with the functional approach can see a direct link. React really makes the world immutable. The easiest way to implement this behavior is to use mountElement.innerHTML, which replaces the entire html after the setState call. Although in practice this approach has a lot of difficulties (see the example implementation in the additional materials), it allows you to build a library that will work like React in 200 lines.

The main problem with using innerHTML is related to performance. To say it's slow is an understatement. So the creators of React went another way.

Virtual DOM tree

Earlier in the course, we said that components are rendered, but that's a bit off. In reality, after rendering (a call to the render function for the entire component tree), a so-called virtual DOM is created. It's just a JS object with a certain structure that reflects the state of the screen. Next, React compares the new virtual DOM tree with the old one and builds an object describing the difference between the old and the new state. It's only at this point that the new state starts to be drawn in the real DOM. It should be clear by now that React is smarter than it looks; it makes changes to the actual DOM as efficiently as possible because it knows HOW it should be changed.

There's an important corollary to the above. The actual DOM that React controls (which is all the descendants of the element that the root component is rendered into) cannot be changed by anyone outside the React application. If this happens, React won't be able to function properly because it has to monitor the current state of the DOM in order to do the diff calculations. When this happens, React gets annoyed and says it's being interfered with.

It's important to note that the virtual DOM is not an end in itself, as many people think. This is just an efficient way to implement the idea of one-way data flow. If innerHTML worked, no one would make a virtual DOM.

And although building a JS object is a much cheaper operation than working with the real DOM, there can still be situations where the calculation process takes a long time, thus slowing down the application. One of the following lessons will be devoted to this topic.

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.