Своя очередь обновлений и своя пачка

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

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

Перед запуском ответьте: что напечатают две последние строки? Заявок в обеих очередях поровну, и подаются они одинаково — тремя одинаковыми вызовами.

type Updater = (prev: number) => number;
type Update = number | Updater;

interface Cell {
  value: number; // то, что компонент увидит в следующей отрисовке
  queue: Update[]; // заявки, накопленные с прошлого разбора
}

function createCell(initial: number): Cell {
  return { value: initial, queue: [] };
}

// сеттер ничего не вычисляет — он только кладёт заявку в конец очереди
function set(cell: Cell, update: Update): void {
  cell.queue.push(update);
}

function flush(cell: Cell): void {
  let next = cell.value;
  for (const update of cell.queue) {
    // число заменяет накопленное, функция получает его и преобразует
    next = typeof update === "function" ? update(next) : update;
  }
  cell.queue.length = 0;
  cell.value = next;
}

const plain = createCell(0);
const snapshot = plain.value; // ровно это число видит отрисовка
set(plain, snapshot + 1);
set(plain, snapshot + 1);
set(plain, snapshot + 1);
flush(plain);
console.log("три значения:", plain.value);

const smart = createCell(0);
set(smart, (n) => n + 1);
set(smart, (n) => n + 1);
set(smart, (n) => n + 1);
flush(smart);
console.log("три обновителя:", smart.value);

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

Посмотрите на строку cell.queue.length = 0. Очередь опустошается ровно в момент разбора, и следующее событие копит заявки уже поверх нового значения: обновитель, поданный вторым нажатием, получит то, что накопило первое, а не то, с чего ячейка начинала. У ячейки, к которой никто не обращался, цикл не сделает ни шага, и значение останется прежним.

flush мы позвали руками. В React его руками не зовёт никто, и вопрос «когда именно» совсем не праздный: от ответа зависит и число отрисовок, и то, что успеет увидеть обработчик. Спросим у настоящего React — он ответит точно.

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

function Counter() {
  const [count, setCount] = React.useState(0);
  console.log("отрисовка, count =", count);
  const onClick = () => {
    queueMicrotask(() => console.log("микрозадача, поставленная ДО set"));
    setCount(count + 1);
    queueMicrotask(() => console.log("микрозадача, поставленная ПОСЛЕ set"));
    console.log("обработчик кончился");
  };
  return <button id="inc" onClick={onClick}>Нажато: {count}</button>;
}

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

Отрисовка встала между микрозадачами — ровно туда, куда встала бы микрозадача, поставленная в момент setCount. И обработчик успел доработать целиком: его собственная строка напечаталась раньше их всех. Никакой особой магии в объединении обновлений нет — есть отложенный на микрозадачу разбор.

Микрозадачи разбирались в статье «Микрозадачи и макрозадачи»: браузер выполняет их, когда текущий кусок кода дошёл до конца, — раньше любого setTimeout и раньше, чем нарисуется кадр.

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

// createCell и flush из первого примера статьи уже готовы — здесь только новое
type Update = number | ((prev: number) => number);
interface Cell {
  value: number;
  queue: Update[];
}
declare function createCell(initial: number): Cell;
declare function flush(cell: Cell): void;

const dirty = new Set<Cell>(); // ячейки, у которых накопились заявки
let scheduled = false;
let onFlushed = (): void => {}; // сюда в следующем разделе встанет отрисовка

function set(cell: Cell, update: Update): void {
  cell.queue.push(update);
  dirty.add(cell);
  schedule();
}

function schedule(): void {
  if (scheduled) return; // разбор уже заказан — второй такой же не нужен
  scheduled = true;
  queueMicrotask(() => {
    scheduled = false;
    for (const cell of dirty) flush(cell);
    dirty.clear();
    onFlushed();
  });
}

const count = createCell(0);
onFlushed = () => console.log("очередь разобрана, count =", count.value);

console.log("обработчик пошёл");
set(count, count.value + 1);
set(count, count.value + 1);
console.log("обработчик кончился, в ячейке", count.value);

Вторая строка вывода — самая говорящая: обработчик кончился, а в ячейке по-прежнему ноль. Ничего другого он увидеть и не мог — заявки лежат в очереди, разбор ещё не наступил. «Сеттер не присваивает, а планирует» из статьи про снимок теперь не утверждение, а видимое следствие трёх строк schedule.

Флажок scheduled стоит того, чтобы посмотреть на него отдельно. Без него каждый set заказывал бы свою микрозадачу: три вызова — три разбора и три отрисовки. С ним первый set события заказывает разбор, а остальные видят scheduled === true и молча дописывают в очередь.

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

И вот здесь целиком помещается статья про снимок. Строка const value = count.value выполняется в момент вызова функции, а вызывают эту функцию после разбора очереди. Обработчик, созданный внутри, замкнул это число — и другого не увидит, сколько бы событий ни прошло. Ровно так же, как замыкание из части I.

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

// очередь и планировщик из прошлых разделов лежат в подложке
type Update = number | ((prev: number) => number);
interface Cell {
  value: number;
  queue: Update[];
}
declare function createCell(initial: number): Cell;
declare function set(cell: Cell, update: Update): void;
declare let onFlushed: () => void;

const count = createCell(0);
let plainClick = (): void => {};
let smartClick = (): void => {};

// «компонент»: обычная функция, которую зовут заново после каждого разбора
function Counter(): void {
  const value = count.value; // снимок берётся здесь — уже после разбора
  console.log("отрисовка, count =", value);
  plainClick = () => {
    set(count, value + 1);
    set(count, value + 1);
    set(count, value + 1);
  };
  smartClick = () => {
    set(count, (n) => n + 1);
    set(count, (n) => n + 1);
    set(count, (n) => n + 1);
  };
}

onFlushed = Counter; // разобрали очередь — зовём компонент заново
Counter(); // первая отрисовка
plainClick(); // первое нажатие
setTimeout(() => smartClick(), 0); // второе — уже другим событием

Ноль, единица, четвёрка. Три set(count, value + 1) положили в очередь три единицы, и разбор оставил последнюю; три обновителя сложились друг на друга поверх неё. Никто ничего не «замораживал» специально: у функции просто нет способа увидеть значение, появившееся после её вызова.

Второе нажатие отправлено через setTimeout нарочно: позови мы оба обработчика подряд, планировщик сложил бы их в одно событие — вышло бы одно нажатие с шестью заявками.

Заодно объяснилось и то, почему обработчик приходится заводить заново на каждой отрисовке. Он не «обновляется» — он новый, потому что новое у него замыкание. Старый никуда не делся, просто на кнопке теперь висит свежий; в React то же самое происходит с onClick в разметке.

Очередь у каждого состояния своя — это мы уже собрали. А планировщик один на всех, и отсюда берётся правило «одна отрисовка на событие»: сколько бы ячеек ни изменилось, разбор наступает один раз и onFlushed зовётся один раз.

Две ячейки, обработчик меняет обе, и вызывается он дважды: сразу и из таймера. Сколько строк «отрисовка» будет в выводе?

type Update = number | ((prev: number) => number);
interface Cell {
  value: number;
  queue: Update[];
}
declare function createCell(initial: number): Cell;
declare function set(cell: Cell, update: Update): void;
declare let onFlushed: () => void;

const count = createCell(0);
const step = createCell(1); // вторая ячейка со своей собственной очередью
let onClick = (): void => {};

function Panel(): void {
  const c = count.value;
  const s = step.value;
  console.log("отрисовка: счёт", c, "шаг", s);
  onClick = () => {
    set(count, (n) => n + s);
    set(step, (n) => n + 1);
    console.log("обе заявки поданы");
  };
}

onFlushed = Panel;
Panel();
onClick(); // нажатие
setTimeout(() => onClick(), 0); // и то же самое из таймера

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

И главное: вторая пачка пришла из таймера, а собралась точно так же. Нашему планировщику всё равно, откуда позвали set, — он смотрит на границу микрозадачи, а не на обработчик. Именно этим React 18 отличается от семнадцатого: там объединение делала обёртка вокруг собственных обработчиков React, и за их пределами — в таймере, в .then, в подписке — каждое обновление давало свою отрисовку. Перенос заказа в микрозадачу сделал объединение автоматическим везде.

dirty — множество, поэтому две заявки в одну ячейку не заставят разобрать её дважды. React ведёт список «корней, у которых есть работа», примерно так же.

Теперь сравнение честное: тот же сценарий, что в третьем разделе, но на настоящем React.

function Counter() {
  const [count, setCount] = React.useState(0);
  console.log("отрисовка, count =", count);
  return (
    <p>
      Нажато: {count}{" "}
      <button
        id="plain"
        onClick={() => {
          setCount(count + 1);
          setCount(count + 1);
          setCount(count + 1);
        }}
      >
        три значения
      </button>{" "}
      <button
        id="smart"
        onClick={() => {
          setCount((n) => n + 1);
          setCount((n) => n + 1);
          setCount((n) => n + 1);
        }}
      >
        три обновителя
      </button>
    </p>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Counter />);
setTimeout(() => document.getElementById("plain")!.click(), 50);
setTimeout(() => document.getElementById("smart")!.click(), 100);

Три строки — те же самые. Миниатюра не «похожа» на React и уж точно не устроена как он внутри; она повторяет его наблюдаемое поведение в той части, ради которой писалась. Дальше расхождения начинаются быстро.

Самая заметная строка — четвёртая. Наш планировщик перерисовывает после любого разбора. React бережливее и проверяет раньше: заявку, пришедшую в пустую очередь, он вычисляет прямо в сеттере и, если Object.is говорит «то же самое», отрисовку не заказывает вовсе — обработчик с setCount(count) в нетронутом компоненте не даёт новой строки в консоли. Как это выглядит изнутри и где у этой бережливости граница — во врезке ниже. Что именно сравнивает Object.is и почему это правило больно бьёт по объектам, разбирает следующая статья главы; починить миниатюру предлагает вторая задача.

function Counter() {
  console.log("тело началось");
  const [count, setCount] = React.useState(0);
  console.log("отрисовка, count =", count);
  const onClick = () => {
    // console.log в обновителе нарушает чистоту нарочно: иначе не увидеть, кто и когда его зовёт
    setCount((n) => {
      console.log("обновитель 1, n =", n);
      return n + 1;
    });
    setCount((n) => {
      console.log("обновитель 2, n =", n);
      return n + 1;
    });
    console.log("обработчик кончился");
  };
  return <button id="inc" onClick={onClick}>Нажато: {count}</button>;
}

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