ТЛ; др
В зависимости от вашего варианта использования вы можете использовать только SSR, только разделение кода или комбинировать оба при необходимости.
Заслуги ССР
Лучше SEO , поскольку поисковые роботы имеют разметку для работы (и не обязательно зависят от выполнения javascript) для индексации.
Ускоренный начальный рендеринг , поскольку разметка отправляется с сервера, браузер не должен ждать выполнения javascript для его рендеринга. (Хотя разметке по-прежнему будет не хватать интерактивности, пока реакция не станет гидратированной на стороне клиента).
Сначала доставить критический CSS . Критический CSS для начального рендеринга страницы может быть встроенным, лучше UX, так как загруженная разметка уже будет иметь готовые стили.
Упрощенное разбиение маршрута . SSR imo упрощает рассуждение о разделении маршрута вашего приложения. Например, у вас могут быть разные страницы для /about и /home, которые можно использовать для разделения маршрута, чтобы уменьшить размер пакета (и при необходимости предварительно загрузить другие маршруты на стороне клиента).
Объединение кода, разделяющего ваши компоненты и SSR
Возможно, нет необходимости выполнять серверную визуализацию всей вашей страницы. Например, предположим, что ваша домашняя страница (которую вы хотите отобразить на сервере) содержит компонент Chat, чтобы пользователи могли напрямую задавать вам вопросы.
Если этот компонент большой, вы можете отказаться от его рендеринга на сервере, чтобы пользователь мог сначала получить самые важные фрагменты страницы. Это уменьшит вашу начальную загрузку страницы за счет разделения кода этого компонента на компоненте домашней страницы.
Когда браузер проанализировал разметку, он загрузит ваш компонент Chat после основного пакета. Таким образом, вы можете идентифицировать и контролировать размеры ваших пачек.
Только с использованием разделения кода
Это идеальный способ для создания приложения, если вы не заинтересованы в преимуществах SSR.
Например, если ваше приложение является пользовательской панелью для аутентифицированных пользователей, может быть лучше вообще не беспокоиться о SSR, а просто разделить код вашего приложения. Также обратите внимание, что на сервер, выполняющий рендеринг вашего приложения, потребуется больше времени для отправки ответа на сервер (вместо простых REST API), поскольку разметка должна быть создана.
Приходите на ваши вопросы:
Я запутался, как расщепление кода вписывается в модель ssr. Является ли ssr отрисовкой первого попадания, а затем деление кода после этого выполняется на клиенте?
Да, вроде. Браузер получает начальную загрузку с сервера, после чего клиент заботится о загрузке необходимых битов. Теперь вы можете решить предварительно загрузить серверную часть компонентов и также отправить все (пожалуйста, отметьте react-loadable, о котором я упоминаю в конце этого ответа).
Как бы это отличалось от разделения кода на сервере. Это если вы идете по определенному маршруту, то извлекаете этот кусок для первого рендера?
lazy - это просто более чистый API с поддержкой Suspense для разделения кода. В идеале, когда вы загружаете маршрут в первый раз, сервер отрисовывает начальную разметку, а затем позволяет клиенту позаботиться о загрузке следующих битов и маршрутизации. Imo Next.js делает это очень хорошо.
Как бы это отличалось, если бы это было сделано на сервере.
Вы можете предварительно загрузить все свои компоненты или только необходимые биты. Пожалуйста, проверьте Объединение кода, разделяющего ваши компоненты и раздел SSR .
Есть ли реальная выгода для ssr с разделением кода. Разве это не просто добавляет сложности?
У всего здесь есть свой компромисс, imo. Как я уже упоминал в разделе Only, использующем разделение кода , прекрасно использовать разделение кода, если ваш вариант использования не требует преимуществ SSR.
Примечание
В настоящее время lazy (в React v16.6.1) не полностью поддерживает SSR. Возможно, вы захотите проверить react-loadable для обработки случаев, когда вы хотите предварительно загрузить компоненты на стороне сервера.