Server Components ломают привычный паттерн «всё рендерим в клиенте»

Server Components ломают привычный паттерн «всё рендерим в клиенте»

Если в проекте React/Next.js Server Components включены, сначала разделяйте не код, а ответственность: где данные, где интерактив, где кеш. Компонент без state, effects и браузерных API — кандидат на сервер. Всё, что реагирует на клик, ввод, локальный storage или DOM, уезжает в client boundary.

Главная ошибка — тащить в серверный слой лишние зависимости. Один случайный hook, библиотека с обращением к window или контекст для клиента, и дерево начинает дробиться. Сразу проверяйте: можно ли отдать этому компоненту только данные и разметку? Если нет — не маскируйте его под RSC ради красивой архитектуры.

Для SaaS и лендингов RSC полезны там, где много статичного UI, каталоги, дашборды с тяжёлой читаемой частью и редкими интерактивными островками. Это снижает объём JS на клиенте и упрощает первый рендер. Но любая сложная форма, фильтры в реальном времени и локальные состояния должны оставаться компактными и изолированными.

Есть наблюдение которое стоит проверить: чем меньше граница между server и client, тем дешевле сопровождение. Не стройте серверные деревья из клиентских привычек. Сначала вырежьте интерактив в отдельные островки, потом уже оптимизируйте fetch, кеш и повторное использование данных.

Если у компонента нет причины жить в браузере — пусть живёт на сервере; если есть хотя бы одна причина, делайте client boundary максимально маленькой.