React Server Components: разбираемся без хайпа

Последние полгода в каждом втором React-проекте мне приходится объяснять Server Components. Не туториал из документации, а именно разбор — когда их брать, а где проще обойтись старыми добрыми SSR или даже CSR. Давайте разберёмся без хайпа.

Что на самом деле делает RSC

Когда коллега спрашивает “как работают Server Components”, первое, что я делаю — рисую на доске три сценария:

1. CSR: браузер получает index.html с пустым <div id="root"> и JS-бандл, который всё рендерит на клиенте
2. SSR: сервер отдаёт готовый HTML, но потом тот же код запускается на клиенте для гидратации
3. RSC: часть компонентов вообще не попадает в клиентский бандл

Ключевое отличие RSC — это не просто “рендер на сервере”, а полное исключение компонента из клиентского кода. Например:

// Этот компонент НЕ попадёт в client bundle
async function ProductDetails({id}) {
  const product = await db.products.find(id); // Прямой доступ к БД!
  return <div>{product.name}</div>; 
}

// А этот — попадёт, потому что 'use client'
'use client';
function AddToCartButton() {
  const [count, setCount] = useState(0); // Хук — только на клиенте
  // ...
}

Где RSC реально полезны

Из своего опыта выделяю три кейса, где Server Components оправданы:

1. Тяжёлые зависимости — например, компонент использует pdf-lib для генерации PDF. Тащить эту либу в клиентский бандл бессмысленно.
2. Прямой доступ к ресурсам — подключение к DB/REST/gRPC прямо из компонента без прокси-API.
3. Статичный контент с вкраплениями интерактива — скажем, статья с комментариями, где сама статья — RSC, а форма комментария — Client Component.

Но есть нюанс: если у вас уже настроен эффективный API-слой, RSC могут добавить больше сложности, чем пользы.

Подводные камни, о которых редко говорят

1. Сложность дебага — ошибки в Server Components иногда проявляются только в непонятных сообщениях типа “Invalid RSC payload”.
2. Ограниченный интерактив — попытка использовать useState или onClick в RSC приведёт к ошибке. Приходится дробить компоненты.
3. Проблемы с кешированием — динамические RSC (рендерящиеся при каждом запросе) могут убить производительность, если не настроить кеширование.

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

Когда пока не стоит лезть в RSC

• SPA с богатым интерактивом — если у вас много состояний, сложные формы, то RSC дадут мало преимуществ
• Проекты без Next.js — на чистом React реализовать RSC сложно, почти все production-кейсы завязаны на Next
• Команды без опыта SSR — если у team lead’а глаза начинают дёргаться при словах “гидратация”, рано говорить про Server Components

Сейчас мой подход — внедрять RSC постепенно, начиная с самых очевидных кейсов (статичные страницы, тяжелые библиотеки). А ваш?

Источник: https://www.reddit.com/r/reactjs/comments/1vpmwfa/discussion_about_server_components/