Я полагаю, что другие проделали довольно хорошую работу, объясняя React Virtual DOM. Простым и практичным способом я попытаюсь объяснить, как я (буду) управлять развертыванием динамического c веб-сайта (включая корпоративные системы среднего размера) с использованием NodeJS и React. Я также постараюсь не утомлять вас.
Представьте на этот раз, что React никогда не существовало и что вы создавали традиционное приложение для рендеринга на стороне сервера. Каждый раз, когда пользователь выбирает маршрут, контроллер работает с моделью для выполнения бизнес-логики c и возвращает представление. В NodeJS это представление обычно компилируется с использованием механизма шаблонов, такого как рули. Если вы задумаетесь на секунду, станет очевидно, что представлением может быть любой html контент, который затем отправляется обратно в браузер в качестве ответа.
Это типичный ответ, который можно отправить обратно:
<html>
<head>
<title>Our Website</title>
<style></style>
<script src="/link/to/any/JS/script"></script>
</head>
<body>
<h1>Hello World </h1>
</body>
</html>
Если этот ответ попадает в браузер, очевидно, «Hello World» отображается на экране. Теперь, с помощью этого простого подхода, мы можем делать мощные вещи!
ВАРИАНТ 1: Мы можем назначить один контроллер для обработки всех входящих маршрутов app.get("*", controllerFunc) и отобразить одно представление для всего нашего сервера.
ВАРИАНТ 2: Мы могли бы попросить несколько контроллеров обрабатывать различные маршруты и отображать специфичные для маршрута c представления с нашего сервера.
ВАРИАНТ 3: Мы могли бы попросить несколько контроллеров обрабатывать различные маршруты и генерировать страницы на лету (т.е. динамически) с нашего сервера.
Если бы мы строили традиционное веб-приложение, вариант 3 будет единственным разумным стандартом. Здесь страницы генерируются динамически для разных маршрутов. Однако с помощью опции 1 мы можем создать качественное одностраничное приложение, в котором ответ, отправляемый на сервер, представляет собой пустую страницу html, но со встроенным сценарием JS, который имеет возможность манипулировать DOM - Да, Реагировать ! Вот как может выглядеть такой ответ:
<html>
<head>
<title>Our Website</title>
<style></style>
<script src="/link/to/any/JS/script"></script>
</head>
<body>
<h1>Hello World </h1>
<div id="root"> </div>
<script async type=”text/javascript” src="/link/to/our/transpiled/ReactSPA.js"></script>
<!--async attribute is important to ensure that the script has access to the DOM whenever it loads. This also makes the script non-blocking -->
</body>
</html>
Очевидно, что мы возлагаем всю ответственность на сгенерированный SPA, и все журналы маршрутизации c обрабатываются на стороне клиента (см. * 1028). * реагируют-маршрутизатор-дом ). На стороне сервера мы можем представить концепцию в варианте 2 и настроить обработчики маршрутов NodeJS, чтобы прослушивать другой конкретный маршрут c для любого взаимодействия REST API. Если вы знакомы с NodeJS, порядок регистрации маршрутов по app.get() или app.post() имеет значение.
Однако, используя опцию 1, мы можем быстро ограничиться и можем обслуживать только одно одностраничное приложение с этого сервера. Почему? Потому что мы попросили один контроллер обработать все входящие маршруты, не относящиеся к API, и отобразить одно представление. Мы также рискуем обслуживать ненужный раздутый файл JS. Пользователям предоставляется полный веб-сайт, когда все, что им, вероятно, нужно, - это только целевая страница.
Если мы обратимся к варианту 2, то мы можем гораздо больше настраивать и обслуживать несколько одностраничных приложений для разных маршрутов, все с нашего сервера. Такой подход помогает уменьшить размеры сборки JS, отправляемой в браузер. Типичным примером может служить веб-сайт, на котором есть страница приветствия (или каталог введения), страница входа в систему и панель мониторинга.
Назначая контроллеры для разных маршрутов, мы можем создавать SPA специально для этих маршрутов. SPA для начальной страницы, другой для страницы входа в систему, а затем другой для панели инструментов. Да, браузер должен был бы загружаться при переходе между тремя, но, по крайней мере, мы сильно увеличиваем начальное время рендеринга для нашего сайта. Мы также можем использовать более безопасную опцию cook ie для авторизации, а не менее безопасную опцию хранения токенов сессий на localStorage.
В более продвинутых настройках у нас могут быть динамические c веб-сайты с различными компонентами React, отображаемыми как виджеты на динамически генерируемой странице. На самом деле, это то, что делает Facebook.
Способ создания таких SPA или компонентов довольно прост. Запустите реактивный проект и настройте веб-пакет для рендеринга готового к производству файла JS в предпочитаемый каталог publi c stati c в репозитории на стороне сервера. <script>, указанный в представлении, может затем легко загрузить эти встроенные реагирующие компоненты, поскольку они существуют в области действия каталога publi c на стороне сервера.
По сути, это означает один репозиторий с несколькими клиентскими каталогами и один каталог сервера, в котором место назначения файлов рабочей сборки, которые будут сгенерированы веб-пакетом для каждого клиентского проекта, установлено в общедоступный каталог сервера c stati c сервера. Итак, каждый каталог на стороне клиента - это проект (либо полный SPA, либо простой React Component в качестве виджета) со своим собственным файлом webpack.config и package. json. Фактически у вас может быть два отдельных конфигурационных файла - производство и разработка. Затем для сборки вы используете npm ~relevant command~ либо для производственной, либо для разрабатываемой сборки.
Затем вы можете go опередить хост, как и любое приложение NodeJS. Потому что основным приложением является NodeJS - вот где находится сервер. Замените NodeJS на PHP и Apache / NGINX, концепция остается прежней.