По фэншуй
Микро-интерфейс приносит много преимуществ и проблем. Как мы можем получить доступ к микроинтерфейсу на основе текущего стека технологий? Какие общие функции необходимы? Как мы можем разрешить механизм плагинов? В этой статье описывается решение для микроинтерфейсного доступа и детали реализации.
Предисловие
Концепция микроинтерфейса несколько раз попадала в заголовки новостей в Китае, и проблемы, которые она решает, очевидны. Однако эти проблемы, упомянутые в микроинтерфейсе, имеют большое значение, когда наша команда поддерживает проекты.
«Микрофронтенд — это некая структура с некоторой технологией».
Это утверждение показывает ограничения, которые можно принять за мнение непрофессионала, пытающегося идти в ногу со временем. В моих проектах стек технологий массового стока и страницы работали онлайн. Любая итерация и обновление должны быть осторожными и безопасными. Микрофронтенд в определенной степени дает преимущества пользовательского опыта и технического обслуживания, но его ценность для бизнеса не может быть определена количественно. Для реализации этой технологии необходимы руководящие принципы. Ожидается, что он будет соблюдать стандартные технологические стеки и изолировать основные элементы контролируемых диапазонов влияния. Затем рассматривается реализация решения для микроинтерфейса.
Основываясь на приведенной выше информации, вам необходимо полностью понять техническое решение и пропорции на текущем участке преобразования для внедрения этой новой технологии. Вы также должны знать о различиях в возможностях, предоставляемых существующими зрелыми платформами микроинтерфейса. Следует избегать механического применения.
Задний план
Проекты, поддерживаемые моей командой, управляются фоном ПК через рабочие станции. Это может привести к проблемам, если они находятся с разными партнерами в разных странах или в разных часовых поясах.
Разработчики, создающие новую страницу, могут принадлежать к разным командам. Таким образом, трудно обеспечить унификацию стилей на нескольких страницах управления, спецификаций дизайна, компонентов и поведения взаимодействия при выполнении существующих требований.
Когда бизнес переносится на другую рабочую станцию, по-прежнему требуется логическая согласованность с различиями в панелях навигации и темах. Существующие стандартные решения используют Java для прямого HTML с использованием шаблонов. После нескольких поколений итераций страницы, сгенерированные различными технологическими стеками, уже существуют в разных системах.
Хотя страницы были реализованы React, ни одна из них не была представлена в виде обычных компонентов React, поскольку прежние разработчики были очень способными. Например:
- Большинство страниц настраиваются и генерируются JSON с компонентами потребления.
- Некоторые страницы настраиваются и генерируются JSON другой команды с компонентами потребления, что полностью отличается от JSON выше.
- Другие страницы загружаются через JS Bundle, предоставляемый платформой публикации страниц.
У разработчиков нет другого выбора, кроме как разработать надежное решение для реализации, когда они сталкиваются с технической подготовкой.
Решение и блок-схема
Во-первых, проанализируйте общие функции, которые необходимо загрузить на все страницы сайта:
На рисунке выше показаны упрощенные общие функции. Краткие введения перечислены ниже:
- Загрузчик макетов: загрузка элементов навигации для разных рабочих станций.
- Загрузчик DADA: загрузка страниц, настроенных с помощью JSON.
- Загрузчик исходного кода: загрузить пакет JS
- Micro Loader: процесс загрузки микроинтерфейса.
- Отчет журнала: журналы отслеживания.
- Часовой пояс: переключение часовых поясов.
- i18n: переключение языков
- Guider: единый контроль над руководствами пользователя.
Дополнительные возможности расширения на страницах перечислены ниже:
- Мониторинг безопасности
- Управление трафиком
- Управление всплывающим окном
- Анкеты
- QA-робот
После грубой классификации общие процессы загрузки страницы перечислены ниже:
Детали реализации
Основываясь на предыдущей идее загрузки, сначала сходится путь загрузки страницы. Это гарантирует, что записи загрузки всех страниц находятся под единым загрузчиком. Затем систематически обрабатываются жизненные циклы загрузки всех страниц.
Во время конвергенции также необходимо держать плагин основного пути загрузки открытым, чтобы поддерживать различные возможности расширения и доступ к технологическому стеку рендеринга в любое время.
1. Механизм подключаемых модулей
По основному пути загрузчик загружает конфигурации для обработки, а конфигурации предоставляют контекст. Затем конфигурации передаются плагину для использования. Процесс показан в списке ниже:
Возьмем в качестве примера независимое подприложение JS Bundle:
<div id="root"></ div> <script src="https://cdn.address/schema-resolver/index.js"></ script> <script src="https://cdn.address/schema-resolver/plugin/layout.js"></ script> <script src="https://cdn.address/schema-resolver/plugin/source-code.js"></ script> <script src="https://cdn.address/schema-resolver/plugin/micro-loader.js"></ script> <script src="https://cdn.address/schema-resolver/plugin/i18n.js"></ script><script> SchemaResolver.render( { micro: true, host: "dev.address", hfType: "layout1", externals: ["//{HOST}/theme1/index.css"], // host is cdn prefix, the resource maybe in different env & country resource: { js: "/index.js", css: "/index.css", }, }, { container: document.querySelector("#root") } ); </script>
С помощью предыдущего подключаемого модуля можно включать и использовать различные конфигурации.
Внедрение плагина макета использует поле hfType, а затем загружает соответствующий ресурс макета, чтобы предоставить контейнер для следующего этапа.
В соответствии с конфигурацией, если микроинтерфейс включен на текущей странице, Micro Loader использует предоставленный контейнер и создает песочницу. В данном случае он основан на цянькунь. Затем Micro Loader предоставляет контейнер.
Наконец, Container передается плагину SourceCode для загрузки, запуска и рендеринга пакета. Разработчики могут передать его другому подключаемому модулю для использования контейнера в соответствии с другими конфигурациями с другим протоколом рендеринга или стеком технологий.
В этом процессе подключаемый модуль каждой ссылки является независимым и подключаемым. Например, без загрузки плагина макета поле hfType не может быть использовано, а логика плагина макета не может быть внедрена в метод getContainer. Затем Контейнер визуализируется непосредственно через самый внешний слой без представления соответствующего меню. Без Micro Plugin логика микроинтерфейса не внедряется, песочница не создается, а процесс рендеринга страницы продолжает работать в обычном режиме.
2. Безопасная миграция
Для наших проектов универсальное решение невозможно. Для существующих стоковых страниц требуется полный анализ текущего стека стоковых технологий:
Для приведенных выше стандартных страниц их следует развертывать онлайн слева направо партиями на уровне страницы. Что касается левой части, некоторые проекты нуждаются в модификации перед развертыванием для онлайн-доступа.
Это миграционное тестирование необходимо для разработки автоматизированного сквозного (E2E) процесса тестирования и сортировки реестра микроинтерфейса посредством пакетной миграции. Благодаря этим двум типам управления процессами и объемами контент, поставляемый в текущем решении, полностью управляем. Остальные части представляют собой повторяющиеся задачи с количественным охватом.
3. Форма микро-фронтенда
В соответствии с приведенным выше решением ожидаемые формы микроинтерфейса перечислены ниже:
- Каждая страница, которая включает микроинтерфейс, может быть основным приложением.
- Микро-интерфейс — это дополнительный плагин. Любые бизнес-исключения, возникающие из-за микроинтерфейса, могут быть закрыты в любое время.
- Переключение между маршрутизаторами страниц микроинтерфейса может привести к частичному обновлению, в то время как страницы реестров без микроинтерфейса перенаправляются напрямую. По мере увеличения охвата страниц микроинтерфейса частичное обновление также постепенно увеличивается.
- Используйте различные подключаемые модули расширения, чтобы загружать стандартные страницы различных типов технологических стеков и преобразовывать их в соответствующие подприложения.
Пути регистрации и вызовов в SchemaResolver перечислены ниже:
Резюме
Выдающиеся мысли, лежащие в основе микрофронтенда, являются ключом к решению конкретных задач. Эта технология приносит пользу только тогда, когда решаются конкретные бизнес-задачи. Не будьте слишком целеустремленными. В настоящее время SchemaResolver предоставляет различные возможности открытия с учетом ролей:
- Для администраторов платформ он предоставляет возможность подключаемого модуля для обеспечения глобальной масштабируемости.
- Для разработчиков страниц он предоставляет стандартные пути решения доступа, доступ к множеству технологических стеков и другие возможности, включая микроинтерфейс, многоязычность, отслеживание, меню и загрузку тем. Он также разделяет общие возможности разных систем, что позволяет быстро перенести конкретную бизнес-логику на другие платформы.
- Для сторонних пользователей он предоставляет унифицированные критерии доступа через стеки технологий изоляции микроинтерфейса и стилей изолированных подприложений, не изучая системные меню или методы доступа к темам. Он мигрирует на соответствующие платформы, чтобы просматривать состояние страниц сайта в глобальном масштабе с помощью единого управления системой страниц.
