Триггер, рендер, коммит

В части II триггером были вы сами: изменили массив задач — тут же позвали render(), и разметка перестроилась раньше, чем обработчик дошёл до следующей строки. В React триггера два — первый root.render() и любой вызов сеттера из useState, — и ни один из них ничего не перестраивает. Оба лишь записывают заявку. Проверьте на первом: в каком порядке напечатаются четыре строки?

function App() {
  console.log("рендер App");
  return <p>Привет</p>;
}

const element = <App />;
console.log("элемент создан, type —", typeof element.type);

const root = ReactDOM.createRoot(document.getElementById("root")!);
console.log("до root.render()");
root.render(element);
console.log("после root.render()");

Строка «рендер App» — последняя. <App /> не вызывает App: это объект-описание из статьи «JSX — это не HTML», и в его поле type лежит сама функция, нетронутая. root.render() тоже её не вызывает — он кладёт описание в очередь и возвращает управление. React доберётся до заявки, когда текущий скрипт отработает до конца. Ровно поэтому примеры учебника нажимают кнопку через setTimeout: сразу после root.render() кнопки в DOM ещё нет.

Второй триггер — сеттер состояния. Он делает то же самое: записывает заявку и возвращается. Что напечатается раньше — «после setCount» или «рендер, count = 1»?

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

ReactDOM.createRoot(document.getElementById("root")!).render(<Counter />);
// первая отрисовка случится после этого скрипта, поэтому нажимаем с задержкой
setTimeout(() => document.getElementById("inc")!.click(), 50);

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

Компонент не решает, когда ему выполняться. Он функция, а вызывает её React — когда дойдёт до заявки.

Рендер — это вызов функции компонента: React зовёт её, получает описание разметки и на этом шаге больше ничего не делает. В предыдущих статьях этот шаг назывался отрисовкой, и его уже считали по console.log в теле компонента. Вопрос, который там не поднимался: чьи функции вызываются по одной заявке? Ниже состояние есть только у Page. Сколько строк «рендер» добавит один клик — и какие именно?

interface TitleProps {
  text: string;
}

function Title({ text }: TitleProps) {
  console.log("рендер Title:", text);
  return <h3>{text}</h3>;
}

function Footer() {
  console.log("рендер Footer");
  return <p>Ни пропсов, ни состояния</p>;
}

function Page() {
  const [count, setCount] = React.useState(0);
  console.log("рендер Page, count =", count);
  return (
    <div>
      <Title text="Счётчик" />
      <button id="inc" onClick={() => setCount(count + 1)}>Нажато: {count}</button>
      <Footer />
    </div>
  );
}

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

Три строки на первую отрисовку и ещё три после клика. Title получил тот же текст «Счётчик», у Footer вообще нет ни пропсов, ни состояния — и всё же обе функции вызвались заново. React не сравнивает пропсы, прежде чем вызвать компонент: описание, которое вернул Page, содержит <Title /> и <Footer />, значит, их функции нужно вызвать, чтобы узнать, что внутри. Рендер идёт вниз по дереву до самого конца.

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

Вниз — да, но не вверх и не вбок. Два одинаковых счётчика в одном родителе; клик по левому — что напечатается после первых трёх строк?

interface CounterProps {
  name: string;
}

function Counter({ name }: CounterProps) {
  const [count, setCount] = React.useState(0);
  console.log("рендер", name + ", count =", count);
  return (
    <button id={name} onClick={() => setCount(count + 1)}>
      {name}: {count}
    </button>
  );
}

function App() {
  console.log("рендер App");
  return (
    <div>
      <Counter name="left" />
      <Counter name="right" />
    </div>
  );
}

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

Одна строка. Заявку подал левый счётчик — перерисовался он и всё, что он возвращает (здесь — одна кнопка). App не вызывался: его состояние не менялось, а описание, из которого растёт левый счётчик, у React уже есть. Правый счётчик не вызывался тем более: его ячейка состояния лежит отдельно, как показано в статье про useState.

Правило рендера в одну строку: перерисовывается компонент, чьё состояние изменилось, и всё, что он возвращает. Родители и соседи — нет.

Пока идут вызовы функций, страница неподвижна: React собирает новые описания, сравнивает их со старыми и лишь потом, одним заходом, вносит разницу в DOM. Этот последний шаг и называется коммитом. Границу между рендером и коммитом можно увидеть, подсмотрев в DOM прямо из тела компонента — в рабочем коде так не делают, но для диагностики сгодится. Что окажется «на экране» во второй строке вывода?

function Counter() {
  const [count, setCount] = React.useState(0);
  // подсматриваем в DOM из рендера — только чтобы увидеть шаг; в рабочем коде так нельзя
  const onScreen = document.getElementById("out")?.textContent;
  console.log("рендер: count =", count, "| на экране:", onScreen);
  return (
    <div>
      <p id="out">{count}</p>
      <button id="inc" onClick={() => setCount(count + 1)}>+1</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Counter />);
setTimeout(() => document.getElementById("inc")!.click(), 50);
setTimeout(() => {
  console.log("после коммита: на экране", document.getElementById("out")!.textContent);
}, 100);

В первом рендере на экране undefined: DOM ещё пуст, абзаца #out не существует — его создаст коммит. Во втором count уже единица, а в DOM по-прежнему ноль: функция выполняется, коммит впереди. И только третья строка, напечатанная из таймера, видит новое число.

На коммите React правит ровно то, что изменилось: текстовый узел внутри <p> получит новое значение, а сам абзац, кнопка и обёртка останутся теми же объектами — та самая гарантия из статьи «Зачем React, если вы уже писали рендер из состояния», благодаря которой поле ввода не теряет фокус. Если описание совпало со старым целиком, коммиту нечего делать, и DOM не тронут вовсе, хотя рендер состоялся.

Слово «коммит» здесь значит то же, что в базах данных и git: изменения копятся, а применяются одним неделимым шагом. Пользователь не увидит DOM «наполовину новым».

Раз рендер — обычный вызов функции без последствий для DOM, React позволяет себе вольности. Он может вызвать компонент, а результат выбросить, так и не дойдя до коммита: например, если за время рендера пришла заявка поважнее. Может вызвать функцию дважды подряд, чтобы нечистый рендер выдал себя, — так при разработке делает режим StrictMode. Может менять порядок и число вызовов от версии к версии. Всё это безопасно при одном условии: у вызова нет никаких следствий, кроме возвращённого описания. Такую функцию называют чистой — те же пропсы и состояние на входе, то же описание на выходе, и ничего не изменилось вокруг.

Вот компонент, который условие нарушает: он нумерует гостей во внешней переменной. При первой отрисовке список выглядит правильно — 1, 2, 3. Что в нём окажется после клика по «Перерисовать»?

let guests = 0; // общая переменная снаружи компонента

function Guest() {
  guests = guests + 1; // рендер меняет то, что существовало до вызова
  return <li>Гость №{guests}</li>;
}

function List() {
  const [tick, setTick] = React.useState(0);
  return (
    <div>
      <ul>
        <Guest />
        <Guest />
        <Guest />
      </ul>
      <button id="again" onClick={() => setTick(tick + 1)}>Перерисовать ({tick})</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<List />);
setTimeout(() => document.getElementById("again")!.click(), 50);
setTimeout(() => {
  const names = Array.from(document.querySelectorAll("li"), (li) => li.textContent);
  console.log(names);
}, 100);

Гости стали четвёртым, пятым и шестым, хотя ни пропсов, ни состояния у них нет и «по смыслу» ничего не менялось. Номер зависит от того, сколько раз и в каком порядке React вызывал функцию, — а этого React никому не обещал. Включите в таком проекте StrictMode — и уже при первой отрисовке будет 2, 4, 6.

Правил чистоты три, и все они про одно: не трогать то, что существовало до вызова. Нельзя менять внешние переменные, пропсы и объекты из состояния — только читать. Нельзя трогать DOM: ни создавать узлы, ни менять document.title, ни вешать обработчики — всё это работа коммита, а для побочных действий после коммита есть отдельный механизм — эффекты; знакомство с ними начинается со статьи «useEffect — это синхронизация, а не жизненный цикл». И нельзя вызывать сеттер состояния: это триггер, а триггер посреди рендера — заявка на ещё один рендер.

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

function Loop() {
  const [count, setCount] = React.useState(0);
  console.log("рендер", count);
  setCount(count + 1); // триггер прямо во время рендера
  return <p>{count}</p>;
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Loop />);

Главный инструмент этой главы — console.log первой строкой в теле компонента, с именем компонента и значением, ради которого он рисуется. Лог в обработчике считает триггеры, лог в таймере после клика показывает результат коммита, и только лог в теле считает рендеры. Но одну особенность стоит знать заранее: не всякий триггер доходит до рендера. Ниже три клика — сколько строк «рендер» они добавят?

function Counter() {
  const [count, setCount] = React.useState(0);
  console.log("рендер, count =", count);
  return (
    <div>
      <button id="same" onClick={() => setCount(count)}>Оставить как есть</button>
      <button id="inc" onClick={() => setCount(count + 1)}>+1</button>
    </div>
  );
}

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

Первый клик по «Оставить как есть» не напечатал ничего: сеттер сравнил новое значение со старым через Object.is, увидел то же самое число и заявку не подал. А вот третий клик, точно такой же, строку добавил. React вправе так поступить: обещание звучит как «компонент и его дети не будут перерисованы», а на деле React иногда всё же вызывает саму функцию, чтобы убедиться, что состояние не изменилось, — и только потом бросает работу, не трогая ни детей, ни DOM. Лишняя строка в консоли — не ошибка в вашем коде, а ещё одна причина, по которой рендер должен быть чистым.

Отсюда важное следствие для объектов и массивов: Object.is сравнивает ссылки, и объект, изменённый на месте, — это «то же самое». Триггера не будет, как бы сильно вы ни поменяли его поля. Копия вместо изменения на месте — не стилистика, а единственный способ подать заявку; этому посвящена отдельная статья главы.