Начал я писать про еще одно нововведение в NextJS 13 - лайауты, как понял, что сначала стоит рассказать про React Server Components (RSC).
Уже два года назад был выложен RFС (Ready for comment, документ с описанием фичи) по серверным компонентам (reactjs/rfcs/0188-server-components.md), но какую-либо популярность такие компоненты пока не обрели. Я думаю вы либо не слышали про них, либо не использовали (а если использовали, поделитесь в комментариях впечатлениями).
Если в двух словах, это такие компоненты, которые рендерятся только на сервере и код которых не попадает в клиентский бандл (в отличие от обычного SSR). Это позволяет на клиент загружать JS-код только интерактивных компонентов (zero-bundle-size components), реализовать более простой код сплиттинг, избавиться от client-server waterfalls (когда мы сразу в нескольких компонентах загружаем данные внутри
useEffect и одновременно создаем N запросов на сервер). По сути это попытка реализовать частичную регидрацию (partial rehydration), когда мы "гидрируем" только клиентские компоненты.Все бы ничего (и даже в теории очень круто), но помимо технических проблем (типа клиентского роутинга и кеширование компонентов на сервере), у RSC очень ужасный DX (developer experience). (1) Свой API использования, (2) сложный жизненный цикл, (3) необходимость настраивать сервер и (4) отсутствие документации. Раньше, при обычном SSR, у нас были изоморфные компоненты, которые могли рендериться и на сервере, и на клиенте. Да, на сервере не работали хуки
useEffect, для каких-то компонентов нужно было явно возвращать null при рендеринге на сервере, но они были универсальными. Сейчас же (в контексте RSC) универсальные компоненты из себя представляют чистые функции (в которых нельзя использовать хуки), и они просто возвращают JSX. Серверные компоненты представляют собой вообще отдельный вид функций (с async-await, без хуков).Чтобы отличить клиентские и серверные компоненты, придумали использовать директиву "use client" в начале файла, что тоже на мой взгляд является проблемой. Помимо разработчика и React-а, эту директиру должен понимать сборщик (и если Webpack это умеет, то, например, для Vite, нет реализации), IDE, eslint и другие инструменты. И кстати, внешние библиотеки тоже (reactjs/rfcs/pull/227#issuecomment-1301626536). Явное разделение компонентов на серверные и клиентские без правильной архитектуру сделает код в разы сложнее, чем это можно было сделать с самописным SSR.
Возможно, если для RSC сделать API как у клиентских, избавиться от явного указания директивы (чтобы бандлеры сами определяли, серверный компонент или нет), то фича сдвинется с места. Но пока по моим ощущениям реализовывать вручную в своих проектах серверные компоненты никто не будет, и использоваться они будут только под капотом больших фреймворков, типа NextJS (что и произошло в последнем релизе).