Глава 9 Серверные компоненты React

Будущее серверных компонентов React

Книга

Fluent React: Build Fast, Performant, and Intuitive Web Applications

Глубокое погружение во внутреннее устройство React: JSX и продвинутые паттерны, виртуальный DOM и реконциляция, серверный рендеринг, конкурентный режим и серверные компоненты.

Автор

Спикер

Глава 9 · Откуда растут RSC

Два родителя: MPA и SPA

Прежде чем говорить о будущем — вспомним, из чего RSC собраны. Веб десятилетиями качался между двумя крайностями, и у каждой были веские причины существовать.

MPA — multi-page application

«Многостраничник» эпохи PHP и Rails: каждый клик — запрос на сервер, в ответ — новая HTML-страница. Сильные стороны: быстрый первый экран, SEO из коробки, работает без JavaScript, данные всегда свежие с сервера. Слабость: любое действие — перезагрузка всей страницы, состояние (скролл, черновик, музыка) теряется.

SPA — single-page application

«Одностраничник» эпохи React: HTML приходит один раз, дальше всё рисует JavaScript в браузере. Сильные стороны: мгновенные переходы без перезагрузки, богатая интерактивность, состояние живёт между экранами. Слабость: весь код приложения едет клиенту — первый экран ждёт бандла, слабые устройства и SEO страдают, данные ходят через отдельный API.

Оба паттерна честно решали задачи своего времени — просто оптимизировали разное: MPA — доставку контента, SPA — интерактивность. RSC — попытка не выбирать: HTML и данные с сервера как в MPA, мягкая навигация и живой интерактив как в SPA.

Глава 9 · Где мы оказались

RSC: лучшее от MPA и SPA в одной архитектуре

Мы прошли всю главу: преимущества, рендеринг, правила, server actions. Итог — архитектура, которая сочетает многостраничные приложения с серверным рендерингом и удобство одностраничных, не жертвуя ни производительностью, ни сопровождаемостью.

Предсказуемая производительность

Компоненты выполняются на наших серверах, мощность которых мы контролируем, — а не на незнакомых устройствах пользователей. И это не «лёгкая разметка»: markdown, подсветка синтаксиса, запросы к БД — тяжёлая работа и её зависимости остаются на сервере, клиенту едет готовый результат. Неинтерактивный ≠ обезличенный: RSC рендерятся на каждый запрос и могут читать куки и сессию.

Безопасность по умолчанию

Секреты у бэкенда были всегда — разница в том, кто охраняет границу. В SPA + API её держит дисциплина: не заимпортить случайно серверное во фронт. Здесь секреты и запросы к БД живут в одном дереве с UI, но границу проверяет компилятор: серверный код физически не попадает в бандл.

Меньше JavaScript у клиента

Серверные компоненты исключаются из клиентского пакета и могут быть асинхронными — данные ждём на сервере, а не в браузере.

2023 · Что обещала книга

Планы на момент написания книги

Книга зафиксировала момент: RSC — «горячая» тема, реализация сырая, React 19 ещё не вышел, прод-путь фактически один — Next.js. Команда React обещала два фронта работы:

Лучшая интеграция с упаковщиками

Сотрудничество с разработчиками Webpack, Rollup и других инструментов. RSC требуют упаковщика «нового поколения» — умеющего строить раздельные графы модулей для сервера и клиента. Чем лучше поддержка, тем проще создавать RSC-совместимые платформы и приложения.

Поддержка экосистемы

Вокруг новой архитектуры будут появляться инструменты, библиотеки и фреймворки — внедрять RSC в проекты станет проще, а выгоду от производительности получит больше команд.

И большой прогноз: меньше JavaScript у клиента, упрощённое получение данных, лучший UX — а по мере распространения RSC «станут важным инструментом». Мы в августе 2026-го — можем выставить оценки.

Август 2026 · Сверяем часы

Что сбылось, а что разочаровало

Обещание книги	Август 2026
Упаковщики нового поколения	Сбылось: Turbopack стабилен в Next.js, официальный @vitejs/plugin-rsc, поддержка в Parcel — RSC больше не привязаны к одному инструменту
Поддержка экосистемы	Сбылось с оговоркой: App Router впервые обогнал Pages Router (State of JS 2025); React Router и Remix v3 везут RSC, есть Waku и TanStack — но «полный прод» всё ещё в первую очередь Next.js
Меньше JavaScript у клиента	Подтверждено практикой: команды отчитываются о сокращении бандла на 40–60 % (условные 400–600 КБ → 150–250 КБ)
«Станут важным инструментом»	Сбылось: React 19 (конец 2024) внёс RSC и server actions в стабильное ядро; RSC — рекомендуемый способ строить новые React-приложения

Что разочаровало: ментальная сложность «двух миров» так и осталась главной жалобой; часть экосистемы (CSS-in-JS, context-зависимые библиотеки) не переехала; несколько лет RSC ≈ Next.js. Новые фронты: React Compiler (автомемоизация), «use cache» и Partial Prerendering в Next.js, стабилизация RSC в React Router и Vite.

Рекап перед обсуждением

Вся глава — в пяти строках

Этот доклад закрывает главу 9 — дальше вопросы из книги по всем её темам. Освежим четыре прошлых доклада одним слайдом.

RSC — новый тип компонентов: выполняются на сервере, исключены из клиентского пакета, могут запускаться во время сборки и быть асинхронными.
Два взаимодополняющих процесса: RSC-рендеринг превращает компоненты в дерево элементов, серверный рендеринг — дерево в HTML.
Правила простые: сериализуемые пропсы, никаких хуков состояния и эффектов, импорт серверного из клиентского запрещён — но композиция через children разрешена.
Server actions («use server») замыкают круг: мутации с клиента без ручных endpoint'ов, формы работают до загрузки JS.
Это не замена клиентским компонентам, а дополнение: интерактивные части остаются на клиенте.

Проверьте ваши знания

Пять вопросов для обсуждения

Вопросы из книги. Сначала обсуждаем — потом клик по вопросу раскрывает тезисный ответ.

Что является главной ценностью серверных компонентов React?

Код компонента не едет клиенту: тяжёлая работа и её зависимости выполняются на сервере, в бандле остаётся только интерактив. Плюс прямой доступ к данным и секретам — без отдельного API-слоя.

Могут ли клиентские компоненты импортировать серверные? Почему?

Импортировать — нет: компоновщик смотрит на import, и серверный код (вплоть до node:fs) уехал бы в клиентский пакет. Но принять готовый серверный компонент через children/пропсы — можно: в пакет при этом ничего не добавляется.

Каковы компромиссы между серверными компонентами и традиционным клиентским подходом?

Выигрыш: меньше JS, быстрее первый экран, данные и секреты на сервере. Плата: два типа компонентов и граница между ними (интеллектуальные затраты), обязательный сервер или сборка, упаковщик нового поколения; интерактив всё равно требует клиентских компонентов.

Что такое ссылки на модули и как React обрабатывает их во время согласования?

Вместо клиентского компонента сервер кладёт в дерево заполнитель — объект с $$typeof: react.module.reference и ID модуля. При согласовании React на клиенте подменяет ссылку реальным модулем из клиентского пакета и рендерит его — так «дыры» в серверном дереве заполняются интерактивом.

Как server actions делают приложения React более доступными?

Форма с action работает до загрузки JavaScript: до гидратации сабмит уходит нативным браузерным POST (прогрессивное улучшение). Слабые сети, слабые устройства, отключённый JS — критичные сценарии вроде логина остаются рабочими.

Что далее

Преимущества Пройдено

Антон Помазков

Серверный рендеринг Пройдено

Антон Помазков

Правила работы серверных компонентов Пройдено

Артём Никифоров

Серверные действия Пройдено

Артём Никифоров

Будущее серверных компонентов React Пройдено

Артём Никифоров