Начиная с React 18 рендер можно прервать: срочные обновления обгоняют несрочные, даже если React уже взялся за несрочное. Если задуматься, вопросов много:

• Как React посреди рендера отдаёт поток браузеру, чтобы тот обработал ввод, а потом продолжает с того же места?

• Почему до React 16 он так не умел?

• Кто решает, какие обновления срочные, и почему большинство рендеров не прерывается вообще?

• Что происходит с незакоммиченными обновлениями, когда пришло что-то срочное?

• И главное, как обновления, которые выстраиваются в очередь, не путаются в порядке, если срочное пришло позже, но должно обогнать несрочные?

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

Всё разбираем на одном простом примере — поиске по списку.

function Search() {
  const [inputQuery, setInputQuery] = useState("");
  const [listQuery, setListQuery] = useState("");

  const onChange = (e) => {
    const { value } = e.target;
    setInputQuery(value);
    startTransition(() => setListQuery(value));
  };

  return <>
    <input value={inputQuery} onChange={onChange} />
    <List listQuery={listQuery} />
  </>;
}

const List = memo(({ listQuery }) => filterProducts(listQuery).map(
  (p) => <Row key={p.id} item={p} />
));

Поле ввода обновляется сразу, а список — через startTransition.

1. Как React обновляет интерфейс

Пару слов, чтобы мы вкладывали один и тот же смысл в термины.

У React два дерева: current - соответствует тому, что сейчас на экране, и WIP-дерево (work-in-progress) — его React строит, когда что-то меняется.

React не правит current на месте. Он строит рядом WIP-дерево: вызывает компоненты, сравнивает их новый результат с тем, что лежит в current, и отмечает, что поменялось. Это и есть рендер. В React это слово не про рисование: работа идёт в памяти, DOM и экран не меняются.

Когда WIP-дерево готово, React применяет найденные изменения к DOM, и WIP-дерево становится новым current. Это коммит. После него браузер перерисовывает страницу.

Узлы двух деревьев связаны попарно ссылкой alternate: обходя WIP-дерево, React по этой ссылке находит парный узел в current и берёт оттуда прошлое состояние хуков и прошлый результат рендера. Узлы WIP-дерева обычно даже не создаются с нуля. После коммита деревья меняются ролями: WIP-дерево становится current, а прежнее current идёт в дело при следующем рендере: из его узлов React и строит новое WIP-дерево, перезаписывая их новыми данными.

Что является причиной рендера? Отдельный компонент чаще всего перерендеривается по одной из трёх причин:

• изменилось его состояние;

• перерендерился родитель;

• изменился контекст.

А как же пропсы? Их изменение — не отдельная причина: новые пропсы появляются, только когда перерендерился родитель.

Но если подняться выше, в начале почти всегда оказывается обновление состояния в каком-то компоненте. Родитель перерендерился, потому что изменилось его состояние или состояние кого-то выше. Контекст изменился, потому что изменилось состояние компонента, который передаёт значение в провайдер. Исключения есть:

• самый первый рендер;

• внешний стор в useSyncExternalStore;

• данные, которых компонент ждал в Suspense;

• forceUpdate у классового компонента;

• в режиме разработки StrictMode, который вызывает компоненты дважды, и Fast Refresh.

Их оставим в стороне — дальше достаточно проследить путь одного обновления состояния.

Путь такой. Срабатывает сеттер из useState или dispatch из useReducer - разницы нет: внутри React useState сделан через useReducer, поэтому сеттер — это тот же dispatch, и путь у обновления один и тот же.

1. Запрос. Сеттер ничего не меняет на экране сразу — он только создаёт запрос на обновление (дальше для краткости — просто обновление). Обновление встаёт в очередь обновлений своего хука. У каждого функционального компонента есть список хуков (связный список; у классов устроено иначе), а у каждого хука — своя такая очередь: тоже связный список, но кольцевой и с указателем на хвост. Ещё обновление получает приоритет — он зависит от того, откуда вызван сеттер: из обработчика клика, из startTransition, из таймера. В коде React приоритет называется lane. Но в очереди приоритет роли не играет: новое обновление всегда встаёт в хвост. Очередь — общий объект для пары узлов в current и WIP-дереве, поэтому обновление не потеряется, даже если WIP-дерево выбросят (такое бывает — об этом ниже).

2. Планирование. Приоритет есть не только у обновления, но и у каждого узла дерева. У узла два таких поля: lanes - приоритеты обновлений, которые ждут в самом компоненте, и childLanes - приоритеты обновлений, которые ждут в его дочерних компонентах на любой глубине. React записывает приоритет обновления в lanes компонента, а потом поднимается по родительским компонентам до корня и добавляет этот приоритет в childLanes каждого. Вызывать компоненты — то есть рендерить — React при этом сразу не начинает. React ждёт, пока закончится текущий код — например, весь обработчик клика, — чтобы все обновления из него попали в один рендер. И только потом решает, что делать: самое срочное (клик, ввод с клавиатуры) рендерит тут же, а остальное отдаёт планировщику — отдельному пакету React, который решает, когда эту работу выполнить.

3. Рендер. За один рендер React берёт не все ожидающие обновления, а только самые срочные из них — остальные подождут следующего рендера. React обходит дерево от корня. По childLanes он видит, в каких ветках ждут обновления с этим приоритетом, и спускается только туда, а остальные пропускает. По lanes находит сами компоненты с такими обновлениями. Их и их дочерние компоненты React вызывает заново. Новый результат сравнивается с тем, что лежит в current, и собирается в WIP-дерево. Экран всё это время не меняется.

4. Коммит. Изменения из готового WIP-дерева применяются к DOM за один раз, без пауз, и WIP-дерево становится current. Поэтому пользователь никогда не видит интерфейс наполовину обновлённым. Дальше браузер рисует страницу.

Теперь, что такое конкурентный рендеринг. Без него React обрабатывает обновления по очереди: взял пачку (несколько обновлений подряд он объединяет в одну), довёл до экрана, взял следующую. Пока идёт тяжёлое обновление, всё остальное ждёт, и интерфейс “замерзает”. Тяжёлое обновление блокирует поток — а в нём же браузер обрабатывает ввод и рисует страницу. Поэтому, пока обновление не закончится, ни нажатие клавиши, ни перерисовка не произойдут.

В конкурентном рендеринге у обновлений появляется приоритет. Срочное — например, ввод с клавиатуры — может обогнать несрочное, даже если то уже наполовину посчитано: React выбрасывает недоделанное WIP-дерево и сначала рендерит срочное. Выбросить его безопасно — экран во время рендера не меняется. В итоге поле ввода отзывается мгновенно, а тяжёлый список догоняет чуть позже. Вся эта конкурентность — в том, когда React начинает рендер и как его прерывает. Коммит же всегда идёт целиком, без пауз.

2. Пример: поиск по списку

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

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

Это тот же код, что во вступлении, — повторю его здесь, чтобы не бегать туда-сюда.

function Search() {
  const [inputQuery, setInputQuery] = useState("");
  const [listQuery, setListQuery] = useState("");

  const onChange = (e) => {
    const { value } = e.target;
    setInputQuery(value);
    startTransition(() => setListQuery(value));
  };

  return <>
    <input value={inputQuery} onChange={onChange} />
    <List listQuery={listQuery} />
  </>;
}

const List = memo(({ listQuery }) => filterProducts(listQuery).map(
  (p) => <Row key={p.id} item={p} />
));

Оба состояния — просто строки, записать строку ничего не стоит. И найти товары тоже быстро: filterProducts в List - просто поиск текста в названиях товаров, он укладывается в пару миллисекунд. Дорого другое — отрендерить Row на каждый найденный товар, а их тысячи.

Да, в реальном проекте такой список лучше виртуализировать. Но здесь тяжёлый список нужен специально: на нём хорошо видно, как React прерывает рендер.

startTransition - функция из React: обновления, сделанные внутри неё, становятся несрочными. Вот что она меняет для пользователя.

Без startTransition. Пользователь нажал клавишу — и страница перестаёт отвечать, пока не перестроится весь список. Только потом символ появляется в поле. Если быстро напечатать “123”, React построит три списка подряд: для “1”, “12” и “123”.

С startTransition. Символ появляется в поле сразу, а под ним пока остаётся старый список. Если пришёл новый символ, а список ещё строится, недостроенный список выбрасывается. Поэтому, если печатать быстрее, чем строится список, промежуточные списки так и не появятся — React сразу построит список для “123”.

Отсюда и два состояния с одним и тем же текстом. Без startTransition хватило бы одного. А так у них разный приоритет: inputQuery обновляется сразу, listQuery - когда получится.

А memo нужен, чтобы срочный рендер поля ввода не тащил за собой список: без него List рендерился бы заново при каждом рендере Search, даже с тем же listQuery.

Дальше по ходу статьи следим за четырьмя вещами:

• inputQuery - текст в поле ввода;

• listQuery - текст, по которому строится список;

• на экране — то, что сейчас в DOM;

• WIP-дерево — то, что React считает в памяти, но ещё не показал.

3. Как React останавливает рендер

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

• inputQuery: "1";

• listQuery: "", а "1" ждёт несрочного рендера;

• на экране: в поле “1”, под ним все товары, без фильтра;

• WIP-дерево: в поле “1”, под ним товары с “1” в названии — готова половина

JavaScript не умеет приостанавливать функцию: пока она выполняется, браузер не может ни обработать клик, ни нарисовать кадр. Единственный способ отдать управление — закончить функцию, то есть return. Ровно это React и делает.

WIP-дерево React строит по одному компоненту. После каждого он спрашивает планировщика — отдельный пакет React, который решает, когда работать, — “не пора ли уступить?”. На одну порцию работы планировщик даёт 5 мс — это просто константа в его коде (frameYieldMs = 5). При 60 кадрах в секунду кадр длится около 16 мс, так что браузеру остаётся время обработать ввод и перерисовать страницу. На 120-герцовом мониторе кадр — около 8 мс, а порция всё те же 5 мс: частоту экрана планировщик не учитывает.

Компоненты React обрабатывает в цикле: взял компонент, обработал, спросил планировщика, взял следующий. Если планировщик ответил “пора уступить”, React просто не берёт следующий компонент — цикл заканчивается, и функция, которая рендерит всё дерево, выходит через return, хотя React прошёл только часть дерева.

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

А откуда React знает, с какого компонента продолжить, если стек исчез? Позиция в дереве хранится в обычной переменной workInProgress снаружи — она переживает паузу.

Такой подход называют кооперативной многозадачностью: код никто не прерывает силой, он сам регулярно уступает управление. В React его ещё называют time slicing — нарезкой работы на порции по времени.

Вывод для практики. React уступает браузеру только между компонентами. Поэтому важно, в чём именно тяжесть.

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

А если один компонент сам по себе считает 200 мс — например, сортирует огромный массив прямо в теле, — 5-миллисекундные порции не помогут: этот компонент рендерится целиком. startTransition тоже не спасёт: работа станет несрочной, но когда до неё дойдёт очередь, все 200 мс пройдут одним куском. Такой расчёт надо убирать из рендера:

• Web Worker — отдельный поток в браузере: код в нём выполняется параллельно и не мешает ни React, ни обработке ввода. Считаться быстрее он не станет, но интерфейс не замрёт.

• Нарезать расчёт самому — считать порциями и между ними отдавать управление браузеру, например через setTimeout. По сути, повторить вручную то, что React делает с компонентами.

4. Почему до React 16 так было нельзя

Смотрим на тот же момент, когда React строит дерево в памяти. Почему его вообще можно бросить на полпути?

До React 16 дерево обходилось рекурсией: функция обрабатывает компонент и вызывает себя для каждого дочернего компонента. Этот механизм так и называют — stack reconciler. Где ты сейчас в дереве, знал только стек вызовов. А стек не отложишь: вышел из функции — позиция потеряна. Поэтому всё дерево обходилось целиком, без остановок.

В React 16 обход переписали. У каждого компонента появился объект — fiber, с тремя ссылками: на первый дочерний компонент (child), на следующий соседний (sibling) и на родительский (return). Дерево стало связным списком, по которому идут обычным циклом: есть дочерний — вниз, нет — к соседнему, нет соседнего — вверх к родительскому и дальше к его соседнему. Чтобы помнить позицию, хватает одной переменной — той самой workInProgress.

Вывод для практики. Представьте: React успел вызвать половину Row для “1”, и тут пользователь напечатал “2”. Недоделанное WIP-дерево React выбрасывает и строит заново — уже для “12”. Получается, многие Row вызваны дважды, а результат первого вызова на экран так и не попал. Поэтому в теле компонента не должно быть действий, которые влияют на что-то снаружи. Например, если отправлять запрос прямо в теле компонента, запросов уйдёт столько, сколько раз React его вызвал, — в том числе для выброшенных рендеров. То же с подписками и с изменением внешних переменных.

Такому коду место в эффектах или в обработчиках событий. Эффекты запускаются только после коммита — то есть только для того, что React действительно применил к DOM. А обработчики срабатывают на действие пользователя, а не на рендер.

5. Кто решает, что срочно — и что вообще прерывается

Смотрим на момент между вызовом сеттера и рендером: компоненты React ещё не вызывает, а решает, когда это делать.

Каждое обновление получает приоритет по тому, откуда пришло. В нашем onChange:

• setInputQuery вызван прямо в обработчике ввода — срочный;

• setListQuery вызван там же, но внутри startTransition - несрочный.

Главное, что легко упустить: по 5 мс React режет только несрочные рендеры.

• Целиком, без пауз: клик, ввод с клавиатуры, скролл, движение мыши, обычный setState после fetch или по таймеру.

• Порциями по ~5 мс, с паузами: startTransition, useDeferredValue, повторы Suspense.

Приоритеты внутри первой группы разные: клик срочнее скролла, а скролл срочнее setState после fetch. От этого зависит, как скоро рендер начнётся. Но начавшись, он идёт без пауз.

Кто сравнивает приоритеты? setState не рендерит сразу. Он ставит микротаску через queueMicrotask - в обычную очередь микротасок. Она выполнится, как только закончится текущий код, раньше любых макротасок и отрисовки. Микротаска одна на все setState подряд: оба вызова в нашем onChange разберёт одна и та же микротаска.

В микротаске React берёт самое срочное из ожидающего:

• клик или ввод (наш setInputQuery) - рендерит прямо здесь же, в микротаске, без планировщика;

• всё остальное (в том числе наш setListQuery) - отдаёт планировщику как задачу с приоритетом;

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

Для одного корня — того, что создаёт createRoot, обычно это всё приложение, — React держит у планировщика только одну задачу. Когда приходит более срочное обновление — например, скролл посреди недостроенного списка, — React в микротаске сам отменяет старую задачу и ставит новую, с другим приоритетом.

Вывод для практики. Обычный setState с большим ответом сервера рендерится одним куском и может подвесить ввод. Если рендер после загрузки тяжёлый — оберните обновление в startTransition: работы меньше не станет, но её можно будет прервать. Ну, и, опять же, можно уменьшить саму работу: виртуализировать список или загружать данные порциями.

6. Что происходит с недоделанным WIP-деревом

Смотрим на момент, когда список для “1” посчитан в памяти наполовину — и тут пользователь печатает “2”.

• inputQuery: "1" → "12";

• listQuery: "", а "1" и "12" ждут несрочного рендера;

• на экране: в поле “1”, под ним все товары, без фильтра;

• WIP-дерево: в поле “1”, под ним товары с “1” в названии — готова половина

Срочный setInputQuery("12") рендерится в микротаске. Но WIP-дерево посчитано для несрочного приоритета, и в нём уже применён listQuery = "1". Доделать его — значит заставить ввод ждать список. Вырезать из него listQuery - нельзя, он уже разошёлся по половине дерева.

Поэтому React сравнивает: WIP-дерево посчитано не для того приоритета, что нужен сейчас? Тогда оно не нужно — выбрасываем. Новое WIP-дерево строится с нуля — от current, дерева, которое соответствует тому, что на экране. Срочный рендер идёт без пауз до конца, коммит — и поле показывает “12”.

Сразу после этого React запускает несрочную работу заново, тоже с нуля. И тут бонус: все ожидающие transition-обновления React рендерит одной пачкой. В очереди listQuery лежат и “1”, и “12” — значит, считается сразу список для “12”. Список для “1” не появится на экране вообще.

• inputQuery: "12";

• listQuery: "12";

• на экране: в поле “12”, под ним товары с “12” в названии;

• WIP-дерево: нет

Выбрасывать WIP-дерево безопасно: пока идёт рендер, экран не меняется, а в DOM попадает только законченный результат.

Вывод для практики. Промежуточные значения несрочного состояния могут так и не попасть на экран. Не стройте логику на том, что каждое значение listQuery будет отрисовано, — например, аналитику “пользователь увидел результаты для X” в эффекте на listQuery.

7. Как обновления не путаются в порядке

Смотрим на путь от сеттера до рендера: как обновления встают в очередь хука и в каком порядке рендер их применяет.

Добавим на страницу кнопку “Очистить”. Она сбрасывает оба состояния, и оба — срочно, без startTransition:

<button onClick={() => { setInputQuery(""); setListQuery(""); }}>
  Очистить
</button>

Пользователь напечатал “1”, и список для “1” уже на экране. Потом он допечатал “2”, и setListQuery("12") ждёт своего несрочного рендера. Не дождавшись, пользователь жмёт “Очистить”.

В очереди хука listQuery теперь два обновления:

Срочный рендер. React просматривает всю очередь по порядку и у каждого обновления проверяет приоритет. Несрочный setListQuery("12") по приоритету не подходит — перепрыгиваем. Срочный setListQuery("") берем в работу. На экране: пустое поле и полный список. Правильно.

Несрочный рендер. Теперь подходит и setListQuery("12"). После срочного рендера listQuery уже "". Если бы React просто применил setListQuery("12") поверх этого, listQuery стал бы "12": setListQuery("12") не смотрит на прежнее значение, а просто заменяет его. И список внезапно отфильтровался бы по тексту, который пользователь уже стёр. Баг.

Чтобы такого не было, у хука, кроме текущего значения состояния, есть ещё два поля:

• memoizedState - текущее значение состояния, его и видит компонент;

• baseState - база: значение состояния, с которого следующий рендер начнёт применять обновления;

• baseQueue - все обновления, начиная с первого пропущенного, в том порядке, в каком вызывались сеттеры: и пропущенные, и уже применённые. Следующий рендер применит их к базе по порядку.

Проследим, как менялись эти поля с самого начала у хука listQuery - того useState, в котором хранится текст для списка.

Начало. Поле пустое, на экране полный список:

• memoizedState: "";

• baseState: "";

• baseQueue: пусто

Напечатана “1”. Сам сеттер эти поля не меняет — он только ставит обновление в очередь. Поля пересчитываются, когда React вызывает компонент и хук разбирает свою очередь. Первым это делает срочный рендер от setInputQuery("1"): оба состояния, inputQuery и listQuery, объявлены в одном компоненте — Search, и React вызывает его целиком. Хук listQuery находит в очереди несрочное обновление setListQuery("1") и пропускает его. На первом пропуске React фиксирует базу — значение до пропуска, "", - и откладывает это обновление в baseQueue. С этого момента baseState не следует за memoizedState, пока пропущенное не применят:

• memoizedState: "";

• baseState: "";

• baseQueue: setListQuery("1") (несрочное)

Несрочный рендер для “1”. React начинает с базы "" и применяет setListQuery("1"). Пропусков нет, поэтому baseQueue очищается, а в baseState React записывает то же, что в memoizedState. Список для “1” на экране:

• memoizedState: "1";

• baseState: "1";

• baseQueue: пусто

Напечатана “2”. Всё как с “1”: срочный рендер поля пропускает несрочное обновление setListQuery("12"), база фиксируется на "1", а само обновление уходит в baseQueue:

• memoizedState: "1";

• baseState: "1";

• baseQueue: setListQuery("12") (несрочное)

Нажата “Очистить”. Кнопка вызывает setListQuery("") без startTransition - это срочное обновление. Срочный рендер снова перепрыгивает через setListQuery("12"), а setListQuery("") применяет. Но setListQuery("") идёт в очереди после пропущенного setListQuery("12"), поэтому тоже попадает в baseQueue - хоть и уже применён.

В этом и смысл правила: baseQueue хранит обновления в исходном порядке вызовов, независимо от приоритета. Несрочный рендер прогонит их от базы по порядку — так, как если бы приоритетов не было вовсе. Только применённому setListQuery("") React в baseQueue ставит приоритет 0 (NoLane). Нулевой приоритет React считает подходящим для любого рендера, так что такое обновление больше никогда не пропустят. В исходниках так и написано: “это обновление будет показано, мы не хотим его откатывать” (This update is going to be committed so we never want uncommit it).

Поля после клика:

• memoizedState: "";

• baseState: "1";

• baseQueue: setListQuery("12") (несрочное), setListQuery("") (приоритет 0)

После несрочного рендера. React начинает не с memoizedState, а с базы и прогоняет baseQueue по порядку: "1" → "12" → "". Итог — "", как будто всё шло по порядку с самого начала.

• memoizedState: "";

• baseState: "";

• baseQueue: пусто

В коде React это называют rebasing — как в git: отложенные изменения заново накатываются на базу.

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

8. Приоритеты — это биты

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

Приоритет в React — не число 1, 2, 3, а бит в 31-битном числе. Такие биты называются lanes (“полосы”). Чем младше бит, тем срочнее: клик и ввод, непрерывные события вроде скролла, обычные обновления, 14 бит под transition, биты под Suspense и фоновую работу.

Набор приоритетов — одно число, поэтому всё считается одной операцией:

• входит ли обновление в рендер: (set & lane) === lane;

• объединить наборы:a | b;

• самый срочный: lanes & -lanes, младший бит.

Отсюда и то, что нулевой приоритет подходит любому рендеру: (set & 0) === 0 верно при любом set.

Группы и ротация. Для transition в React не один бит, а целая группа: 10 бит под startTransition и ещё 4 под useDeferredValue. Так же устроены повторы Suspense — тоже 4 бита. Когда React выбирает, что рендерить, он берёт сразу все ожидающие биты группы — поэтому все transition-обновления и рендерятся одной пачкой.

Зачем тогда несколько бит, а не один? Чтобы различать transition между собой. Например, если один из них ждёт данных в Suspense, React помечает его бит как приостановленный и рендерит остальные, не дожидаясь его.

Биты в группе раздаются по кругу. Каждое новое событие со startTransition получает следующий бит, а после последнего React возвращается к первому. Внутри одного события бит один: два startTransition в одном обработчике попадут в один бит. А если по кругу выпал бит, который ещё занят старым transition, новый просто разделит его со старым — и рендериться они будут вместе.

Биты помогают и не обходить всё дерево. Когда меняется компонент, React поднимается от него к корню и ставит каждому предку бит “внизу есть работа” (childLanes). При рендере ветку без нужного бита React пропускает целиком, не заходя внутрь.

Почему 31, а не 32. Старший, 32-й бит в JavaScript означает минус, и React его просто не занимает: любой набор приоритетов — положительное число. Объяснения этому в исходниках я не нашёл — видимо, так просто проще, чем следить за знаком.

Итог

• Как остановить рендер? React рендерит по одному компоненту и после каждого спрашивает планировщика, не пора ли уступить. Если пора — выходит через return и оставляет планировщику колбек, чтобы потом продолжить. Планировщик отправляет сам себе сообщение и тоже выходит — стек пустеет. Сообщение приходит отдельной задачей (макротаской), а между задачами браузер успевает обработать ввод и нарисовать кадр. Только потом планировщик вызывает колбек.

• Почему только с React 16? Раньше React обходил дерево рекурсией, и где он сейчас в дереве, помнил только стек вызовов: выйти посередине значило потерять место. В React 16 у каждого компонента появился объект-узел — fiber — со ссылками на первый дочерний компонент, соседний и родительский. По таким ссылкам дерево обходится обычным циклом, а текущий узел хранится в одной переменной. Её можно оставить как есть, выйти и потом продолжить с того же места.

• Что прерывается? Только несрочные рендеры: обновления из startTransition, useDeferredValue и повторы Suspense. Рендер после клика, ввода или обычного setState идёт целиком, без пауз.

• Что с недоделанным WIP-деревом? Выбрасывается; несрочное считается заново, все transition — одной пачкой.

• Как не путается порядок? База + отложенная очередь: несрочный рендер переигрывает обновления по порядку вызова.

• Что такое приоритет? Бит в 31-битной маске (lane).

Что это значит для вашего кода:

• Если после обновления тяжёлый рендер, оберните это обновление в startTransition. Иначе React отрендерит всё одним куском, и ввод будет ждать.

• Если тяжёлый расчёт сидит в одном компоненте, нарезка по 5 мс не поможет. Выносите такой расчёт из рендера — например, в Web Worker.

• Не делайте в теле компонента запросов, подписок и изменений внешних переменных. React может вызвать компонент и выбросить результат, а эти действия всё равно произойдут.

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

За кадром осталось немало. Что будет, если несрочный рендер прерывают снова и снова, — список так и не дойдёт до экрана? Как useDeferredValue показывает старое значение, пока считается новое? И как transition держит на экране старый интерфейс, пока Suspense ждёт данных? Об этом — в следующий раз.

Если что-то осталось непонятным или хочется копнуть какую-то часть глубже — пишите в комментариях.