React Server Components: граница, payload и что через них проходит

Компоненты, которые никогда не отгружаются

Зачем это вообще нужно? Каждый KB, который браузер скачивает, нужно распарсить и исполнить, прежде чем страница станет интерактивной, — а большая часть типичной Next.js кодовой базы — это логика рендеринга, которой в браузере делать нечего. RSC позволяет провести эту границу явно и не платить ничего за её существование.

React Server Component (RSC, серверный компонент React) — это компонент, который исполняется только на сервере — при сборке или на запрос — и чей код никогда не попадает в клиентский бандл. Вторая часть фразы — весь экономический аргумент. Классический SSR-компонент рендерится на сервере и ещё раз на клиенте при гидратации, поэтому его код отгружается в браузер; RSC рендерится один раз, на сервере, и браузер получает только его результат. Поэтому компонент может делать то, что браузерному коду не позволено никогда: ходить в базу напрямую, читать файловую систему, использовать тяжёлый markdown-рендерер или подсветку синтаксиса, держать API-секреты — ничто из этого не покидает сервер.

// app/orders/page.tsx — Server Component (по умолчанию в app/)
import { db } from "~/lib/db";          // server-only: никогда не попадает в клиентский бандл
import { formatMoney } from "~/lib/money";

export default async function OrdersPage() {
  // Загрузка данных рядом с компонентом, которому они нужны.
  // Ни useEffect, ни танцев с loading-стейтом, ни API-роута посередине.
  const orders = await db.order.findMany({ take: 50, orderBy: { createdAt: "desc" } });

  return (
    <table>
      <tbody>
        {orders.map((o) => (
          <tr key={o.id}>
            <td>{o.customerEmail}</td>
            <td>{formatMoney(o.totalCents)}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

Обратите внимание, чего здесь нет: ни useEffect + fetch + спиннера, ни API-эндпоинта, построенного только чтобы возить данные в браузер. Компонент — async, он сам await-ит свои данные, и слой данных живёт рядом с разметкой, которая их потребляет. Это убивает классический водопад клиентской загрузки, где браузер качает JS, исполняет его, потом обнаруживает, что нужны данные, потом делает ещё один круг по сети — на сервере компонент и база часто в одном датацентре, и этот круг стоит ~1 мс вместо ~100 мс.

Что клиент получает на самом деле — это RSC payload: компактное сериализованное описание отрендеренного дерева — результат серверных компонентов плюс плейсхолдеры («здесь отрендери клиентский компонент из чанка X, вот его props») везде, где встречается клиентский компонент. React на клиенте строит из payload дерево, не исполняя серверный код. Это же делает возможной мягкую навигацию: клик по ссылке запрашивает RSC payload нового маршрута, и React вливает его в существующее дерево — клиентские компоненты в постоянном layout сохраняют состояние (полунабранный поиск переживает переход), потому что payload — это описание для реконсиляции, а не HTML-страница на замену.

”use client” — граница, а не метка

Самое частое senior-заблуждение про RSC: читать "use client" как «этот компонент — клиентский». На деле директива объявляет границу в графе зависимостей модулей: этот файл и всё достижимое через его импорты принадлежит клиентскому бандлу. Вы не аннотируете каждый интерактивный компонент — вы помечаете точки входа, где серверное дерево передаёт управление клиентской территории, и бандлер обходит граф импортов оттуда. Именно поэтому однострочный «фикс» из Hook утащил 180KB: пометить файл layout — значит пометить всё его поддерево импортов.

Отсюда два следствия. Первое — практический паттерн: двигайте клиентские границы к листьям. Держите layout, страницы и компоненты с тяжёлыми данными серверными, а интерактивные острова вырезайте минимальными — <AddToCartButton>, а не <ProductPage>. Второе: клиентский компонент не может импортировать серверный (импорт затащил бы серверный код в клиентский граф — сборка либо обработает его как клиентский компонент, либо упадёт на server-only API). Но клиентский компонент может получить серверно отрендеренный контент как children или любой другой prop: сервер рендерит внутреннее дерево, а клиентский компонент вставляет готовый результат на место. Переплетение достигается композицией, а не импортом.

// theme-provider.tsx
"use client";
export function ThemeProvider({ children }: { children: React.ReactNode }) {
  const [theme, setTheme] = useState<"light" | "dark">("light");
  return <ThemeCtx.Provider value={{ theme, setTheme }}>{children}</ThemeCtx.Provider>;
}

// app/layout.tsx — Server Component
export default function RootLayout() {
  return (
    <ThemeProvider>
      {/* По-прежнему рендерится на сервере, ноль клиентского JS —
          проходит СКВОЗЬ клиентский компонент как children, а не импортируется им. */}
      <HeavyServerSidebar />
    </ThemeProvider>
  );
}

Что проходит через границу: только сериализуемое

Прежде чем передать prop через границу "use client", спросите себя: переживёт ли это значение сериализацию в JSON, передачу по сети и оживление в совершенно другом процессе? Если нет — prop не пройдёт.

Props, текущие из серверного компонента в клиентский, пересекают настоящую границу процессов и времени — на сервере они сериализуются в RSC payload, в браузере оживают. Поэтому они обязаны быть сериализуемыми RSC-сериализатором React: JSON-примитивы, простые объекты и массивы, Date, Map/Set, FormData, типизированные массивы, JSX и промисы (которые достримливаются по мере разрешения). Что пройти не может: функции (замыкание onClick захватило серверный скоуп — оживить его в браузере невозможно), экземпляры классов (объект модели Prisma бросит ошибку или молча потеряет прототип) и всё, что несёт живые ресурсы — сокеты, хендлы базы. Поэтому «Functions cannot be passed directly to Client Component props» — ошибка границы, а не синтаксиса. И поэтому два легитимных обходных пути устроены именно так: передавайте вниз данные и пусть обработчик живёт в клиентском компоненте — либо передавайте Server Action (функцию с "use server"), сериализуемую ровно потому, что по проводу идёт ссылка — идентификатор, который клиент вызовет сетевым запросом, — а не само замыкание.

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