Understanding the virtual DOM

Why do we need to manipulate the DOM in the first place? It is because our web applications are not static. They have a state represented by a user interface (UI) that a web browser renders, and that state can be changed when an event occurs. What kind of events are we talking about? There are two types of events that we're interested in:

• User events: When a user types, clicks, scrolls, resizes, and so on
• Server events: When an application receives data or an error from a server, among others

What happens while handling these events? Usually, we update the data that our application depends on and that data represents a state of our data model. In turn, when a state of our data model changes, we might want to reflect this change by updating a state of our UI. Looks like what we want is a way of syncing two different states: the UI state and data model state. We want one to react to the changes in the other and vice versa. How can we achieve this?

One of the ways to sync your application's UI state with an underlying data model's state is a two-way data binding. There are different types of two-way data binding. One of them is Key-Value Observation (KVO), which is used in Ember.js, Knockout, Backbone, and iOS, among others. Another one is dirty checking, which is used in Angular.

Instead of a two-way data binding, React offers a different solution called the virtual DOM. The virtual DOM is a fast in-memory representation of the real DOM, and it's an abstraction that allows us to treat JavaScript and DOM as if they were reactive. Let's take a look at how it works:

1. Whenever a state of your data model changes, the virtual DOM and React will re-render your UI to a virtual DOM representation.
2. It then calculates the difference between the two virtual DOM representations: the previous virtual DOM representation that was computed before the data was changed and the current virtual DOM representation that was computed after the data was changed. This difference between the two virtual DOM representations is what actually needs to be changed in the real DOM.
3. Update only what needs to be updated in the real DOM.

The process of finding a difference between the two representations of the virtual DOM and re-rendering only the updated patches in a real DOM is fast. Also, the best part is—as a React developer—that you don't need to worry about what actually needs to be re-rendered. React allows you to write your code as if you were re-rendering the entire DOM every time your application's state changes.

If you would like to learn more about the virtual DOM, the rationale behind it, and how it can be compared to data binding, then I would strongly recommend that you watch this very informative talk by Pete Hunt from Facebook at https://www.youtube.com/watch?v=-DX3vJiqxm4.

Now that you've learned about the virtual DOM, let's mutate a real DOM by installing React and creating our first React element.