Virtual Dom

В одном из предыдущих курсов мы впервые столкнулись c изменением DOM в процессе взаимодействия со страницей. Этот способ резко отличается от того, который мы использовали в курсе JS: DOM API. Важнейшее отличие связано с тем, как происходит изменение состояния отрисованного экрана. Напомню вкратце, что при прямом манипулировании DOM нам нужно сделать следующее:

1. Удалить из DOM то, что стало неактуально для следующего состояния.
2. Изменить, если надо, те элементы, которые присутствуют на экране и должны остаться в новом.
3. Добавить новые элементы на страницу (точечно).

Другими словами, чтобы перейти в новое состояние, нужно изменить старое. Значит про него надо знать.

В React всё совсем по-другому. После любого изменения и вызова setState React создаёт новое состояние и отрисовывает все компоненты так, как будто это происходит с нуля. На самом деле отрисовка действительно происходит с нуля. Нам не важно, что было до этого момента на экране и как оно располагалось. Любое изменение в React приводит к тому что приложение отрисовывается заново.

Создатели React называют этот подход one-way data flow:

1. Действия пользователя приводят к изменению состояния приложения (через setState).
2. React запускает цикл отрисовки. Начиная от того компонента, в котором было изменено состояние (как правило, корневой компонент), через пропсы данные постепенно распространяются от компонентов более высокого уровня до самых глубинных компонентов.
3. Получившийся html интегрируется в страницу.

Те, кто хорошо знаком с функциональным подходом, могут увидеть прямую связь. React действительно делает мир неизменяемым (immutable). Самый простой способ реализовать подобное поведение - использовать mountElement.innerHTML, который заменяет html целиком после вызова setState. Хотя на практике этот подход сопряжён с кучей сложностей (я реализовывал подобную схему), он позволяет в 200 строк построить библиотеку, которая будет работать как React.

Главная проблема при использовании innerHTML связана с производительностью. Сказать, что это медленно — ничего не сказать. Поэтому создатели React пошли другим путём.

Дерево виртуального DOM

Когда я говорил, что компоненты отрисовываются, то немного лукавил. В реальности после того, как отработает их рендеринг (вызов функции render для всего дерева компонентов), создаётся так называемый виртуальный DOM (virtual DOM). Это просто JS-объект определённой структуры, который отражает состояние экрана. Далее React сравнивает новое дерево виртуального DOM со старым и строит разницу между ними ("дифф", или объект, описывающий разницу между старым и новым состоянием). И только в этот момент начинается отрисовка нового состояния в реальный DOM. Здесь уже должно быть понятно, что React умнее, чем кажется на первый взгляд, и вносит изменения в реальный DOM настолько эффективно, насколько это возможно, ведь он знает КАК его надо изменить.

Из описанного выше есть важное следствие. Тот реальный DOM, который находится под контролем React (это все потомки элемента, в который мы рендерим корневой компонент), не может изменяться никем снаружи React. Если подобное произойдёт, то React не сможет нормально функционировать, ведь ему приходится отслеживать текущее состояние DOM для того, чтобы производить вычисления "диффа". Когда подобное происходит, React ругается и говорит, что ему мешают работать.

Обращаю ваше внимание на то, что виртуальный DOM — не самоцель React, как многие думают. Это просто эффективный способ реализовать идею one-way data flow. Если бы работал вариант с innerHTML, то никто бы не делал виртуальный DOM.

И хотя построение JS-объекта — это гораздо более дешёвая операция, чем работа с реальным DOM, все равно могут возникать ситуации, когда процесс вычисления занимает много времени, и это тормозит приложение. Об этом мы поговорим в одном из следующих уроков.

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.