Suspense для данных: контракт «брось promise», use() и границы как UX-дизайн

Контракт: подвеситься броском, продолжиться повтором

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

Механически Suspense — протокол исключений. Когда компонент не может отрендериться, потому что данные не готовы, он бросает thenable (promise-подобный объект). React ловит его, раскручивая рендер — помните, рендер чист и выбрасываем, так что отказ от попытки бесплатен, — поднимается до ближайшей границы <Suspense> и коммитит её fallback вместо поддерева. Затем React подписывается на брошенный promise; когда тот резолвится, React повторяет рендер поддерева с нуля. На повторе компонент выполняется снова, у источника данных уже есть значение, чтение возвращается синхронно, и настоящий UI коммитится. В самом компоненте нет ветки загрузки — «не готово» не состояние, которое он моделирует, а исключение, которое он бросает.

use() — санкционированный примитив чтения: const user = use(userPromise) возвращает значение, если promise зарезолвлен, бросает promise для подвешивания, если pending, и бросает причину отклонения, если rejected. В отличие от хуков, use можно вызывать в условиях и циклах — это чтение, а не регистрация состояния. Сам promise должен быть создан в другом месте (родителем, лоадером роутера, кешем) и передан вниз или найден по ключу; работа компонента — только читать.

const cache = new Map();
function fetchUser(id) {              // идентичность: тот же id → тот же promise
  if (!cache.has(id)) {
    cache.set(id, fetch(`/api/users/${id}`).then((r) => {
      if (!r.ok) throw new Error(`HTTP ${r.status}`);
      return r.json();
    }));
  }
  return cache.get(id);
}

function Profile({ id }) {
  const user = use(fetchUser(id));    // подвешивается, пока pending
  return <h1>{user.name}</h1>;
}

// <ErrorBoundary fallback={<Oops />}>
//   <Suspense fallback={<Skeleton />}>
//     <Profile id={42} />
//   </Suspense>
// </ErrorBoundary>

Почему голый fetch в рендере зацикливается навсегда

Вот ловушка из Хука, механически. Рендер чист и перезапускаем: React может вызвать компонент много раз, и каждое подвешивание выбрасывает попытку целиком. Если тело компонента само создаёт promise — use(fetch(url)), — то повтор после резолва снова выполняет тело и создаёт новенький, pending promise. Тот, что зарезолвился, ушёл вместе с выброшенным рендером; новый подвешивает; React подписывается, тот резолвится, повтор, новый promise, подвешивание. Цикл не сходится, и каждая итерация шлёт настоящий сетевой запрос. Лечение — идентичность: какое-то хранилище вне рендера должно возвращать тот же promise для того же логического запроса, чтобы use() на повторе получил уже зарезолвленный promise и прочитал его синхронно. Это хранилище и есть кеш — Map по параметрам запроса в игрушечной версии, query-библиотека или лоадер фреймворка в продакшене. Это структурная причина, по которой документация React говорит: загрузка данных с Suspense предназначена для фреймворков и кеширующих библиотек, а не для ручной сборки — контракт прост, кеш (инвалидация, вытеснение, дедупликация) и есть настоящий продукт.

Границы — это UX-дизайн, а ошибки — близнец границы

Где вы ставите <Suspense>, там и появляются спиннеры — это дизайнерское решение, выраженное структурой компонентов. Одна граница у корня страницы — всё или ничего: проще всего, но любой медленный виджет гасит всё (второй инцидент из Хука). Граница на каждый виджет — секции проявляются независимо: быстрые сразу, медленные показывают локальные скелетоны — ценой «попкорн-UI», когда контент выскакивает в случайном порядке и дёргает раскладку. Сеньорский паттерн — осознанная группировка: оберните то, что пользователь воспринимает как одно целое (шапка + сводка), в одну границу, чтобы они появились вместе, а длиннохвостым секциям (аналитика, рекомендации) дайте свои. Вложенные границы компонуются: подвешивание ловит ближайшая граница-предок, так что внутренние границы ограничивают внутренние состояния загрузки, а внешняя покрывает первый маунт. Для управления порядком проявления — сверху вниз вместо «кто первый зарезолвился» — экспериментальный SuspenseList координировал несколько границ; пока он не стабилен, тот же эффект даёт структура границ или объединение promise выше по дереву.

Отклонение — зеркальный путь: когда ожидаемый promise отклоняется, повтор бросает причину отклонения во время рендера, и это исключение летит до ближайшего error boundary — не до границы Suspense. Продакшен-дерево поэтому ставит их парой: ErrorBoundary снаружи, Suspense внутри, на каждый регион. Честный трейдофф: fallback заменяет контент. Для обновлений после первой загрузки заменить живые данные спиннером часто хуже, чем показать слегка устаревшие, — для этого существует startTransition: обновления, помеченные как transition, не включают fallback уже раскрытой границы; React держит старый UI, пока новое дерево подвешено в фоне.