Подготовка к тех.интервью

Virtual DOM и Fiber vs прямой DOM: последствия решения

Представьте, что в проекте на React предлагается отказаться от использования Virtual DOM и Fiber в пользу прямого (императивного) изменения DOM с целью повышения производительности. Какое из следующих утверждений наиболее точно отражает последствия такого решения?

Почему прямой DOM не “всегда быстрее”

Прямое императивное обновление DOM может быть быстрым в микросценариях (один узел, редкие изменения), но в реальных приложениях часто приводит к большому числу разрозненных мутаций и лишней работе браузера.
В React вычисление «что должно быть на экране» отделяется от этапа реальных DOM-изменений, а на повторных рендерах применяются минимально необходимые операции.

Типичные проблемы императивного DOM в динамическом интерфейсе:

  • Сложнее гарантировать «минимальные изменения»: логика сравнения и выбора операций фактически переносится в прикладной код, где часто получается больше действий, чем нужно.
  • Легко потерять «стабильность UI»: например, случайно перезаписать value у input или сбросить фокус при обновлениях, потому что DOM меняется в разных местах и в разное время.
  • Возникает риск «раскачки» производительности: частые мелкие изменения вызывают больше коммитов и визуальных задержек, чем одно сгруппированное обновление.

Что дают VDOM и Fiber

В React обновление UI концептуально делится на три шага: trigger → render → commit, причём реальный DOM изменяется на этапе commit и только при наличии отличий между рендерами.
Fiber дополняет это тем, что делает рендеринг инкрементальным (работа дробится на части), появляется возможность ставить на паузу, прерывать, переиспользовать работу и назначать приоритеты разным типам обновлений.

Ключевые эффекты Fiber и современного React:

  • Инкрементальный рендеринг: крупная работа распределяется по времени вместо стратегии «сделать всё сразу».
  • Приоритизация: обновления от взаимодействия (например, ввод) могут обслуживаться раньше фоновых обновлений.
  • Конкурентный рендеринг (начиная с React 18 как основа новых возможностей): рендер может быть прерываемым; реальные DOM-мутации откладываются до конца, чтобы интерфейс оставался согласованным даже при паузах или отмене промежуточной работы.

Также в React 18 есть автоматическое пакетирование обновлений (automatic batching): несколько setState в таймерах, промисах и других асинхронных местах объединяются, чтобы уменьшить число повторных перерисовок.

Примеры, схема, таблица

Схема «React-подход» vs «императивный DOM-подход» (упрощённо):

- React:
- (1) Изменение состояния → постановка работы в очередь на рендер
- (2) render: вычисление нового представления UI (без мутаций DOM)
- (3) commit: применение минимальных DOM-операций
- Императивный DOM:
- (1) Изменение данных
- (2) Прикладной код сам решает, какие узлы и как менять (часто много мелких операций, распределённых по коду)

Пример: императивное обновление списка (часто получается много DOM-операций)

const listEl = document.getElementById('list');


function renderList(items) {
  // Полная перерисовка: просто, но может быть дорого на больших списках
  listEl.innerHTML = '';
  for (const item of items) {
    const li = document.createElement('li');
    li.textContent = item.title;
    listEl.appendChild(li);
  }
}

Проблема: при частых изменениях данных (поиск, сортировка, фильтры) такая стратегия может делать слишком много работы, даже если изменилось 1–2 элемента.

Иллюстрация идеи React «минимальные изменения на commit» (концептуально)

// Концептуально:
// 1) состояние меняется
// 2) React пересчитывает дерево UI
// 3) React применяет только отличия в DOM на commit
//
// Важно: изменение состояния не означает немедленную мутацию DOM,
// мутации происходят на этапе commit.

Пример: automatic batching в React 18 (идея — меньше ререндеров)

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // В React 18 обновления в таймере обычно батчатся автоматически,
  // что уменьшает число перерисовок.
}, 1000);

Пример: разделение срочных и несрочных обновлений (повышение отзывчивости)

import { startTransition } from 'react';

function onType(nextValue) {
  // Срочно: обновить ввод
  setInputValue(nextValue);

  // Несрочно: обновить тяжёлый список результатов
  startTransition(() => {
    setSearchQuery(nextValue);
  });
}

Смысл: несрочная работа может уступать место вводу/кликам, повышая отзывчивость, а устаревшая незавершённая работа может быть отброшена.

Если React «обходится стороной» и DOM меняется вручную в тех узлах, которыми одновременно управляет React, возникают трудноуловимые ошибки: рассинхронизация состояния, неожиданные перезаписи значений, проблемы при повторных рендерах и при включении конкурентных возможностей.

Таблица: что теряется при отказе от VDOM/Fiber

АспектReact с VDOM/FiberПрямой императивный DOM
Минимизация DOM-измененийDOM меняется на commit и только при отличиях между рендерамиМинимальность нужно реализовать вручную; часто выполняются лишние операции
Пакетирование обновленийВ React 18 есть automatic batching, уменьшающий число ререндеровОбычно каждое изменение немедленно меняет DOM, если специально не писать батчинг
Приоритизация/пауза работыFiber: инкрементальный рендеринг, приоритеты, пауза/отмена/переиспользование работыТребуется собственный планировщик; иначе тяжёлые обновления блокируют поток выполнения
Согласованность UI при прерыванииКонкурентный рендер откладывает DOM-мутации до завершения выбранной версии UIПри частичных ручных обновлениях легко получить промежуточные несогласованные состояния
Отказ от VDOM/Fiber имеет смысл только при смене подхода или инструмента целиком (например, другой рендерер или другая библиотека), а не как «точечная оптимизация» внутри React, потому что архитектура React завязана на управляемом commit и планировании работы.

Итого: верным является вариант 2 — прямой DOM не гарантирует ускорения, тогда как VDOM+Fiber помогают уменьшать количество реальных DOM-операций, пакетировать обновления и поддерживать отзывчивость за счёт приоритизации и прерываемого рендеринга.