Какие ограничения серверных компонентов важно учитывать и как они влияют на решение?
Компоненты
Серверные компоненты (RSC) выполняются только на сервере — оттуда и все ограничения: у них нет браузера и нет «жизни» после рендера.
Ограничения
Нет состояния и эффектов: useState, useReducer, useEffect, useLayoutEffect, useContext (клиентский) недоступны — компонент выполняется один раз и не перерисовывается в ответ на действия.
Нет обработчиков событий: onClick/onChange передать нельзя — функции не сериализуются. Интерактив — только в клиентских компонентах (исключение — Server Actions в формах).
Нет браузерных API: window, document, localStorage, matchMedia отсутствуют.
Пропсы, передаваемые клиентским компонентам, должны быть сериализуемыми: примитивы, простые объекты/массивы, JSX; функции и классы — нет.
Направление импорта одностороннее: серверный компонент может рендерить клиентский, но клиентский не может импортировать серверный — только принимать его как children/проп.
Кеширование и «свежесть»: результат может кешироваться фреймворком; обновление — через ревалидацию/повторный запрос, а не через setState.
Как это влияет на решение
- Дерево проектируется «островами»: серверные компоненты — данные, разметка, тяжёлые зависимости (парсеры, ORM — ноль JS клиенту); клиентские — интерактивные листья.
- Состояние формы/модалки/табов живёт в клиентском компоненте; данные для него приходят пропсами сверху.
- Секреты и доступ к БД — безопасно на сервере, но не забывать: всё, что уходит в клиентский компонент пропсом, попадает в payload и видно пользователю.
Коротко для собеседования
RSC: нет state, эффектов, обработчиков и браузерных API; пропсы клиентским компонентам только сериализуемые; клиентский модуль не может импортировать серверный (только children). Следствие — архитектура островов: данные и тяжёлые зависимости на сервере, интерактив в клиентских листьях; данные в payload видны пользователю.