Render и commit: почему React вызывает компонент чаще, чем рисует

Рендер — это вызов функции, а не обновление экрана

Каждое обновление UI в React проходит один и тот же конвейер: триггер → render → commit. Триггер — это либо первый монтаж, либо обновление состояния (setState планирует ре-рендер, а не выполняет его). Фаза render — это React, вызывающий функции ваших компонентов. Возвращаемое значение — дерево элементов: простых, неизменяемых JavaScript-объектов, которые порождает JSX (под капотом — react.createElement) и которые описывают, как должен выглядеть UI: тип, пропсы, дети. Создание элементов дёшево — DOM не трогается, ничего не рисуется и не измеряется. React рендерит компонент, чьё состояние изменилось, затем рекурсивно его детей, собирая полное описание следующего UI.

Именно здесь спотыкается большинство: «рендер» порождает описание, а описание можно сравнить, закешировать или выбросить в корзину без какой-либо цены для пользователя. Фаза commit — это когда React берёт разницу между новым описанием и тем, что сейчас на экране, и применяет минимальный набор реальных мутаций DOM — appendChild, обновления атрибутов, удаления — одним синхронным, непрерываемым проходом. После commit браузер рисует кадр, затем выполняются пассивные эффекты (useEffect). Layout-эффекты (useLayoutEffect) выполняются внутри commit, после мутаций, но до отрисовки — поэтому они могут измерять DOM без видимого мерцания, и поэтому медленный код в них напрямую блокирует отрисовку.

Fiber: единица работы, делающая рендер прерываемым

Внутри каждый экземпляр компонента опирается на fiber (волокно — внутренний узел планировщика React) — изменяемый узел, хранящий тип компонента, его текущие пропсы, состояние хуков (связный список — вот почему порядок хуков должен быть стабильным) и флаги изменений. Когда ты смотришь на компонент, видишь функцию, возвращающую JSX, — fiber — это то, что React держит за кадром между рендерами. Фаза render — это work loop (цикл обработки работы) по fiber-узлам: обработать один fiber, отрендерить его компонент, согласовать детей, перейти к следующему. Один fiber — одна единица работы, и между единицами React может остановиться. Срочные обновления он по-прежнему прогоняет синхронно до конца, но внутри transition и других конкурентных механизмов уступает браузеру управление примерно каждые 5 мс — и долгий рендер дерева на 2 000 строк больше не замораживает ввод на 300 мс: обработчик нажатия выполняется между единицами работы.

Второй структурный трюк — двойная буферизация: React держит текущее fiber-дерево (то, что на экране) и строит отдельное work-in-progress-дерево (дерево «в работе») во время рендера. Commit, по сути, — это перестановка указателя с текущего дерева на work-in-progress. Это разделение и делает выбрасывание работы безопасным: если посреди рендера приходит более приоритетное обновление, React бросает work-in-progress-дерево — текущее никто не трогал, экран консистентен — и начинает свежий рендер от нового состояния.

Почему render обязан быть чистым — и как StrictMode держит вас честными

Чистота — не вопрос стиля, а контракт, который делает планировщик легальным. При одних и тех же пропсах и состоянии компонент обязан вернуть те же элементы и не изменить ничего больше — никаких мутаций существовавших до вызова объектов, сетевых запросов, записи в ref, никакого analytics.track. Причина арифметическая: render может выполниться ноль, один или много раз на один закоммиченный кадр. Рендер внутри transition может быть выброшен и перезапущен; будущий offscreen-рендер может выполняться для UI, который никогда не станет видимым. Побочный эффект в рендере поэтому срабатывает непредсказуемое число раз — 40% фантомных показов из пролога были ровно этим: эффектами рендеров, которые так и не закоммитились.

function SearchResults({ items, query }) {
  // Баг: побочный эффект в фазе рендера. Срабатывает на каждую *попытку* рендера —
  // включая рендеры, которые React отбрасывает, — а не один раз на отрисовку.
  analytics.track("impression", { query });

  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

function SearchResultsFixed({ items, query }) {
  // Эффекты запускаются после коммита — один раз на *закоммиченное* изменение query.
  useEffect(() => {
    analytics.track("impression", { query });
  }, [query]);

  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

StrictMode — инструмент принуждения: в dev-режиме он намеренно вызывает render каждого компонента дважды (и прогоняет лишний цикл setup/cleanup эффектов при монтаже), чтобы любая нечистота дала видимое удвоение — два лога, два запроса, массив, растущий вдвое. Чистый компонент двойной вызов не замечает — в этом и есть тест. Компромисс: чистота запрещает делать работу в самом «очевидном» месте и выталкивает её в обработчики событий и эффекты, что в первый день кажется бюрократией — но именно это бесплатно покупает прерываемый рендеринг, кеширование рендеров и серверный рендеринг. Сценарий отказа: команды, выключающие StrictMode «потому что логи дублируются», отключают единственную сигнализацию, которая срабатывает до продакшен-инцидента.