React Server Components и Suspense streaming

Что такое React Server Components

После этого урока ты поймёшь, почему добавление 'use client' к каждому компоненту уничтожает преимущество RSC — и как провести границу правильно.

React Server Components (RSC) — это React компоненты, которые выполняются исключительно на сервере. Они являются async функциями, которые могут обращаться к базам данных, читать файлы или вызывать любой server-side API. Их вывод — HTML плюс специальное сериализованное React-дерево (RSC Payload) — но никогда не JavaScript, отправляемый в браузер.

Ключевое разделение:

• Server Components — рендерятся на сервере, производят HTML. Без useState, без useEffect, без браузерных API. Ноль KB кода компонента в браузерном bundle.
• Client Components — помечаются 'use client' вверху файла. Запускаются и на сервере (для начального HTML) и на клиенте (для интерактивности). Их код компонента отправляется в браузер.

// ServerCard.tsx — Server Component (директива не нужна)
// Запускается только на сервере. JS в браузер не отправляется.
async function ServerCard({ id }: { id: string }) {
  const data = await db.product.findUnique({ where: { id } });
  return <div>{data.name}</div>;
}

// AddToCart.tsx — Client Component
'use client';
import { useState } from 'react';
export function AddToCart({ productId }: { productId: string }) {
  const [added, setAdded] = useState(false);
  return <button onClick={() => setAdded(true)}>{added ? 'Добавлено' : 'В корзину'}</button>;
}

На типичной странице товара, заголовок, описание и изображение — Server Components: они fetch’ят один раз при запросе, отдают HTML, не отправляют JS. Только интерактивные листья (AddToCart, фильтры, модалки) становятся Client Components.

Как Suspense включает стриминг

React Suspense — примитив для “покажи fallback пока эта часть дерева загружается”. На сервере Suspense boundary позволяет остальному дереву стримиться, пока suspended компонент ещё разрешает своё async обещание.

Lifecycle запроса со стримингом:

1. Запрос приходит на сервер
2. Сервер начинает рендеринг. Шелл лэйаута (nav, заголовок страницы, skeleton-shaped fallbacks) не нуждается в async данных — рендерится мгновенно
3. Чанк HTML шелла отправляется по открытому response stream. TTFB срабатывает здесь (~50–100ms)
4. Сервер запускает async data fetch’и внутри Suspense boundaries, параллельно
5. По мере разрешения каждого fetch’а, сервер рендерит эту секцию и стримит HTML чанк
6. Браузер получает чанки, заменяет Suspense fallbacks на реальный контент
7. LCP срабатывает когда самый большой визуально элемент заcтримился

Вместе эти семь шагов означают, что пользователь видит живой интерактивный шелл уже через 100ms, а не пустой экран. Без шага 3 (ранняя отправка шелла) вся цепочка блокируется на самом медленном fetch’е шага 4.

Польза: без стриминга TTFB был бы равен самому медленному fetch’у (600ms). Со стримингом TTFB равен времени рендеринга шелла (80ms). Пользователь видит контент намного раньше.

Правило границы ‘use client’

Когда подключаешь новый компонент, сопротивляйся рефлексу добавить 'use client' сверху — сначала проверь, нужно ли ему вообще какое-то состояние браузера.

Лучшая архитектура: держать как можно больше дерева как Server Components, переносить 'use client' к листьям, которым реально нужна интерактивность.

// Page.tsx — Server Component (по умолчанию)
async function ProductPage({ id }) {
  const product = await fetchProduct(id);  // server-side, нуль клиентского JS
  return (
    <main>
      <h1>{product.name}</h1>
      <ProductImages urls={product.images} />     {/* Server Component */}
      <Suspense fallback={<ReviewsSkeleton />}>
        <ReviewsSection productId={id} />          {/* Server Component, стримится */}
      </Suspense>
      <AddToCart productId={id} />                 {/* Client Component */}
    </main>
  );
}

Влияние на размер bundle’а реально: Next.js 15 приложение, которое переносит большинство компонентов на server-side, может уменьшить клиентский bundle с 240KB до 60KB.

Ловушка dehydration/rehydration

Распространённый баг при добавлении TanStack Query в RSC приложение: сервер fetch’ит данные, рендерит HTML, отправляет. Клиент hydrates, монтирует те же query хуки и fetch’ит те же данные снова — два round-trip’а для одной загрузки страницы.

Фикс: dehydrate серверный query cache в HTML, rehydrate на клиенте:

// На сервере
const queryClient = new QueryClient();
await queryClient.prefetchQuery({ queryKey: ['product', id], queryFn: () => fetchProduct(id) });
const dehydratedState = dehydrate(queryClient);

// В HTML — передать клиенту
<HydrationBoundary state={dehydratedState}>
  <ProductPage />
</HydrationBoundary>

Теперь useQuery(['product', id]) на клиенте находит данные в кэше мгновенно — без повторного fetch’а.