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:
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:
setState
).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.
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.
The Hexlet support team or other students will answer you.
A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.
Programming courses for beginners and experienced developers. Start training for free
Our graduates work in companies:
From a novice to a developer. Get a job or your money back!
Sign up or sign in
Ask questions if you want to discuss a theory or an exercise. Hexlet Support Team and experienced community members can help find answers and solve a problem.