Какую систему микрофронтенда мы хотим от сцены

внешний интерфейс

Эта статья обычно предназначена для того, чтобы ответить на несколько вопросов:

  1. Миграция на микро-фронтенды, что именно мы хотим?
  2. Какие части обычно включает в себя отраслевая «микроинтерфейсная» система?
  3. Какая технология обычно используется для «микроинтерфейсного фреймворка», близкого к одноклассникам R&D?
  4. Может ли проект нашей команды сейчас находиться на "микроинтерфейсе"? Что нужно изменить и в какой степени?

(Читайте полный текст ниже примерно через 20 минут)


Micro front-end понятие не новое, о нем в той или иной степени слышали все, здесь я не буду давать кучу определений, а просто подытожу обзор/обзор текущих отраслевых практик, эта статья нацелена наЕще нетСтуденты или команды, которые использовали микро-интерфейсы в своем бизнесе, могут легко получить общее представление о «микро-интерфейсах» с помощью этого обзора;

В общем, понятие "микрофронтенд" до сих пор в расцвете от его создания до его разработки (делать свое делоПри разработке не существует единого консенсуса/стандарта (с высокой долей рынка); каждая крупная фабрика/сообщество имеет разные определения этой концепции и лежащей в ее основе технологии.


Итак, чего мы хотим?

Как следует, этотипичныйПример структуры микроинтерфейса : на странице, доступ к которой осуществляется по URL-адресу, имеется основное приложение (базовое), несколько сосуществующих подприложений A/B, а подприложение B имеет вложенное подприложение C. ; их могут использовать разные команды Независимая разработка, каждое приложениеОнлайн самостоятельно, не мешая друг другу.


«Независимый онлайн» «Невмешательство»

Важно для нас«Независимый онлайн» «Невмешательство», не мешают друг другу на уровне онлайн-релиза и не мешают друг другу на уровне сосуществования приложений;

Это самая интуитивная способность, которую нам должен принести микро-фронтенд, потому что прямая проблема, с которой мы сталкиваемся, это «есть внутренние модули, которые нужно разобрать по разным командам для разработки, как выпустить и выйти в онлайн» (т.е. , «разделить некоторые большие внутренние модули на подприложения» »).

начать с«Не мешать друг другу на уровне онлайн-релиза»Если говорить, например, о главном приложении версии 1.0.1, а о вспомогательном приложении А версии 2.1.0, люди из разных команд запустили свои собственные приложения, и это никак не повлияло на ритм их релизов;

Когда вспомогательное приложение A обновляется до версии 2.1.1, основное приложение и вспомогательное приложение B должныНикаких изменений/релизов вообще, онлайн-страница — это вспомогательное приложение A, эта область является новой.

Упростите этот случай до минимального, всего одно основное приложение и одно вспомогательное приложение, давайте посмотрим«Независимый онлайн»это дело.

Перед этим давайте поговорим о не-микро интерфейсе,загрузка страницыКак это работает:

Обычно запись результата упаковки приложения на странице интерфейса представляет собой раздел<script>Тег загружает файл js и после выполнения монтирует содержимое в узел dom, как показано ниже.

<html>
  <head>
    ...
  </head>


  <body>
    <div id="root"></div>
    <script src="//cdn/entry/main-app.js@1.0.2"></script>
  </body>
</html>

При доступе к разным маршрутам (url-адресам) на странице исходно упакованные js будут асинхронно загружать js-чанки соответствующих маршрутов и компонентов, а затем отображать содержимое/компоненты по этому маршруту после получения кода;

Возьмем, к примеру, webpack, вставив<script>тег для получения других фрагментов js, каждый фрагмент js загружается с помощью jsonp (файл входа — IIFE).

<html>
  <head>
    ...
    <script src="//cdn/chunk/0.f3c200e0.async.js"></script>
    <script src="//cdn/chunk/1.5bb06b78.async.js"></script>
  </head>

  <body>
    <div id="root"></div>
    <script src="//cdn/entry/main-app.js@1.0.2"></script>
  </body>
</html>

// 0.f3c200e0.async.js

(window.webpackJsonp=window.webpackJsonp||[]).push([chunkId], xxxChunk)

Затем переключитесь на фреймворк микро-интерфейса, загрузка будет немного другой, в частности, при рендеринге контента в определенных областях,От «загрузки собственного чанка» к «загрузке записи приложения», загрузчик изменен с веб-пакета на "контейнер микро-фронтенда";

получить доступhttps://xxx-domiain/main-app/sub-route/xxxxНапример, упрощенный процесс:

  1. Основное приложение соответствует/main-app/sub-souteМаршрут, отображать содержимое текущего маршрута
  2. Если в текущем содержимом маршрутизации есть подприложения, загрузите их асинхронно.Запись подприложения
  3. подприложение соответствует/sub-route/xxxxМаршрутизация, рендеринг соответствующего контента маршрутизации в своей области

назад«Независимый онлайн»В этом вопросе, во-первых, уже всем известно, что микро-фронтенд-фреймворк на самом деле«Родительское приложение загружает запись дочернего приложения», а затем просто задайте этот «вход» как раздел js (или html), как показано на рисунке ниже,

Тогда у нас еще так много проблем;

  • Как внедрить скрипт записи загрузки, куда его загрузить и как контролировать версию?
  • Где выйти в интернет, как выйти в интернет?
  • Когда поддержание является онлайн и обновлена, почему бы не позволить основным приложению быть переупаковано?
  • Как выбрать другую версию для запуска/отката/оттенков серого?
  • Как я могу увидеть список всех текущих под-приложений?
  • Как интегрировать совместную отладку при переключении между несколькими версиями?
  • ...

Микро интерфейсная система

На самом деле это отражает то, чтоНаш спрос на «микро-интерфейс» — это не только «фреймворк микро-интерфейса», но и целая поддерживающая «система микро-интерфейса»;

Это общее содержание системы.Последние несколько вопросов в предыдущем разделе можно определить по«Система управления» «Пакет разработки»ответить, и обычно все говорят"Фреймворк микро-интерфейса"только в этой системе«Контейнер времени выполнения»эта часть;


система управления

«Систему управления» можно рассматривать как онлайн-платформу управления + онлайн-процесс выпуска;

Согласно текущим результатам исследования, реализация микро-фронтенда должна быть оснащена такой платформой управления, хотя она настолько абсолютна, но имеет на две функции больше, чем онлайн-платформа не-микро-фронтенда:

  • Управление приложением- Могут быть запущены разные версии различных основных приложений и подприложений, а также могут быть перечислены адреса входа различных версий онлайн-приложений.
  • управление зависимостями- Четкое управление зависимостями приложения родитель-потомок и ввод адреса входа дочернего приложения в родительское приложение.

Согласно предыдущему разделу «Загрузка записи», загрузка записи дочернего приложения — это родительское приложение для загрузки URL-адреса js, например:https://cdn/.../entry@v1.js, то подприложениеонлайнТо есть обновить URL-адрес (версию), каждый раз, когда он выходит в сеть, это новый адрес входа (версия);

А для того, чтобы «обновить суб-приложение онлайн и предотвратить переупаковку основного приложения», также необходимо разрешить этому URL-адресу записи проходить через онлайн-платформу.инъекцияв родительское приложение, а не жестко кодировать в коде родительского приложения; этоинъекцияПроцесс и то, какие субприложения внедряются, выполняются на этой онлайн-платформе управления.

Другие части, такие как «выпуск версии», «план в оттенках серого» и «приватизация», соответствуют общей интерфейсной онлайн-платформе развертывания и не будут повторяться;

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

В приложении: некоторые результаты исследования

грузовой контейнер Платформа управления
Qiankun(на базе одного спа) OneX (Внутри Али — Ant Financial)
MicroX (внутри Али) MicroX + CSKit (внутри Alibaba — Alibaba Cloud Intelligence)
icestark Iceworks (Ali Inside-Flying Ice)
alfajs Альфа (Alibaba Internal — Alibaba Cloud Console)

Пакет разработки

Эта часть документации особенно важна, это не просто введение в фреймворк микроинтерфейса, включая документацию самой разработки, а также только что упомянутый «процесс онлайн-релиза». должны иметь документы, соединенные последовательно.

Существуют небольшие различия между сборкой/выпуском, что означает, что упакованные записи могли измениться или даже больше; формат продукта подприложения имеет некоторые ограничения, такие как потребность в дополнительных файлах, связанных с «загрузочной записью».

Интегрированная отладка между несколькими приложениями «родитель-потомок» включает:

  • Локальная разработка подприложений может быть отделена от родительского приложения и начинать разработку и отладку независимо
  • Отладка локального дочернего приложения и доступ к родительскому приложению, оба запускаются локально
  • Чтобы воспроизвести онлайн-баги, нужно отладить дочернее приложение и родительское приложение для доступа, одно из которых запускается локально, а другое загружается онлайн

микроматериалы

Пунктирная линия нарисована для «микроматериалов», потому что они появились относительно поздно в построении системы (также далеко от нашего понимания).(Aeolus)Текущий спрос далеко), на ранней стадии работы микроинтерфейса нет необходимости в реализации;

А появление «микроматериалов» — это по сути трансформация формы микрофронтенда, изменение микрофронтенда из"Комбинация приложений на разных уровнях страницы, без пакетов"преобразовать в«В соответствии с протоколом интерфейса удаленные компоненты и функции могут быть загружены напрямую, без пакетов»,

Он напрямую стирает границы App/Page/Component(widget)/Function/Plugin, написан в виде нативного браузерного импорта esm и deno import (есть еще бэкенд "удаленный вызов процедур" (RPC) в способ вызова. Чувство), напрямую снижая порог повторного использования компонентов и удаленной загрузки, поэтому такие вещи, как рынок материалов, также будут следовать этой тенденции;

// 伪代码示例，加载函数级别的微组件并执行
import foo from 'https://cdn/.../foo.js'
const foo = import('https://cdn/.../foo.js')
const foo = load('https://cdn/.../foo.js')
foo(xxx)

В этом случае просто различайте границы текущих заголовков.

  • App- Целое микроинтерфейсное приложение также может иметь множество модулей и несколько страниц внутри.
  • Page- Чуть более крупный компонент микроинтерфейса с маршрутизацией можно назвать страницей, например страницей запроса данных.
  • Widget- Виджеты (виджеты) без роутинга, например кнопки с уникальным стилем
  • Function- Функциональная функция, которая загружается и выполняется удаленно, например, представьте себе загрузку функции в lodash с помощью UMD (формат интерфейса определяется вне приложения)
  • Plugin- Формат интерфейса, относительно строгие функции, определяемые контекстом выполнения (формат интерфейса определяется приложением)

контейнер среды выполнения

Эта часть — то, что обычно делает «микроинтерфейсный фреймворк» в узком смысле;


Что он в основном делает, возможно, это:

  • загрузка приложения- В соответствии с зарегистрированным подприложением через указанный URL-адрес загрузите запись подприложения в согласованном формате и смонтируйте ее в указанное место.
    • В настоящее время в отрасли существует два распространенных формата входа:HTMLиJS
      • JS более чистый в качестве входа, и проще преобразовать старые проекты с HTML в качестве входа.
    • Комбинация входа отца и сына(т.е. определить зависимости)Так же есть два режимасостав времени сборкиикомпозиция во время выполнения
      • Некоторые фреймворки получают статус регистрации субприложения и адрес входа на основе данных, подобных манифесту.
      • Частичная поддержка фреймворка иПлатформа управленияПри сотрудничестве среда выполнения принимает адрес входа, динамически вводимый платформой.(Есть также фреймворки, которые утверждают, что среда выполнения и платформа управления развязаны, но на самом деле, если вы ее не используете, вам придется реализовать логику внедрения самостоятельно)
  • жизненный цикл- загружать/монтировать/обновлять/выгружать и т.д.
    • Инициализация при загрузке/монтировании, защита разрешений, язык i18n и т. д.
    • Очистка при удалении, например удаление тегов скриптов, тегов стилей, субприложений dom и т. д.
    • И мост для двустороннего обновления при маршрутизации и связи родитель-потомок
  • синхронизация маршрута- При переключении маршрута субприложения URL-адрес обновляется синхронно; когда URL-адрес перескакивает/обновляется, суб-приложение обновляется синхронно
    • То есть маршрутизация для подприложений эквивалентна url
  • связь приложений- Это означает поддержку удобной связи между родительским и дочерним приложениями, не такой сложной, как postMessage (имеется в виду строки)
    • Что, вы просите родственные приложения общаться друг с другом? Конечно, все используют родительское приложение в качестве EventHub.
  • изоляция песочницы- Для того, чтобы каждое приложение «дополняло друг друга», каждое приложение должно выполняться в «изолированной» среде.
    • Без изоляции глобальные стили CSS могут быть конфликтующими и хаотичными, а глобальные переменные JS могут быть загрязнены/подделаны/заменены.
    • В этой части отрасли существует множество решений и направлений развития, и я расскажу об этом в следующей главе.
  • Обработка исключений- Унифицированная обработка всех вышеперечисленных вещей, когда сообщается об ошибке, такой как сбой загрузки или сбой сопоставления маршрута.

изоляция песочницы

Обычно между несколькими приложениями необходимо изолировать только две части: JS и CSS;

JS-изоляция

Snapshot

дополнительное приложениеустанавливать, сначала сделайте снимок глобальной переменной окна и поместите его в замыкание, затем бросьте глобальное окно в суб-приложение и поместите его в суб-приложениеудалитьПри восстановлении глобальной переменной окна через снапшот;


Это практика некоторых ранних фреймворков, на самом деле это не формирует "изоляцию", а лишь предотвращает "загрязнение" друг друга несколькими подприложениями, также есть много ограничений:

  • Родительские и дочерние приложения не могут сосуществовать, а вся страница под маршрутом URL-адреса является дочерним приложением.
  • Несколько подприложений не могут сосуществовать, потому что существует только одно глобальное окно и только один снимок.
  • Безопасность метода снимка недостаточно строгая, и у глубокой копии будут проблемы при встрече с документом/историей и т. д.

Сейчас такого нет, и используется идея песочницы.


Sandbox


Wasm VM

Перекомпилируйте интерпретатор Wasm JS и поместите его в браузер, а суб-приложение поместите прямо в эту виртуальную машину для выполнения;

Изоляция очень строгая, я видел много технических статей, объясняющих это, но до сих пор не исследовался ни один реальный фреймворк микро-фронтенда.

Причина та же, что если вы не используете Web Worker/iframe, изоляция слишком строгая, связь очень хлопотная, а накладные расходы на связь очень большие;

(Но есть и другие способы использования помимо микроинтерфейсов, напримерStackBlitz )


with() + new Function(code) + Proxy

withСинтаксис используется для изменения цепочки областей видимости, которая используется здесь для перехвата оконных просмотров при записи доступа к глобальным переменным, таким как прямой доступArray.fromвместоwindow.Array.fromкогда пишешь


new FunctionФункция выполнения кода эквивалентна eval, но eval может получить доступ к текущим локальным переменным области видимости, независимо от того, где выполняется новая функция возврата Function, она может получить доступ только к глобальной области видимости, что нам и нужно.


иProxyПредоставляется объект, используемый в замыканиях with и new Function в качестве области действия окна. Атрибут белого списка ограничивает доступ к некоторым элементам в реальном окне. Через прокси при удалении/добавлении глобальных переменных/apis реальные глобальные переменные не будут затронуты y окно оказывает влияние;


В то же время он перехватывает различные операции над документом/историей/местонахождением, такие как вставка элементов в document.body для перемещения вселенной, переписывание history.push и последующая синхронизация его с URL-адресом, перехват пути расположения, чтобы только подприложения получить внутренние маршруты и т. д., эти различные ограничения составляют среду песочницы;


// 简化伪代码示例
window = new Proxy(pick(window, whiteListProperties), { ... })
document = new Proxy(document, { ... })
...

sandbox = new Function(`
  return function ({ window, location, history, document }, code){
    with(window) {
      ${code}
    }
}`)


sandbox().call(window, { window, location, history, document }, code)

Но степень перехвата окна здесь ограничена, дажеЕго можно просто понимать как «поверхностное копирование», а не как «глубокое копирование»., легко избежать и добиться загрязнения через глобальный общий API, например, напрямую изменитьArray.prototype.pushповедение;


with() + new Function(code) + Proxy + iframe contex

Чтобы более безопасно решить описанную выше проблему выхода из глобального API окна прокси, вы можете взять окно iframe в качестве окна контекста среды песочницы;


iframe здесь не используется напрямую в качестве песочницы для выполнения кода подприложения, и подприложение по-прежнему выполняется вwith + new Function, этот iframe является просто созданным пустым iframe того же происхождения, его единственная цель - получить егоiframe.contentWindowОбъект передается дочернему приложению как окно;


Из-за строгой изоляции iframe все глобальные объекты не имеют ничего общего с внешним слоем(кроме родителя), так и внутри и снаружиArray Array.prototypeОни не совпадают, что равносильно перехвату окна предыдущей схемы.«Глубокое копирование», является относительно полным и элегантным решением для песочницы;


(Прокси-перехват документа/истории/локализации такой же, как и предыдущее решение)

// 简化伪代码示例
frame = document.body.appendChild(document.createElement('iframe',{
  src: 'about:blank',
  sandbox: "allow-scripts allow-same-origin allow-popups allow-presentation allow-top-navigation",
  style: 'display: none;',
}))

window = new Proxy(frame.contentWindow, { ... })
document = new Proxy(document, { ... })
...


sandbox = new Function(`
  return function ({ window, location, history, document }, code){
    with(window) {
      ${code}
    }
}`)


sandbox().call(window, { window, location, history, document }, code)

Realms

tc39 новая спецификация все еще в предложенииRealms, этап 2, может создавать полностью независимые глобальные объекты и глобальные области видимости, которые подходят для реализации песочниц (есть также некоторыеОбсуждение побега),

В настоящее время фреймворк микроинтерфейса не исследовался, и только Figma упомянула, что он используется для собственного подключаемого решения.(После упомянутого выше «микроматериала» в категорию «микрофронтенд» можно включить и плагины);


Изоляция CSS

В отличие от относительной зрелости изоляции JS, изоляция CSS совершенно незрела в отрасли, и в настоящее время она представляет собой небольшую проблему для большинства микроинтерфейсных сред;


Большинство из них скажут вам добавлять префиксы инженерным способом для предотвращения конфликтов, например, модули БЭМ/css/css в js/пользовательские префиксы и т.д.;

Но это не может решить ситуацию, когда разные приложения зависят от разных версий одной и той же UI-библиотеки;

И большинство исторических проектов также имеют много жестко запрограммированных className. Это трудно полностью реформировать;


Удаление при переключении приложений

Это то же самое, что и упомянутый выше [принцип монтирования/выгрузки] Snapshot для изоляции JS при переключении приложений, и проблема тоже та же, поэтому повторяться не буду;


Shadow DOM

Shadow DOMЗвучит как действительно эффективная песочница для изоляции CSS.При той же строгой изоляции DOM, что и у iframe, элементы внутри Shadow DOM никогда не будут влиять на элементы вне его;

и будь то<style>или<link rel="stylesheet">Сгенерированный css не влияет друг на друга внутри и снаружи;

(Источник изображения MDN)

Звучит очень хорошо, просто поставьте Shadow DOM вне каждого суб-приложения и все будет хорошо, а ссылка style/css, вставленная в шапку суб-приложения, будет перехватываться в этом Shadow DOM;

<html>
  ▶︎ <head>...</head>
  ▼ <body>
    ▼ <div id="main-app" >
      ...

      <!-- 子应用 A 对应的 shadow dom 容器 -->
      ▼ <div id="sub-app-a-container">
        ▼ #shadow-root (open)
          ▶︎ <style>...</style>
          ▶︎ <link rel="stylesheet">...</link>
          ▼ <div id="sub-app-a">
             ...
            </div>
        </div>
      </div>

    </body>
</html>

Но на самом деле, помимо совместимости, в браузерном Shadow DOM есть куча багов, а младшая версия react-dom не поддерживает события Shadow DOM, есть еще одна проблема:


всплывающая маска

Если быть точным: как быть с элементами, которые вставляются в document.body через JS в под-приложениях, таких как Tooltip/Popover/Modal?

Если они действительно вставлены в document.body, то Shadow DOM будет пропущен, и не будет CSS субприложения, и стили пропадут;

Если операция вставки захвачена документом песочницы JS, куда должны быть вставлены эти элементы Tooltip/Popover/Modal?

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

Решение для хака состоит в том, чтобы поместить элемент div Shadow DOM, соответствующий каждому подприложению, в конце документа.body Свойства позиционирования, размера и поля/отступа этого элемента div и document.body точно такие же, что эквивалентно покрывающий тело выше, а теги ссылок style/css, вставленные соответствующими суб-приложениями, полностью синхронизируются внутри,

Этот div Shadow DOM используется для переноса элементов, вставленных в document.body дочерним приложением.(Требуется сотрудничество с песочницей JS), таким образом, будь то Tooltip/Popover/Modal или элементы без фиксированного позиционирования, полученный css согласуется с подприложением, а позиция выравнивается с телом, что в принципе решает проблему;

<html>
  ▶︎ <head>...</head>
  ▼ <body>
    ▼ <div id="main-app" >
      ...

      <!-- 子应用 A 对应的 shadow dom 容器 -->
      ▼ <div id="sub-app-a-container">
        ▼ #shadow-root (open)
          ▶︎ <style>...</style>
          ▶︎ <link rel="stylesheet">...</link>
          ▼ <div id="sub-app-a">
             ...
            </div>
        </div>
      </div>

      <!-- 子应用 A 同步所有样式的 shadow dom 容器 -->
      ▼ <div id="sub-app-a-global-shadow">
        ▼ #shadow-root (open)
          ▶︎ <style>...</style>
          ▶︎ <link rel="stylesheet">...</link>
          ▼ <div id="modal">
             ...
            </div>
        </div>
    </body>
</html>

Но хак не идеален, но практика, основанная на синхронном CSS, может иметь проблемы, такие как сбой синхронизации, упущение и т. д.;

  • например правильно<style>Синхронизация внутри тега должна контролироваться все время, а синхронизация между двумя теневыми DOM должна быть взад и вперед, потому что новый может быть вставлен в любой из них.<style>теги или в одном из оригинальных<style>Модификации внутри тегов;
  • Другой пример — схема css в js, которая обычно используется для повышения производительности.CSSStyleSheet.insertRule() APIдля создания стилей, так что хотя на элементы могут влиять стили css, соответствующие<style>Содержимое метки полностью пусто, и ручная синхронизация на основе содержимого метки не может быть выполнена.Песочница JS должна взаимодействовать с перехватывающим API-интерфейсом insertRule для синхронизации;
  • И если место, куда суб-приложение вставляет dom через JS, не является document.body , а любым другим местом, в котором есть dom, его здесь также сложно захватить;

Технический долг!!

Ниже перечислены типичные технические долги, но процесс их устранения также можно рассматривать как часть процесса преобразования микроинтерфейса.

  • Перекрестная связь компонентов между модулями

    Модуль представляет внутренние компоненты/методы других модулей,

    Эти упомянутые элементы должны быть разделены на общедоступные компоненты/методы;

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


  • Общедоступные зависимые компоненты/методы не были полностью разделены и упакованы

    Общие общедоступные компоненты/публичные методы службы и т. д. требуют последующего рефакторинга и разделения


  • Преобразование режима маршрутизации URL-адресов не было выполнено (hash history => browser history)

    Aeolus уже запрашивал и планировал перейти с истории хеширования на историю браузера, но это еще не сделано.

    Если планируется преобразование, но преобразование микроинтерфейса было выполнено до этого, совместимость преобразования маршрутизации может быть затруднена;

    Различные контейнеры микроинтерфейса имеют разные уровни поддержки режимов маршрутизации, а также имеют различную поддержку того, могут ли приложения родитель-потомок использовать разные режимы;


  • Обновление React v17 для устранения проблем с Shadow DOM

    Изоляция CSS основного фреймворка имеет поддержку Shadow DOM, и React необходимо обновить до версии 17, чтобы исправить различные проблемы с Shadow DOM;

    А поскольку текущая версия umi и React управляется внутренним пакетом umi, по сути, это обновление обновляется вместе с umi, и с такими особенностями, как ленивая маршрутизация новой версии umi, тоже нужно разобраться.


  • жестко закодированное имя класса jsx, записанное в коде

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


  • Процессы Dev/CI/CD все еще перерабатываются (monorepo / dev preformance / ci tasks)

    Трансформация самого микрофронтенда также оказывает влияние на процесс Dev/CI/CD, поэтому лучше не делать и то, и другое одновременно;


Общее повторное использование зависимостей

Микрофронтенды не решают проблему повторного использования, само по себе «повторное использование зависимостей» — это не то, чем должен заниматься фреймворк микрофронтенда, а некоторые зависимости нельзя и не следует использовать повторно (например, выполнение кода будет иметь побочные эффекты на внутренние переменные/контекст самой зависимости) (некоторые фреймворки повторно используют и извлекают npm на уровне библиотеки, но это также вызовет проблемы с фрагментами пакетов);


Какой фреймворк использовать?

Технически можно использовать любой фреймворк, дизайн каждого фреймворка в основном декларирует несколько строк легковесных и неинвазивных методов доступа, поэтому стоимость доступа и стоимость замены очень малы, дело в том, что Aeolus должен завершить расщепление модулей. ;

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

Поэтому нам также нужно быть готовыми к тому, чтобы отвязаться и даже заменить фреймворк микро-фронтенда в любой момент трансформации.


В какой степени его нужно переделывать?

  • Внутренняя публика зависит от раскола раскола, отправки отправленного пакета
  • Соответствующий модуль полностью перемещается в другой репозиторий (или каталог монорепозитория, например, apps/ ), иВозможность начать разработку самостоятельно(Потому что его можно разработать и развернуть)
  • Остальное - упаковать и получить доступ согласно соответствующему рамочному документу.
  • Каковы руководящие планы для конкретного фактического процесса преобразования и проектирования переходной стадии?


Refs

В ходе всего процесса перечислены наиболее актуальные и ценные статьи, которые я прочитал.

источник

Techniques, strategies and recipes for building a modern web app with multiple teams using different


Обзор

[Рекомендация] — это общий обзор микроинтерфейсов, включая эволюцию дизайна, эволюцию технологий и т. д.


Webpack5 Module Federation

Никакой песочницы, только упаковка и повторное использование кода


Qiankun

qiankun — это контейнер среды выполнения, загрузчик, но оставшиеся без ответа инженерные и платформенные вопросы


Magic microservices

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

Puzzle

Bit.dev

Alfa


изоляция песочницы

Figma

В блоге Figma подробно рассказывается, как развивалась изоляция песочницы их системы плагинов; Figma используетRealmsи iframe того же происхождения + iframe нулевого происхождения для создания контекста для кода в песочнице.


Добро пожаловать в "Byte Front End ByteFE" Контактный адрес электронной почты для доставки резюме "tech@bytedance.com"

Категории