Реакция рендеринга на стороне сервера - Virtual DOM?

Недавно я начал изучать SSR (рендеринг на стороне сервера), и я впечатлен его преимуществами. Назовем несколько значений времени загрузки, SEO, без конфигурации javascript.

Однако я пытаюсь понять, стоит ли реагировать на рендеринг на стороне сервера. React известен своими манипуляциями с виртуальным DOM, но использование реакции с рендерингом на стороне сервера не дает преимуществ reactJs.

Может ли кто-нибудь поделиться своими идеями об использовании reactJS для рендеринга на стороне сервера?

4.5к репутации и до сих пор задаете такие вопросы?

Sulthan 30.06.2018 13:02

Но я не нашел на это правильного ответа. Я не вижу особой пользы от использования reactJS для рендеринга на стороне сервера. Не был уверен, что это неправильный вопрос. Было бы полезно, если бы меня направили в правильном направлении.

G_S 30.06.2018 13:06

В конечном итоге React на стороне сервера просто выведет строку HTML для клиента, как если бы она была отрисована фреймворком PHP или ASP.NET Razor. Так что, в конце концов, вы даже можете использовать его для веб-приложения, отрисованного на 100% на стороне сервера, без React во внешнем интерфейсе.

John Weisz 30.06.2018 13:08

React по-прежнему является хорошим способом создания html на серверах node.js, даже если полученный HTML статичен и только что возвращен клиентам.

Sulthan 30.06.2018 13:09

Итак, из приведенных выше комментариев я не вижу преимущества Virtual DOM, а все генерация html будет выполняться на стороне сервера и возвращаться клиенту, где html будет отображаться напрямую

G_S 30.06.2018 13:11
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Навигация по приложениям React: Исчерпывающее руководство по React Router
Навигация по приложениям React: Исчерпывающее руководство по React Router
React Router стала незаменимой библиотекой для создания одностраничных приложений с навигацией в React. В этой статье блога мы подробно рассмотрим...
Массив зависимостей в React
Массив зависимостей в React
Все о массиве Dependency и его связи с useEffect.
1
5
1 478
1

Ответы 1

Использование рендеринга на стороне сервера в 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 появится на картинке.

G_S 01.07.2018 07:03

Нет, Virtual DOM не будет использоваться в этом случае, поскольку сервер (обычно) не хранит дерево компонентов клиента - в этом отношении он не имеет состояния. Всякий раз, когда маршрут изменяется, сервер генерирует новое дерево компонентов и отправляет новый ответ, что означает полную перезагрузку страницы. Что можно сделать, так это то, что исходный документ отправляется с сервера, а затем любые последующие изменения маршрута происходят на стороне клиента (как и в SPA).

catchergeese 02.07.2018 11:55

@catchergeese, можете ли вы прокомментировать масштабируемость ReactJS SSR в большом масштабе. Если на зарегистрированных страницах с динамическим контентом наблюдается большое количество обращений, вы рекомендуете перейти с Nunjucks на ReactJS SSR. Мы планируем провести рефакторинг до ReactJS SPA для существующего решения MPA. Меня беспокоит немного масштабов SSR. Есть ли у вас опыт, которым можно поделиться?

sudhanshu 22.10.2018 13:25

Спасибо за вопрос, @sudhanshu. Это действительно актуальный вопрос, хотя трудно дать однозначный ответ, поскольку варианты использования значительно различаются, а «высокий масштаб» - довольно относительный термин, но позвольте мне поделиться своим опытом на более общем уровне. При SSRing на ваш сервер оказывается незначительное дополнительное усилие. Хорошей отправной точкой может быть просмотр malloc.fi/….

catchergeese 23.10.2018 15:11

Да, я прошел через это, пока он соответствует той пропускной способности, которую я в порядке. Другая проблема, о которой я размышлял, - это продажа чего-то вроде NextJS в нескольких проектах в моей компании. Это привнесет в ReactJS много самоуверенного стиля NextJS. Как будто нужно отключить React Router.

sudhanshu 24.10.2018 09:17

Другие вопросы по теме