<b>RSC ломают привычную схему: сервер больше не “кормит” весь UI одним куском</b>

<b>RSC ломают привычную схему: сервер больше не “кормит” весь UI одним куском</b>

Если коротко, React Server Components полезны там, где страницу выгодно собрать ближе к данным, а не тащить всё в браузер. Для лендинга и SaaS это обычно даёт: меньше JS на клиенте, проще скрывать секреты, лучше старт без тяжёлых hydration-узлов.

Но RSC не чинят плохую архитектуру сами по себе. Если в компоненте смешаны запросы, форматирование и интерактивность, вы просто переносите хаос на сервер. Правило простое: серверный компонент — про чтение данных и компоновку, клиентский — только про события, состояние и браузерные API.

На практике удобно держать границу так:
— данные и кэширование в server components;
— формы, фильтры, модалки, drag&drop — в client components;
— тяжёлые библиотеки выносить вниз по дереву, а не в корень;
— передавать в клиент только то, что реально нужно для рендера.

Есть наблюдение которое стоит проверить: если после внедрения RSC вы не уменьшили объём клиентского JS и не упростили data flow, то выгоды почти нет. Значит, граница проведена формально, а не по смыслу.

Итог простой: RSC хорошо работают не как “фича ради фичи”, а как способ жёстко разделить чтение данных и интерактивность. Начинайте с одного экрана, где это особенно видно, и измеряйте не магию, а объём JS и сложность компонентов.