Микро-интерфейсы, веб-компоненты и библиотеки общего доступа

Question

, поэтому я работаю над переводом приложения моей компании на микро-интерфейс.Мы следуем стандарту, описанному в https://micro -frontends.org / .Несмотря на то, что все в настоящее время используется React, мы обертываем вещи веб-компонентами, чтобы в будущем у нас была свобода и гибкость, чтобы не зависеть от фреймворка.У нас есть рабочая архитектура, и она работает прекрасно.Мы даже создали необычный слой совместимости поверх спецификации веб-компонента, который позволяет нам передавать реквизиты, подобные React, веб-компонентам, включая объекты, массивы и даже функции.Это позволяет значительно улучшить взаимодействие между ними.

Основная проблема, которую мы сейчас имеем, - это дублирование библиотек.Мы являемся магазином React, поэтому, несмотря на то, что у нас есть этот независимый от фреймворка подход, все использует React.Хотя этот новый подход дает нам возможность индивидуально обновлять части нашего приложения до более новой версии React (наконец-то), нам все еще не нравится идея такого большого дублирования библиотеки React.

Чтобы поставить еев перспективе, даже Gzipped, React / ReactDOM более 40 КБ.Это супер крошечный в отдельности, но в увеличенном масштабе он начинает занимать все большую пропускную способность.С точки зрения оперативной памяти это меньше проблем, около 130 КБ для этих библиотек, и учитывая объем оперативной памяти большинства устройств, сейчас это не так уж и много.

Но, конечно, мы хотим, чтобы все было максимально оптимизировано и оптимизированонасколько это возможно.Поэтому я надеюсь, что кто-то может предложить способ, с помощью которого приложения для микро-интерфейса (те, которые обернуты в веб-компонент) могут получить React и другие библиотеки из родительского приложения.

Вы должны знать, что JavaScript родительского приложениязагружается до микро-интерфейсов.Каждый микро-интерфейс загружается через тег <script>.Наконец, в настоящее время мы НЕ используем Shadow DOM - компромисс, который мы сделали, чтобы извлечь выгоду из того, как мы переносим существующий код в новую архитектуру микро-интерфейса.

Answer 1

Основная идея состоит в том, чтобы рассказать модульному пакетеру о том, как упаковать ваши микро-интерфейсы.

Предполагая, что вы используете Webpack для объединения ваших приложений, вот две вещи, которые вам нужно сделать.

Шаг 1:

Объявите React как Внешнюю зависимость, как в Webpack config :

externals: {
  'react': 'React',
  'react-dom': 'ReactDOM'
},

Шаг 2:

Перед загрузкой JS родительского приложения убедитесь, что вы загружаете React и ReactDOM из CDN или другого эквивалентного места:

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Поместите эти скрипты в ваш основной index.html, который отвечает за загрузку всего вашего SPA.

Объяснение

Когда вы объявляете определенный пакет / библиотеку как внешний, Webpack не включает его в состав пакета. Предполагается, что внешняя среда сделает эту конкретную версию доступной в качестве глобальной переменной. В случае React он использует React и ReactDOM в качестве глобальных переменных.

Сделав это и включив его через CDN, у вас останется ровно одна копия React и ReactDOM . Когда пользователь посещает приложение в первый раз, оно будет работать медленнее, но после кэширования это не должно быть проблемой

Кроме того, вы можете расширить эту идею, а также объявить их как external для вашего родительского приложения или родительского контейнера оболочки .