Дальше, если тип элемента не изменился, проверяются его атрибуты:

Hello
 → 
Hello

Алгоритм просто изменит className, не затрагивая текстовый контент.

2. Рекурсивное сравнение дочерних элементов

На втором шаге рекурсивно сравниваются дочерние элементы. Если структура осталась прежней, он обновит только измененные узлы.

Привет
 → 
Пока

Например, в данном случае изменится только текст в теге

, не затрагивая родительский

.

3. Оптимизация списков с помощью ключей (keys)

Если, например, список рендерится через .map(), то все мы знаем, что нужно юзать уникальные ключи, которые React использует для отслеживания элементов.

Код без использования ключей:

  {items.map((item) => (
    
{item.text}
  ))}

Если забыть прописать ключи React ругнется, а при изменении массива пересоздадутся все теги

, даже если часть элементов осталась неизменной. Если не использовать key, React будет сравнивать элементы по позиции, что приводит к неправильным обновлениям. Собственно, отсюда и правило: нельзя использовать index в качестве ключа. Ключи должны быть уникальными.

Правильный код с использованием ключей:

  {items.map((item) => (
    
{item.text}
  ))}

Теперь React будет точно знать, что изменять нужно только те

, у которых key изменился, а остальные оставить без изменений.

Подробнее про React Fiber

React Fiber — это переписанный алгоритм согласования, представленный в React 16, который позволяет управлять рендерингом эффективней старого стекового алгоритма.

До React 16 использовался стековый рекурсивный алгоритм. Проблемы заключалась в том, что, если один компонент рендерился долго, UI мог «зависнуть». Отсутствовали приоритеты рендеринга, а также не было возможности прервать рендеринг, например, если пользователь вводил текст, то React мог продолжать рендеринг и не реагировать на ввод.

Fiber решил все эти проблемы и теперь у нас есть:

• Приоритизация задач. Сначала перерендериваем более важные части, потом менее.

• Разбиение рендеринга на чанки (React может рендерить части дерева отдельно).

• Асинхронный рендеринг (React может прерывать выполнение и продолжать позже).

• Приоритизация задач. Сначала перерендериваем более важные части, потом менее.

• Разбиение рендеринга на чанки (React может рендерить части дерева отдельно).

• Асинхронный рендеринг (React может прерывать выполнение и продолжать позже).

Концепции Fiber

Каждый узел VDOM — это Fiber Node
В отличие от старого алгоритма, React теперь хранит в памяти две версии дерева. Первая — это текущее (current) дерево — то, что сейчас в DOM, вторая — рабочее (work-in-progress) дерево — новая версия, которую React готовит.

Рендеринг разбивается на этапы
Рендеринг разбивается на этапы с использованием «chunk-based rendering». React может приостанавливать рендеринг для выполнения более важных задач, таких как пользовательский ввод, и продолжить его позже.

Фазы работы Fiber

Render Phase (Diffing, вычисление изменений)

• Проходит асинхронно и может быть прервано.

• Создаётся новое Work-In-Progress (WIP) Fiber-дерево.

Commit Phase (Обновление DOM)

• Выполняется синхронно и не может быть прервано.

• Применяются изменения к DOM и вызываются componentDidMount, componentDidUpdate, useEffect.

Структура Fiber Node

Структура Fiber Node в React представляет собой описание каждого узла виртуального DOM (VDOM) и содержит информацию, необходимую для эффективного обновления реального DOM. Нода хранятся в памяти и служат промежуточным представлением элемента, которое позволяет React управлять рендерингом и обновлением интерфейса. Вот так выглядит структура:

{
  type: 'div',
  stateNode: DOMNode,
  child: FiberNode,
  sibling: FiberNode,
  return: FiberNode,
  effectTag: 'update',
  pendingProps: {...},
  memoizedProps: {...},
  alternate: FiberNode,
  updateQueue: null,
  hooks: null,
  index: 0,
  nextEffect: FiberNode,
  firstEffect: FiberNode,
  lastEffect: FiberNode,
  tag: 'FunctionComponent',
  mode: 0
}

• type: Тип узла, который определяет, какой элемент должен быть отрендерен.

• stateNode: Ссылка на реальный DOM-узел, с которым этот Fiber связан.

• child: Ссылка на первый дочерний узел, если он есть.

• sibling: Ссылка на следующий узел этого же уровня.

• return: Ссылка на родительский узел. Указывает на Fiber-узел родителя этого компонента, строя дерево.

• effectTag: Тип обновления.

• pendingProps: Пропсы, которые должны быть применены к этому узлу в процессе рендера.

• memoizedProps: Пропсы, которые использовались для рендеринга этого компонента в прошлый раз.

• alternate: Ссылка на Fiber-узел, который хранит старую версию Fiber-узла для вычисления изменений.

• updateQueue: Очередь обновлений для компонента.

• hooks: Информация о хуках (если компонент является функциональным).

• index: Индекс элемента в родительском списке. Используется для оптимизации рендеринга списков и определения порядка обновлений.

• nextEffect: Ссылка на следующий эффект в списке эффектов.

• firstEffect: Ссылка на первый эффект в списке.

• lastEffect: Ссылка на последний эффект в списке.

• tag: Тип компонента.

• mode: Режим рендеринга, который описывает, как компонент будет обновляться (например, в Concurrent Mode или Strict Mode).

• type: Тип узла, который определяет, какой элемент должен быть отрендерен.

• stateNode: Ссылка на реальный DOM-узел, с которым этот Fiber связан.

• child: Ссылка на первый дочерний узел, если он есть.

• sibling: Ссылка на следующий узел этого же уровня.

• return: Ссылка на родительский узел. Указывает на Fiber-узел родителя этого компонента, строя дерево.

• effectTag: Тип обновления.

• pendingProps: Пропсы, которые должны быть применены к этому узлу в процессе рендера.

• memoizedProps: Пропсы, которые использовались для рендеринга этого компонента в прошлый раз.

• alternate: Ссылка на Fiber-узел, который хранит старую версию Fiber-узла для вычисления изменений.

• updateQueue: Очередь обновлений для компонента.

• hooks: Информация о хуках (если компонент является функциональным).

• index: Индекс элемента в родительском списке. Используется для оптимизации рендеринга списков и определения порядка обновлений.

• nextEffect: Ссылка на следующий эффект в списке эффектов.

• firstEffect: Ссылка на первый эффект в списке.

• lastEffect: Ссылка на последний эффект в списке.

• tag: Тип компонента.

• mode: Режим рендеринга, который описывает, как компонент будет обновляться (например, в Concurrent Mode или Strict Mode).

Как Fiber приоритизирует рендеринг?

Fiber использовал систему приоритетов expirationTime (в последних версиях используется Scheduler с приоритетами, такими как Immediate, User-blocking, Normal, Low и Idle). Согласно ей, он отправляет на перерендер сначала важные изменения, потом менее важные.

Важными событиями считаются пользовательские события onChange, onClick и т.п.

События со средней важностью — это анимации, переходы. Анимации и переходы работают через Concurrent Mode и могут быть прерваны.

Менее важными — побочные эффекты UseEffect. React может отложить обновления менее важного UI, если активно обрабатывает другие задачи.

Как работает рендеринг в Fiber?

Сначала React запускает рендеринг (Render Phase), далее создается новое Work-In-Progress (WIP) Fiber-дерево. Здесь React не вносит изменения в DOM, а только создает описание изменений.

Следующим действием идет сравнение нового WIP-дерева со старым деревом и отмечаются изменения, которые нужно внести.

И конечным действием React вносит изменения в реальный DOM, обновляя только те узлы, которые изменились. На этом этапе вызываются lifecycle-методы: componentDidMount, componentDidUpdate, а также хуки useEffect.

Пример:

function App() {
  const [count, setCount] = React.useState(0);
  
  return (
    

      
Счетчик: {count}
       setCount(count + 1)}>Увеличить
    
  );
}

В примере при изменении count происходит следующее:

Сначала React создает Work-In-Progress дерево. Затем сравнивает новое дерево с предыдущим, где видит, что тег

изменился и помечает его как «нужно обновить».

Далее React запускает Commit Phase. Обновляет innerText у тега

.

Готово. React не будет трогать тег , потому что он не изменился.

Производительность

Что касается производительности всего этого процесса, то для того, чтобы его ускорить и оптимизировать, нужно свести количество перерендеров к минимуму. В этом помогут:
React.memo, useMemo, useCallback и правильное использование ключей в списках.

Но об этом все уже знают, это тема отдельная, однако стоило упомянуть это в контексте оптимизации.

Итог

В этой статье я попытался собрать информацию по процессу Reconciliation в React, разобрав его основные аспекты и детали работы под капотом. Надеюсь, что мой материал поможет вам лучше понять, как React обновляет интерфейс и какие технологии стоят за этим процессом. Если у вас есть замечания, вопросы или дополнения, буду рад услышать их в комментариях!