React Compiler: мемоизация уходит из кода

Здесь будет встроен видео-разбор темы (5–7 минут, YouTube / RuTube / VK Видео) — тем, кто лучше воспринимает на слух, текст ниже не обязателен.

React Compiler ничего не делает в браузере: это шаг сборки. Сборка и так переписывает ваш код — превращает <h3> в вызов функции (статья «JSX — это не HTML»; в Next.js это делает SWC, в Expo — Babel). React Compiler — ещё одно такое преобразование поверх. На вход идёт код без единого useMemo, на выходе — код с кешем.

Кеш устроен незамысловато: массив ячеек, который живёт при компоненте столько же, сколько его состояние. В одних ячейках лежат входы, при которых считали, в других — результаты. Перед каждым вычислением стоит проверка: вход тот же — берём готовое, вход другой — считаем заново и кладём в ячейку.

Соберём такой массив руками — просто чтобы увидеть механику. Кнопка меняет состояние Page и к заголовку отношения не имеет; жмём её трижды. Сколько раз напечатается «рендер Title» и сколько — «считаем заголовок»?

tsx

const EMPTY = Symbol("пусто");

// массив ячеек живёт при компоненте столько же, сколько его состояние;
// именно такой кеш дописывает React Compiler — только свой, внутри React
function useCache(size: number): unknown[] {
  const box = React.useRef<unknown[] | null>(null);
  if (box.current === null) box.current = new Array(size).fill(EMPTY);
  return box.current;
}

interface TitleProps {
  name: string;
}

function Title({ name }: TitleProps) {
  console.log("рендер Title");
  const cache = useCache(2);
  let title: string;
  if (cache[0] !== name) {
    console.log("считаем заголовок для", name);
    title = "Привет, " + name.toUpperCase();
    cache[0] = name; // при каком входе считали
    cache[1] = title; // и что получилось
  } else {
    title = cache[1] as string;
  }
  return <h3>{title}</h3>;
}

function Page() {
  const [n, setN] = React.useState(0);
  return (
    <div>
      <Title name="Рико" />
      <button id="inc" onClick={() => setN(n + 1)}>нажато {n}</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Page />);
setTimeout(() => document.getElementById("inc")!.click(), 50);
setTimeout(() => document.getElementById("inc")!.click(), 80);
setTimeout(() => document.getElementById("inc")!.click(), 110);

const EMPTY = Symbol("пусто");

// массив ячеек живёт при компоненте столько же, сколько его состояние;
// именно такой кеш дописывает React Compiler — только свой, внутри React
function useCache(size: number): unknown[] {
  const box = React.useRef<unknown[] | null>(null);
  if (box.current === null) box.current = new Array(size).fill(EMPTY);
  return box.current;
}

interface TitleProps {
  name: string;
}

function Page() {
  const [n, setN] = React.useState(0);
  return (
    <div>
      <Title name="Рико" />
      <button id="inc" onClick={() => setN(n + 1)}>нажато {n}</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Page />);
setTimeout(() => document.getElementById("inc")!.click(), 50);
setTimeout(() => document.getElementById("inc")!.click(), 80);
setTimeout(() => document.getElementById("inc")!.click(), 110);

страница примера

Сначала предположите, что выведет код

Четыре отрисовки и один расчёт. Функция Title вызывалась при каждой перерисовке родителя — React не спрашивает разрешения, как показано в статье «Триггер, рендер, коммит», — но внутри неё работа выполнилась однажды: вход не менялся. Ровно это и делает компилятор, только ячейки заводит сам и не для одной строки, а для каждого значения в компоненте: вычислений, обработчиков, объектов и элементов разметки.

Писать в useRef во время рендера нельзя — это одно из правил, о которых пойдёт речь ниже. Здесь мы вручную изображаем внутренний механизм React; в вашем коде эти строки пишет компилятор.

Компилятор не переписывает вашу логику — он расставляет вокруг неё проверки «менялось или нет». t0, t1 — его собственные имена для промежуточных значений, $ — тот самый массив ячеек, _c — функция из react/compiler-runtime, которая заводит массив при первой отрисовке (в React 19 этот рантайм уже внутри пакета react).

jsлистинг · не запускается

// вывод компилятора для Title — примерно так, только имена короче.
// «Примерно» тут важно: на этом самом Title настоящий компилятор
// обходится двумя ячейками — значение используется один раз, и он
// сливает его ячейку с ячейкой разметки. Здесь они разведены: так видна механика
function Title(t0) {
  const $ = _c(4); // четыре ячейки: под каждый вход и под каждый результат
  const { name } = t0;
  let t1;
  if ($[0] !== name) {
    t1 = "Привет, " + name.toUpperCase();
    $[0] = name;
    $[1] = t1;
  } else {
    t1 = $[1];
  }
  let t2;
  // в ячейку попадает и разметка: пока t1 тот же, элемент не пересоздаётся
  if ($[2] !== t1) {
    t2 = _jsx("h3", { children: t1 });
    $[2] = t1;
    $[3] = t2;
  } else {
    t2 = $[3];
  }
  return t2;
}

// вывод компилятора для Title — примерно так, только имена короче.
// «Примерно» тут важно: на этом самом Title настоящий компилятор
// обходится двумя ячейками — значение используется один раз, и он
// сливает его ячейку с ячейкой разметки. Здесь они разведены: так видна механика
function Title(t0) {
  const $ = _c(4); // четыре ячейки: под каждый вход и под каждый результат
  const { name } = t0;
  let t1;
  if ($[0] !== name) {
    t1 = "Привет, " + name.toUpperCase();
    $[0] = name;
    $[1] = t1;
  } else {
    t1 = $[1];
  }
  let t2;
  // в ячейку попадает и разметка: пока t1 тот же, элемент не пересоздаётся
  if ($[2] !== t1) {
    t2 = _jsx("h3", { children: t1 });
    $[2] = t1;
    $[3] = t2;
  } else {
    t2 = $[3];
  }
  return t2;
}

Читать такой код не нужно — но полезно один раз увидеть, чтобы понимать, что происходит: никакой магии, обычные if и сравнения по !==. И заодно это способ проверить, что компилятор действительно включён: в собранном файле появляются вызовы _c.

Ручная мемоизация держится на массиве зависимостей, а массив — это текст, который пишет человек. Система типов следит за ним лишь наполовину: без второго аргумента useMemo не вызвать.

tsx

interface TotalProps {
  price: number;
  count: number;
}

function Total({ price, count }: TotalProps) {
  const sum = React.useMemo(() => price * count);
  return <p>{sum}</p>;
}

страница примера

Сначала предположите, что выведет код

Это всё, что типы могут сказать: массив на месте. Что в нём лежит — вопрос не типов, а данных, которыми пользуется вычисление. Забыли одну переменную — и значение застынет. Цена сто рублей, штук становится две; что напечатает последняя строка?

tsx

interface TotalProps {
  price: number;
  count: number;
}

function Total({ price, count }: TotalProps) {
  const sum = React.useMemo(() => price * count, [price]);
  return <p id="out">{price} × {count} = {sum}</p>;
}

function Cart() {
  const [count, setCount] = React.useState(1);
  return (
    <div>
      <Total price={100} count={count} />
      <button id="inc" onClick={() => setCount(count + 1)}>ещё штука</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Cart />);
setTimeout(() => document.getElementById("inc")!.click(), 50);
setTimeout(() => console.log(document.getElementById("out")!.textContent), 150);

страница примера

Сначала предположите, что выведет код

разбор вывода
«100 × 2 = 100». Компонент перерисовался, count новый, а sum остался от первой отрисовки: React честно исполнил договор — price не менялся, значит, пересчитывать нечего. Ошибка не в React и даже не в useMemo; ошибка в списке, который написал человек и забыл обновить, когда добавлял в формулу второй множитель.

Компилятор списков не пишет. Он смотрит, из чего вычислено значение, и ставит проверку ровно на эти входы — на price и на count. Забыть зависимость невозможно, потому что её никто не перечисляет: она выводится из кода вычисления, а код и есть источник правды.

С useCallback та же болезнь протекает злее: устаревает не число на экране, а замыкание внутри обработчика — то самое замыкание из части I. Дважды нажимаем «плюс один», потом «показать». Что скажет обработчик и что будет на экране?

tsx

function Log() {
  const [count, setCount] = React.useState(0);
  const report = React.useCallback(() => console.log("в обработчике count =", count), []);
  return (
    <div>
      <button id="inc" onClick={() => setCount(count + 1)}>плюс один</button>
      <button id="say" onClick={report}>показать</button>
      <p id="out">на экране count = {count}</p>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Log />);
setTimeout(() => document.getElementById("inc")!.click(), 50);
setTimeout(() => document.getElementById("inc")!.click(), 80);
setTimeout(() => {
  document.getElementById("say")!.click();
  console.log(document.getElementById("out")!.textContent);
}, 110);

страница примера

Сначала предположите, что выведет код

На экране двойка, в обработчике ноль. Функция создана при первой отрисовке и замкнула тогдашний count; пустой массив зависимостей запретил создавать её заново. Такую ошибку не видно ни в разметке, ни в тестах на рендер — она всплывает в проде, когда кнопка отправляет на сервер устаревшее значение.

Правило exhaustive-deps в eslint ругалось бы на оба примера. Но правило только подсказывает, а решает человек — и строчка eslint-disable-next-line стоит ровно одно движение пальцем.

Кеш компилятора не ограничивается числами и функциями: в ячейку попадает и результат JSX-выражения. Это важнее, чем кажется. Элемент — обычный объект-описание; если при новой отрисовке родитель вернул тот же самый объект, React сравнивает ссылки и внутрь компонента не заходит вовсе.

Проверим руками, без всякого компилятора: Heavy печатает строку при каждой отрисовке, а его элемент положен в ячейку. Клик меняет состояние Panel. Сколько строк добавит один клик и какие именно?

tsx

function Heavy() {
  console.log("рендер Heavy");
  return <p>тяжёлое поддерево</p>;
}

function Panel() {
  const [n, setN] = React.useState(0);
  console.log("рендер Panel, n =", n);
  // компилятор кладёт в ячейку каждое JSX-выражение; здесь делаем это руками
  const heavy = React.useMemo(() => <Heavy />, []);
  return (
    <div>
      <button id="inc" onClick={() => setN(n + 1)}>тик {n}</button>
      {heavy}
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Panel />);
setTimeout(() => document.getElementById("inc")!.click(), 50);

страница примера

Сначала предположите, что выведет код

Одну — «рендер Panel». Heavy не перерисовался, хотя никакого memo вокруг него нет и родитель отработал заново. React дошёл до места, где стоит элемент, увидел тот же объект, что и в прошлый раз, и остановился: описание не менялось — значит, и поддерево менять не из чего.

Отсюда следствие, ради которого всё и затевалось. memo сравнивает пропсы уже после того, как родитель их пересоздал; компилятор просто не пересоздаёт — ни объект пропсов, ни элемент. Поэтому под компилятором memo в большинстве мест лишний: он остаётся полезен разве что на границе с кодом, который компилятор не обработал, — со сторонним пакетом или с файлом, который он пропустил.

Кто	Что кеширует	Откуда берутся зависимости
`useMemo`, `useCallback`	одно значение или одну функцию	из массива, который пишете вы
`memo`	результат компонента, если пропсы совпали	сравнение пропсов по ссылке при каждой отрисовке родителя
React Compiler	все значения компонента, включая элементы разметки	выводятся из кода на сборке

Приём старше компилятора, и в этой главе он попадается третий раз: элемент создаётся не там, где меняется состояние, а выше, и приходит пропсом children — объект-описание переживает перерисовку сам собой.

tsx

function Heavy() {
  console.log("рендер Heavy");
  return <p>тяжёлое поддерево</p>;
}

interface PanelProps {
  children: React.ReactNode;
}

function Panel({ children }: PanelProps) {
  const [n, setN] = React.useState(0);
  console.log("рендер Panel, n =", n);
  return (
    <div>
      <button id="inc" onClick={() => setN(n + 1)}>тик {n}</button>
      {children}
    </div>
  );
}

function App() {
  console.log("рендер App");
  return (
    <Panel>
      <Heavy />
    </Panel>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<App />);
setTimeout(() => document.getElementById("inc")!.click(), 50);

страница примера

Сначала предположите, что выведет код

Вывод тот же, что в двух прошлых статьях: App заявку не подавал, элемент <Heavy /> тот же объект, внутрь React не заходит. Разница — в цене: приём требует перестраивать дерево под оптимизацию, а компилятор даёт то же самое, не трогая структуру.

Кеш безопасен ровно настолько, насколько предсказуем код. Компилятор исходит из того, что компонент — чистая функция: те же пропсы и то же состояние дают тот же результат, а во время отрисовки наружу ничего не течёт. Требование не новое — это правила React, о которые вы уже спотыкались в статьях про рендер и про эффекты. Новое здесь то, что за нарушение платят сразу.

Компонент Stamp считает свои вызовы во внешней переменной — обычная «безобидная» отладочная строчка. Его элемент положен в ячейку, как это сделал бы компилятор. Что окажется на экране после двух кликов?

tsx

let calls = 0;

interface StampProps {
  label: string;
}

function Stamp({ label }: StampProps) {
  calls += 1; // побочный эффект в рендере: результат зависит не только от пропсов
  return <span id="stamp">{label} #{calls}</span>;
}

function Page() {
  const [n, setN] = React.useState(0);
  // ровно то, что дописал бы компилятор: пропсы Stamp не менялись
  const stamp = React.useMemo(() => <Stamp label="метка" />, []);
  return (
    <div>
      <button id="inc" onClick={() => setN(n + 1)}>тик {n}</button>
      {stamp}
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Page />);
setTimeout(() => document.getElementById("inc")!.click(), 50);
setTimeout(() => document.getElementById("inc")!.click(), 80);
setTimeout(() => console.log(document.getElementById("stamp")!.textContent), 150);

страница примера

Сначала предположите, что выведет код

разбор вывода
«метка #1»: счётчик застыл. Компонент рассчитывал на то, что его функция выполняется при каждой отрисовке, — и как только вызовы прекратились, он начал врать. Заметьте, что без мемоизации этот код «работал». Это худший вид ошибки: она лежит тихо и ждёт, пока кто-нибудь включит оптимизацию.

Правило	Чего нельзя в теле компонента	Куда это переносится
Отрисовка чиста	менять переменные снаружи, править DOM, отправлять запросы	обработчик события или эффект
Пропсы и состояние не меняют	`items.push(x)`, `props.user.name = "..."`	новый массив или объект (статья «Объекты и массивы в состоянии»)
Ссылки не читают и не пишут при отрисовке	`ref.current` в теле функции	обработчик или эффект (статья про `useRef`)
Хуки — только на верхнем уровне	вызов хука в условии, цикле или после раннего `return`	разделить компонент (статья «Правила хуков и почему они такие»)

Что будет, если правило всё-таки нарушено? Компилятор чаще всего это видит и такой компонент просто не трогает: оставляет как был, сборка проходит, приложение работает — только ускорения не будет. В Next.js это поведение по умолчанию, за него отвечает настройка panicThreshold: "none" — «пропускать то, что не компилируется».

Но видит он не всё. Мутацию, спрятанную в функции из соседнего модуля, статический анализ не поймает — и тогда кеш вступит в силу поверх кода, который на него не рассчитан. Поэтому правила остаются вашей ответственностью, а не заботой сборки. Смотреть за ними глазами не нужно: свежие версии eslint-plugin-react-hooks включают правила самого компилятора, и редактор подчёркивает ровно те места, из-за которых компонент будет пропущен.

Строгий режим React не случайно вызывает компоненты дважды: он ловит ровно эти нарушения заранее — до того, как их найдёт компилятор.

Компилятор выпущен плагином Babel, пакетом babel-plugin-react-compiler, но работает так уже не везде. В Next.js его не приходится прописывать руками: пакет ставится в зависимости разработки, а в конфигурации поднимается флаг верхнего уровня.

tsлистинг · не запускается

// next.config.ts: флаг верхнего уровня, отдельный плагин прописывать не нужно
const nextConfig = {
  reactCompiler: true
};

// вместо true можно передать настройки: annotation обрабатывает только
// компоненты с директивой "use memo" — так въезжают в большой проект по частям
const gradual = {
  reactCompiler: { compilationMode: "annotation" }
};

// next.config.ts: флаг верхнего уровня, отдельный плагин прописывать не нужно
const nextConfig = {
  reactCompiler: true
};

// вместо true можно передать настройки: annotation обрабатывает только
// компоненты с директивой "use memo" — так въезжают в большой проект по частям
const gradual = {
  reactCompiler: { compilationMode: "annotation" }
};

В Vite флага reactCompiler нет, а @vitejs/plugin-react Babel больше не везёт: для компилятора его либо подключают отдельно, либо берут экспериментальный порт на Rust. Путь через Babel — тот, что в документации React: в зависимости разработки ставят @rolldown/plugin-babel, @babel/core и babel-plugin-react-compiler, а в конфиг добавляют готовый пресет.

tsлистинг · не запускается

// vite.config.ts — React Compiler через Babel
import react, { reactCompilerPreset } from '@vitejs/plugin-react'
import babel from '@rolldown/plugin-babel'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react(), babel({ presets: [reactCompilerPreset()] })],
})

// vite.config.ts — React Compiler через Babel
import react, { reactCompilerPreset } from '@vitejs/plugin-react'
import babel from '@rolldown/plugin-babel'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react(), babel({ presets: [reactCompilerPreset()] })],
})

вывод · терминал, vite build --minify false на шаблоне react-ts; vite 8.3.0, @vitejs/plugin-react 6.1.1, @rolldown/plugin-babel 0.2.4, babel-plugin-react-compiler 1.0.0, @babel/core 8.0.5; сборка 14.09.2026, grep по ней 15.09.2026; macOS arm64, Node 26.5.0
$ grep -n "function App" -A5 dist-compiler/assets/index-*.js
11515:function App() {
11516-	const $ = (0, import_compiler_runtime.c)(24);
11517-	const [count, setCount] = (0, import_react.useState)(0);
11518-	let t0;
11519-	let t1;
11520-	if ($[0] === Symbol.for("react.memo_cache_sentinel")) {

В собранном App тот же кеш, что в начале статьи: $ на 24 ячейки заводит функция c из рантайма компилятора, а memo_cache_sentinel — знак пустой ячейки, как наш EMPTY. Второй путь обходится без Babel. Порт компилятора на Rust — пакет oxc-transform-react; ставят его той версии, которую допускает peer-диапазон plugin-react, — самая свежая в него может не попасть. Включается порт одной опцией.

tsлистинг · не запускается

// vite.config.ts — порт компилятора на Rust, без Babel
import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react({ compiler: true })],
})

// vite.config.ts — порт компилятора на Rust, без Babel
import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react({ compiler: true })],
})

вывод · терминал, vite build --minify false на копии шаблона react-ts; vite 8.3.0, @vitejs/plugin-react 6.1.1, oxc-transform-react 0.145.0 — старшая версия в диапазоне peer у plugin-react; папки @babel и babel-plugin-react-compiler на время сборки переименованы, после возвращены; macOS arm64, Node 26.5.0, 14.09.2026
$ grep -n "function App" -A5 dist-rust/assets/index-*.js
11515:function App() {
11516-	const $ = (0, import_compiler_runtime.c)(24);
11517-	const [count, setCount] = (0, import_react.useState)(0);
11518-	let t0;
11519-	let t1;
11520-	if ($[0] === Symbol.for("react.memo_cache_sentinel")) {
$ # тот же проект с plugins: [react()] — для сравнения
11495:function App() {
11496-	const [count, setCount] = (0, import_react.useState)(0);
11497-	return /* @__PURE__ */ (0, import_jsx_runtime.jsxs)(import_jsx_runtime.Fragment, { children: [

Строки те же, что у сборки через Babel, хотя Babel в ней не участвовал, а без compiler: true у той же функции нет ни ячеек, ни проверок. В Next порт на Rust работает внутри Turbopack и включается второй настройкой рядом с первой — пакет Babel-плагина тогда не нужен.

tsлистинг · не запускается

// next.config.ts — порт компилятора на Rust внутри Turbopack
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

export default nextConfig;

// next.config.ts — порт компилятора на Rust внутри Turbopack
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

export default nextConfig;

вывод · терминал, next 16.3.5 (Turbopack), babel-plugin-react-compiler не установлен; «…» — остальной лог сборки опущен; macOS arm64, Node 26.5.0, 14.09.2026
$ npx next build
▲ Next.js 16.3.5 (Turbopack)
✓ Running next.config.ts took 56ms
- Experiments (use with caution):
  ✓ turbopackRustReactCompiler
  Creating an optimized production build ...
✓ Compiled successfully in 1564ms
…
.next/static/chunks/0m9b9g22yzobb.js (next.config: reactCompiler: true, experimental.turbopackRustReactCompiler: true; babel-plugin-react-compiler НЕ установлен):
(globalThis.TURBOPACK||(globalThis.TURBOPACK=[])).push(["object"==typeof document?document.currentScript:void 0,79474,(t,e,r)=>{"use strict";var c=t.r(71645).__CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE;r.c=function(t){return c.H.useMemoCache(t)}},932,(t,e,r)=>{"use strict";t.i(47167),e.exports=t.r(79474)},20501,t=>{"use strict";var e=t.i(43476),r=t.i(932),c=t.i(71645);t.s(["Price",0,function(t){let i,s,u,o=(0,r.c)(8),{base:n}=t,[_,T]=(0,c.useState)(1);return(o[0]!==_?(i=()=>T(_+1),o[0]=_,o[1]=i):i=o[1],o[2]!==n)?(s=n+" ₽",o[2]=n,o[3]=s):s=o[3],o[4]!==_||o[5]!==i||o[6]!==s?(u=(0,e.jsxs)("button",{onClick:i,children:[_," × ",s]}),o[4]=_,o[5]=i,o[6]=s,o[7]=u):u=o[7],u}],20501)}]);
$ # тот же конфиг без turbopackRustReactCompiler
▲ Next.js 16.3.5 (Turbopack)
✓ Running next.config.ts took 15ms
  Creating an optimized production build ...
> Build error occurred
Error: Turbopack build failed with 1 error:
./next.config.ts
Error: Failed to resolve package babel-plugin-react-compiler while attempting to resolve React Compiler
React compiler is enabled in next.config.ts. We attempted to resolve React Compiler relative to the next package. Is babel-plugin-react-compiler installed in your node_modules directory?
    at ignore-listed frames

Лог честно предупредил об эксперименте, а Price в куске собран с кешем: o=(0,r.c)(8) — восемь ячеек, o[0]!==_ — проверка входа. Без второй настройки тот же флаг ищет Babel-плагин, а раз пакета нет, сборка падает. Оба порта пока экспериментальные, а настройка Next работает только под Turbopack. Какой путь где действует и с какой версии, сведено в таблицу с датой в статье про компилятор файла.

Рантайм-часть в React 19 уже внутри пакета react; для проектов на 17 и 18 ставят отдельный react-compiler-runtime. По умолчанию компилятор работает в режиме infer: сам решает, что в файле компонент и хук, и обрабатывает всё, что нашёл.

Один компонент можно вывести из-под компилятора директивой — строкой в начале тела функции, как "use strict" из части I. Это временная мера для места, которое пока не привели в порядок.

tsx

interface WidgetProps {
  points: number[];
}

function Widget({ points }: WidgetProps) {
  "use no memo"; // временно вывели компонент из-под компилятора
  const total = points.reduce((sum, n) => sum + n, 0);
  return <p>сумма: {total}</p>;
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Widget points={[1, 2, 3]} />);

страница примера

Сначала предположите, что выведет код

Существующие useMemo и useCallback компилятор не выбрасывает: он старается сохранить обещанное ими, а если сохранить не может — не трогает такой компонент целиком. Поэтому включать компилятор можно, не устраивая чистку: сначала флаг, потом, попадая в файл по другому делу, снимаете обёртки. Снимать стоит — чем меньше рукописных массивов, тем меньше мест, где значение застынет.

Было в коде	Под компилятором
`useMemo` вокруг вычисления	удалить: то же самое сделает компилятор, и зависимость не забудет
`useCallback` ради стабильной ссылки	удалить
`memo` вокруг компонента	обычно не нужен; оставить на границе с необработанным кодом
`useRef`, чтобы значение пережило отрисовку	оставить: это память, а не мемоизация
`useMemo`, без которого компонент врёт	чинить логику: правильность не должна зависеть от кеша

Кеш не бесплатен: сборка идёт дольше, а в готовый файл добавляются те самые ячейки и проверки. Для обычного приложения обмен выгодный, но «включили — и везде стало быстрее» не обещает никто: компонент, который тормозит из-за десяти тысяч узлов в разметке, от кеша не оживёт.

Последняя строка таблицы — правило, которое переживает любой компилятор. Мемоизация не входит в договор React: и useMemo, и компилятор имеют право пересчитать значение когда угодно. Если компонент ломается без кеша, он сломан и с кешем — просто реже. Кеш про скорость, а не про поведение; что именно тормозит на самом деле, разбиралось в первой статье этой главы.

React Compiler — шаг сборки: он читает компоненты и дописывает кеш из ячеек, который вы раньше писали руками через useMemo и useCallback.
Зависимости он выводит из кода, поэтому забытая зависимость и застывшее значение перестают быть возможными.
В ячейки попадают и элементы JSX: тот же объект-описание — React не заходит в поддерево, и memo нужен куда реже.
Плата — правила React: чистая отрисовка, никакой мутации пропсов и состояния, ссылки и побочные действия вне тела компонента.
Нарушение компилятор обычно замечает и просто пропускает компонент: сборка не падает, но и ускорения не будет.
Правильность не должна зависеть от мемоизации — ни ручной, ни автоматической: кеш про скорость, а не про поведение.

1/4Внутри компонента написано const sum = React.useMemo(() => price * count, [price]). Пропс price остаётся равным 100, а count меняется с 1 на 2. Что покажет компонент?

2/4Компилятор встретил компонент, который во время отрисовки увеличивает переменную из внешнего модуля. Что произойдёт при сборке?

3/4Что, кроме чисел, строк и функций, компилятор кладёт в ячейки кеша?

4/4В проекте включили компилятор. Нужно ли сразу удалить все useMemo и useCallback, чтобы он заработал?

Зависимость, которая устарела

Список должен отфильтроваться по запросу, но после клика печатает всё подряд. Найдите причину и почините двумя способами — с массивом зависимостей и без него. Какой из двух переживёт следующую правку кода?

tsx

// массив объявлен снаружи — при каждой отрисовке в List приходит тот же объект
const ITEMS = ["кот", "код", "кодер"];

interface ListProps {
  items: string[];
  query: string;
}

function List({ items, query }: ListProps) {
  // список не откликается на новый запрос — почините
  const found = React.useMemo(() => items.filter((it) => it.includes(query)), [items]);
  return <p id="out">{found.join(", ")}</p>;
}

function App() {
  const [query, setQuery] = React.useState("");
  return (
    <div>
      <List items={ITEMS} query={query} />
      <button id="find" onClick={() => setQuery("код")}>искать «код»</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<App />);
setTimeout(() => document.getElementById("find")!.click(), 50);
// кот, код, кодер — а нужно код, кодер
setTimeout(() => console.log(document.getElementById("out")!.textContent), 150);

страница примера

Сначала предположите, что выведет код

Вычисление читает items и query, а в массиве перечислен только items. Пока пропс items тот же объект, значение берётся из кеша — фильтрация с новым запросом не выполняется.

Первый способ — дописать зависимость:

jsлистинг · не запускается

const found = React.useMemo(() => items.filter((it) => it.includes(query)), [items, query]);

const found = React.useMemo(() => items.filter((it) => it.includes(query)), [items, query]);

Второй — убрать мемоизацию совсем:

jsлистинг · не запускается

const found = items.filter((it) => it.includes(query));

const found = items.filter((it) => it.includes(query));

Фильтрация трёх строк дешевле, чем сравнение зависимостей вокруг неё; useMemo здесь никогда не окупался. Переживёт правку второй способ: у него нет списка, который можно забыть обновить, добавив в формулу ещё один пропс. Под компилятором так и пишут — а кеш, если он нужен, появится на сборке.

И отдельно про строку const ITEMS над компонентами. Если бы массив создавался прямо в разметке — items={["кот", "код", "кодер"]}, — в List при каждой отрисовке приходил бы новый объект, зависимость items менялась бы всегда, и useMemo честно пересчитывал бы всё заново. Ошибка бы спряталась, а мемоизация перестала бы работать вовсе — заметить такое можно разве что с секундомером. Ручная мемоизация чувствительна к подобным мелочам; зависимости, выведенные из кода, — нет.

Почему компилятор пропустит этот компонент

В Row два нарушения правил React — из-за них компилятор оставит компонент без оптимизации. Назовите оба и перепишите компонент так, чтобы нумерация и текст пришли снаружи, а тело функции стало чистым.

tsx

let lastNumber = 0;

interface RowProps {
  text: string;
}

function Row({ text }: RowProps) {
  lastNumber += 1;
  const seen = React.useRef(0);
  seen.current += 1;
  return (
    <li>
      {lastNumber}. {text} (показан {seen.current} раз)
    </li>
  );
}

function List() {
  const [n, setN] = React.useState(0);
  return (
    <div>
      <button id="inc" onClick={() => setN(n + 1)}>тик {n}</button>
      <ul>
        <Row text="первая" />
        <Row text="вторая" />
      </ul>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<List />);
setTimeout(() => document.getElementById("inc")!.click(), 50);

страница примера

Сначала предположите, что выведет код

Первое нарушение — lastNumber += 1: отрисовка меняет переменную вне компонента, и результат зависит от того, сколько раз функцию вызвали. Второе — seen.current += 1: запись в ссылку во время отрисовки, та же побочность, только спрятанная в useRef.

Оба счётчика не нужны: номер строки — это данные, и они приходят от родителя.

tsxлистинг · не запускается

interface RowProps {
  number: number;
  text: string;
}

function Row({ number, text }: RowProps) {
  return <li>{number}. {text}</li>;
}

function List() {
  const [n, setN] = React.useState(0);
  const rows = ["первая", "вторая"];
  return (
    <div>
      <button onClick={() => setN(n + 1)}>тик {n}</button>
      <ul>
        {rows.map((text, i) => (
          <Row key={text} number={i + 1} text={text} />
        ))}
      </ul>
    </div>
  );
}

interface RowProps {
  number: number;
  text: string;
}

function Row({ number, text }: RowProps) {
  return <li>{number}. {text}</li>;
}

function List() {
  const [n, setN] = React.useState(0);
  const rows = ["первая", "вторая"];
  return (
    <div>
      <button onClick={() => setN(n + 1)}>тик {n}</button>
      <ul>
        {rows.map((text, i) => (
          <Row key={text} number={i + 1} text={text} />
        ))}
      </ul>
    </div>
  );
}

Теперь Row — чистая функция от пропсов: компилятор его оптимизирует, а число вызовов перестаёт быть видимым снаружи. Считать отрисовки для отладки по-прежнему можно — но console.log, а не записью в состояние программы.

Убрать ручную мемоизацию

Проект перевели на компилятор. Перепишите Card так, как его написали бы сегодня, и скажите, что изменится в поведении.

tsx

interface User {
  name: string;
  age: number;
}

interface CardProps {
  user: User;
  onPick: (name: string) => void;
}

function Card({ user, onPick }: CardProps) {
  const title = React.useMemo(() => user.name.toUpperCase(), [user.name]);
  const style = React.useMemo(() => ({ opacity: user.age >= 18 ? 1 : 0.5 }), [user.age]);
  const handlePick = React.useCallback(() => onPick(user.name), [onPick, user.name]);
  return (
    <button style={style} onClick={handlePick}>
      {title}
    </button>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(
  <Card user={{ name: "Рико", age: 30 }} onPick={(name) => console.log("выбран", name)} />
);

страница примера

Сначала предположите, что выведет код

Уходят все три обёртки — и вместе с ними три массива зависимостей:

tsxлистинг · не запускается

function Card({ user, onPick }: CardProps) {
  const title = user.name.toUpperCase();
  const style = { opacity: user.age >= 18 ? 1 : 0.5 };
  const handlePick = () => onPick(user.name);
  return (
    <button style={style} onClick={handlePick}>
      {title}
    </button>
  );
}

function Card({ user, onPick }: CardProps) {
  const title = user.name.toUpperCase();
  const style = { opacity: user.age >= 18 ? 1 : 0.5 };
  const handlePick = () => onPick(user.name);
  return (
    <button style={style} onClick={handlePick}>
      {title}
    </button>
  );
}

В поведении не меняется ничего: компилятор заведёт ячейки под title, style, handlePick и под сам элемент кнопки — с теми же зависимостями, только выведенными из кода. Разница в другом: строка [onPick, user.name] больше не может разойтись с телом функции при следующей правке.

Пока компилятор не включён, такой код тоже верен — просто объект стиля и обработчик создаются заново при каждой отрисовке. Это и есть нормальная цена работы React, о которой шла речь в первой статье главы.

React Compiler: мемоизация уходит из кода

Видеоразбор темы за 5–7 минут

Что компилятор делает с вашим кодомШаг сборки, который дописывает ячейки кеша

Массив зависимостей пишете вы — и он портитсяЗабытая зависимость и застывшее значение

В кеш попадает и разметкаПочему под компилятором memo нужен реже

Цена: правила ReactЧто ломается от кеша и что компилятор пропускает

Включение и старая мемоизацияФлаг, директива и что делать с готовыми useMemo

Итогошпаргалка по теме

Проверьте себявопросы по теме

Задачизадачи с решениями

Зависимость, которая устарела

Почему компилятор пропустит этот компонент

Убрать ручную мемоизацию