Bailout, мемоизация и tearing

Bailout: как React пропускает работу. Не каждый компонент в перерендеривающемся поддереве действительно перезапускается. Когда React достигает fiber во время render, он проверяет: изменились ли props (через Object.is на каждом prop)? Изменилось ли state? Есть ли pending-обновление контекста, которое потребляет этот fiber? Если ничего из этого не верно, React делает bailout — клонирует fiber из alternate, переиспользует всё существующее дочернее поддерево по ссылке и вообще не вызывает функцию компонента.

Именно поэтому ссылочная стабильность так важна: дочерний компонент, обёрнутый в React.memo, делает bailout только если его props ссылочно равны. Передайте инлайновый {} или стрелочную функцию как prop — и bailout не будет работать при каждом рендере, потому что свежий литерал никогда не равен предыдущему через Object.is. useMemo и useCallback существуют именно для сохранения этих ссылок, чтобы bailout мог сработать.

Ментальная модель: рендеринг родителя не автоматически перерендеривает дочерние компоненты — он предлагает им шанс сделать bailout, а стабильные ссылки — это то, что позволяет им этим шансом воспользоваться.

State хранится на fiber, а не в компоненте. Это факт, который объясняет одновременно и то, почему state переживает рендеры, и то, почему Правила Хуков непреложны. Функциональный компонент не имеет экземпляра — это просто функция, которую React вызывает. Так где же useState хранит значение между рендерами? На fiber. Каждый fiber держит связный список записей хуков — по одной на каждый вызов useState/useReducer/useEffect, в порядке вызова. React продвигает cursor через этот список, пока ваш компонент вызывает хуки.

Вот глубинная причина Правил Хуков: хуки должны вызываться безусловно и в одном и том же порядке при каждом рендере, потому что React идентифицирует каждый хук исключительно по его позиции в последовательности вызовов, а не по имени. Поместите useState под if — и при рендере, где условие переключилось, каждый последующий хук читает неправильную запись. Это также объясняет сохранение состояния: state переживает рендер, потому что fiber переживает; state уничтожается при уничтожении fiber — при размонтировании, при смене типа или при смене ключа.

Tearing и useSyncExternalStore. Прерываемый рендеринг вводит опасность под названием tearing (разрывность — когда разные компоненты видят несогласованные значения одного store): если внешний store меняется между двумя слайсами, компоненты первого слайса видели старое значение, а компоненты позднего слайса — новое, поэтому закоммиченный UI внутренне несогласован — «разорван». Собственное состояние React не может рваться, потому что React контролирует, когда оно меняется; внешние stores могут, потому что React этим не управляет.

useSyncExternalStore исправляет это: он даёт React функцию subscribe и функцию getSnapshot. React читает снимок, и если обнаруживает, что снимок изменился во время конкурентного рендера, перезапускает рендер, гарантируя, что каждый компонент в одном commit наблюдал одно и то же значение store. Именно поэтому любая библиотека состояния, интегрирующаяся с React 18 (Redux, Zustand, Jotai), маршрутизирует через useSyncExternalStore.

Контекст и каскад перерендеривания. Provider контекста рядом с корнем дерева, чьё значение — свежий объектный литерал при каждом рендере, вызывает перерендеривание всего поддерева потребителей. Потребители контекста перерендериваются при каждом изменении значения провайдера по ссылке — а свежий литерал всегда отличается. Исправление: мемоизировать значение контекста через useMemo, чтобы его ссылка была стабильной, когда содержимое не меняется. Это наиболее частая причина перформанс-проблем в реальных React-приложениях, обнаруживаемая Profiler-ом как массовый перерендеринг несвязанных компонентов.