Границы Suspense: проектирование того, что исчезает вместе

Граница — дизайн-единица, а не сантехника

Когда компонент приостанавливается — читает неразрешённый promise через use, Suspense-совместимый фреймворковый запрос или React.lazy — React не ставит на паузу один этот компонент. Он идёт вверх по дереву до ближайшего предка <Suspense>, бросает рендер всего, что под этой границей, и показывает её fallback. Отсюда два следствия, и оба про расстановку, а не про данные:

• Всё под выбранной границей исчезает вместе. Соседи приостановившегося компонента, у которых данные уже были — название товара, кнопка покупки — пропадают тоже, потому что живут под той же границей. Гранулярность загрузочного UI — граница, а не компонент.
• Побеждает ближайшая граница. Оберните медленный блок в собственную границу — и скелетон покажет только его слот; оставьте голым — и приостановка уйдёт к любому предку с границей, как бы высоко он ни был, включая корень роута. Так запрос виджета превращается в полностраничный спиннер.

// ❌ одна граница на корне: ЛЮБОЙ приостановившийся компонент гасит всю страницу
<Suspense fallback={<FullPageSpinner />}>
  <ProductHeader />     {/* fast */}
  <BuyBox />            {/* fast */}
  <RecommendationRail /> {/* p99 2.8s — takes everyone down */}
</Suspense>

// ✅ границы повторяют последовательность загрузки из дизайна
<ProductHeader />
<BuyBox />
<Suspense fallback={<RailSkeleton />}>
  <RecommendationRail /> {/* slow — disappears alone */}
</Suspense>

Правильный способ выбирать расстановку — задать вопрос, на который дизайнеры уже отвечают, рисуя скелетоны: какие области этой страницы загружаются как единое целое? Каждый ответ — граница. Граница на каждый компонент так же неверна, как одна на страницу: пятнадцать независимых спиннеров, всплывающих в случайном порядке, читаются как поломка, один гигантский спиннер — как тормоза. Документация react.dev здесь прямолинейна: не оборачивайте границей каждый компонент; последовательность загрузки должна совпадать с тем, что задумал дизайн.

Вложенность, порядок появления и троттлинг

Вложенные границы дают последовательность появления. Внешняя граница резолвится первой и открывает каркас лейаута; внутренние продолжают показывать свои скелетоны, пока не приедут их данные. Порядок строго сверху вниз — внутренняя граница не может открыться раньше родительской: пока родитель не открылся, внутреннего содержимого на экране нет вовсе. Так «сначала навигация, потом статья, потом комментарии» кодируется прямо в дереве.

Есть деталь, которую сениору стоит знать, потому что она всплывает в трейсах профайлера: React троттлит раскрытие вложенных границ. Когда несколько вложенных границ резолвятся подряд, React батчит появления, а не показывает каждое в момент готовности — интервал порядка 300 мс (константа в исходниках React, не настраивается). Мотивация — мерцание: без этого быстрое соединение даёт каскад скелетонов, каждый из которых виден 16 мс, и это читается как глюк. Цена тоже честная: при быстром попадании в кэш контент может появиться чуть позже, чем пришли данные. Если видите зазор ~300 мс между резолвом данных и отрисовкой внутри вложенного Suspense — это не ваш баг, это React меняет сырую латентность на визуальное спокойствие.

Fallback — это лейаут: резервируйте место

Fallback — не украшение: он занимает слот границы в раскладке. Спиннер в 40px на месте карточки в 480px означает два перелайаута страницы: когда отрисовался спиннер и когда его заменил контент. Это Cumulative Layout Shift (CLS — накопленный сдвиг раскладки), и полевой порог беспощаден — CLS выше 0,1 проваливает Core Web Vitals, и одна замена на всю высоту способна сжечь весь бюджет в одиночку. Дисциплина: каждый fallback — скелетон с теми же размерами, что у устоявшегося контента: та же высота, те же aspect-ratio-боксы для изображений, min-height на контейнерах с плавающей высотой. Относитесь к скелетону как к контракту с дизайн-системой, а не как к довеску: команды, генерирующие скелетоны из раскладки настоящего компонента (серые блоки в той же сетке), показывают CLS около нуля; команды с центрированным спиннером — 0,2 и больше.

Уточнение видимого: fallback, которого нужно избегать

Когда граница уже открылась, правила меняются. Если обновление — новый поисковый запрос, смена фильтра — снова приостанавливает уже видимый контент, поведение React по умолчанию жестокое: он прячет закоммиченный контент и опять показывает fallback. Список результатов моргает скелетоном на каждое нажатие. Именно это предотвращает startTransition (и useTransition): когда обновление, вызвавшее приостановку, помечено как transition, React не прячет видимый контент. Он держит старый UI на экране, рендерит новое дерево в фоне и подменяет, когда готово, — а isPending даёт затемнённый список на время ожидания.

const [isPending, startTransition] = useTransition();

function onQueryChange(q) {
  setInput(q);                       // urgent: the input must echo now
  startTransition(() => setQuery(q)); // non-urgent: results may suspend — keep old list
}

Одна честная оговорка: transition защищает только уже показанный контент. Если новое дерево монтирует новенькую границу, которая приостанавливается, эта граница покажет свой fallback в любом случае — в её слоте нет ничего старого, что можно было бы удержать. Так что вопрос расстановки возвращается и здесь: границы, которые вы собираетесь уточнять на месте, должны оборачивать стабильные слоты, а не пересоздаваться на каждый запрос.

Каталог режимов отказа

• Единственная корневая граница — каждый новый медленный компонент где угодно в роуте наследует полностраничный спиннер. Радиус поражения виджета — вся страница. Это инцидент из пролога, и он повторяется, потому что корневая граница «работает» месяцами, пока кто-то не добавит медленный лист.
• Граница на каждый компонент — попкорн-UI: дюжина скелетонов, резолвящихся в произвольном порядке, лейаут дёргается на каждом. Порядок появления должен быть спроектирован, а не эмерджентен.
• Спиннеры-фоллбеки неверных размеров — провалы CLS, видимые в полевых данных (CrUX), но не на быстрой машине разработчика: локально fallback живёт один кадр.
• Уточнение без transition — видимый контент пробивается в скелетон на каждом действии; пользователи читают это как «приложение теряет мои данные».