<b>Server Components ломают привычную логику: где хранить состояние, а где HTML</b>

<b>Server Components ломают привычную логику: где хранить состояние, а где HTML</b>

Если коротко: Server Components нужны не для того, чтобы «ускорить всё», а чтобы не тащить лишний JS туда, где он не нужен. Типовая ошибка — сделать половину дерева клиентской по привычке и потом удивляться, почему bundle не худеет.

Проверьте три вещи:
— компонент читает данные и сразу рендерит разметку → кандидат в server;
— есть useState, useEffect, обработчики событий, доступ к window → это уже client;
— граница между ними должна быть ниже, чем кажется: лучше один маленький client-блок, чем целая страница с "use client".

Отдельно смотрите на пропсы. В server нельзя безопасно прокидывать функции, классы и всё, что не сериализуется. Поэтому архитектура упирается не в синтаксис, а в контракт между слоями: сервер готовит данные и HTML, клиент берёт только интерактивность. Это особенно важно в SaaS-формах, кабинетах и каталогах, где много статичного UI и мало действий.

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