Недавно я начал изучать SSR (рендеринг на стороне сервера), и я впечатлен его преимуществами. Назовем несколько значений времени загрузки, SEO, без конфигурации javascript.
Однако я пытаюсь понять, стоит ли реагировать на рендеринг на стороне сервера. React известен своими манипуляциями с виртуальным DOM, но использование реакции с рендерингом на стороне сервера не дает преимуществ reactJs.
Может ли кто-нибудь поделиться своими идеями об использовании reactJS для рендеринга на стороне сервера?
Но я не нашел на это правильного ответа. Я не вижу особой пользы от использования reactJS для рендеринга на стороне сервера. Не был уверен, что это неправильный вопрос. Было бы полезно, если бы меня направили в правильном направлении.
В конечном итоге React на стороне сервера просто выведет строку HTML для клиента, как если бы она была отрисована фреймворком PHP или ASP.NET Razor. Так что, в конце концов, вы даже можете использовать его для веб-приложения, отрисованного на 100% на стороне сервера, без React во внешнем интерфейсе.
React по-прежнему является хорошим способом создания html на серверах node.js, даже если полученный HTML статичен и только что возвращен клиентам.
Итак, из приведенных выше комментариев я не вижу преимущества Virtual DOM, а все генерация html будет выполняться на стороне сервера и возвращаться клиенту, где html будет отображаться напрямую





Использование рендеринга на стороне сервера в React делает не подразумевать, что React не будет использоваться на стороне клиента.
Один из полностью верных подходов - начать только с рендеринга на стороне клиента. В этом случае вам нужно настроить один элемент HTML в вашем HTML-файле, который станет ловушкой для React после его загрузки.
Чтобы дать вам пример, допустим, у нас есть элемент <div id = "root"></div> в файле index.html, который будет обслуживаться, если мы HTTP GET GET / path на нашем сервере. Исходный документ (в нашем случае index.html) также должен ссылаться на файл javascript, который включает React и наш код. Это можно сделать, добавив что-то вроде <script type = "text/javascript" src = "/index.js"></script> непосредственно перед тегом </body>.
В какой-то момент, когда выполняется index.js, вызывается метод ReactDOM.render() (примечание: мы находимся в браузере прямо сейчас) - это момент времени, когда React ищет элемент div с идентификатором root, прикрепленным к документу. После того, как он найден, он становится react-root - дерево компонентов монтируется под этим элементом и управляется React (то есть виртуальным DOM, обработчиками событий, обновлениями состояния).
Обратите внимание, что этот подход требует, чтобы по крайней мере один файл javascript был извлечен, проанализирован и выполнен, прежде чем браузер сможет сделать что-нибудь значимым (кроме пустого div) для пользователя. Для некоторых сценариев это неприемлемо, и здесь может помочь SSR (рендеринг на стороне сервера).
Для рендеринга на стороне сервера требуется, чтобы на вашем сервере была доступна среда выполнения JavaScript. Один из популярных вариантов - Node.js (другие включают, например, Nashron для JVM).
В подходе вы выполняете React на сервере и используете метод ReactDOMServer.renderToString() (или ReactDOMServer.renderToNodeStream()) для генерации ответа HTML, который отправляется клиенту - вместо почти пустого ответа с одним заполнителем div, как раньше, теперь вы можете отправить всю разметку, которая будет сгенерирован из вашего дерева компонентов (здесь важно отметить, что в React 16.4 (+) на стороне сервера вызывается только метод жизненного цикла UNSAFE_componentWillMount). После того, как первоначальный ответ с документом отправлен клиенту, браузер может отобразить начальную разметку еще до того, как index.js завершит загрузку. Как только это произойдет, сработает метод ReactDOM.hydrate(). Гидратация - это процесс использования существующей разметки, отображаемой на стороне сервера, и «поливки» ее с помощью javascript-функций, таких как обработчики событий. После того, как это будет сделано, это дерево компонентов теперь полностью управляется React со всеми преимуществами.
Обратите внимание, что в SSR точно такое же дерево компонентов отображается на стороне сервера, а затем гидратируется на стороне клиента.
Конечно, React также можно использовать вместо движков шаблонов в качестве очень мощного генератора статической разметки HTML. Все, что вам нужно сделать, это отобразить разметку на сервере с помощью ReactDOMServer. renderToStaticMarkup() и отправить ее клиенту. Следует отметить, что этот подход оказывает значительное влияние на производительность (https://malloc.fi/performance-cost-of-server-side-rendered-react-node-js) и использует очень ограниченное количество функций React.
ОК. Таким образом, всякий раз, когда маршрут изменяется, только тогда контент будет подготовлен на стороне сервера как часть рендеринга на стороне сервера и возвращен клиенту, и с этого момента Virtual DOM появится на картинке.
Нет, Virtual DOM не будет использоваться в этом случае, поскольку сервер (обычно) не хранит дерево компонентов клиента - в этом отношении он не имеет состояния. Всякий раз, когда маршрут изменяется, сервер генерирует новое дерево компонентов и отправляет новый ответ, что означает полную перезагрузку страницы. Что можно сделать, так это то, что исходный документ отправляется с сервера, а затем любые последующие изменения маршрута происходят на стороне клиента (как и в SPA).
@catchergeese, можете ли вы прокомментировать масштабируемость ReactJS SSR в большом масштабе. Если на зарегистрированных страницах с динамическим контентом наблюдается большое количество обращений, вы рекомендуете перейти с Nunjucks на ReactJS SSR. Мы планируем провести рефакторинг до ReactJS SPA для существующего решения MPA. Меня беспокоит немного масштабов SSR. Есть ли у вас опыт, которым можно поделиться?
Спасибо за вопрос, @sudhanshu. Это действительно актуальный вопрос, хотя трудно дать однозначный ответ, поскольку варианты использования значительно различаются, а «высокий масштаб» - довольно относительный термин, но позвольте мне поделиться своим опытом на более общем уровне. При SSRing на ваш сервер оказывается незначительное дополнительное усилие. Хорошей отправной точкой может быть просмотр malloc.fi/….
Да, я прошел через это, пока он соответствует той пропускной способности, которую я в порядке. Другая проблема, о которой я размышлял, - это продажа чего-то вроде NextJS в нескольких проектах в моей компании. Это привнесет в ReactJS много самоуверенного стиля NextJS. Как будто нужно отключить React Router.
4.5к репутации и до сих пор задаете такие вопросы?