Дизайнерское мышление и цели

резюме

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

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

PS:

Это сериал...

Модуль здесь относится к модулю бизнес-функции, а не к модулю в категории js. Для удобства различия модули в категории js будут называться jsModule.

Это мемуары реального сценария, поэтому 1. могут отсутствовать детали 2. это не минимальная реализация цели, может быть немного сложновато

Диаграмма архитектуры

Где трудность

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

Автономное развертывание означает:

1. Код должен быть упакован отдельно
2. Код размещен на разных серверах, соответствующих разным доменным именам.
3. Разные бизнес-модули могут получать доступ к разным серверным службам.

Это приносит некоторые проблемы:

1. Влияние на существующие процессы НИОКР

один разnpm run devВесь код будет упакован, webpack или другой бандлер решит проблему разделения и загрузки кода. Теперь вам нужно: упаковать код платформы и модуля отдельно, запустить службу ресурсов платформы и службу ресурсов модуля соответственно, а затем загрузить код модуля и выполнить его самостоятельно.

2. Изменения в том, как работает управление Router и Vuex

Модули пост-загружаются и асинхронны.Модули должны отвечать за собственную маршрутизацию и управление состоянием.Для платформы это непредсказуемо и определяется заранее,поэтому Router и Vuex нужно менять на динамическую инъекцию,но к счастью,они все поддерживать эту функцию

3. Отдельно упакованный код, если инструмент упаковки не настроен должным образом, это вызовет ошибки ссылки на код при запуске.

Инструмент упаковки, используемый в проекте, — это webpack, который регистрирует глобальную переменную (webpackJsonp по умолчанию) и управляет jsModule в массиве. Если вы загрузите другой фрагмент кода, упакованный таким же образом, jsModule, управляемый этими двумя, запутается, потому что ссылка на jsModule реализована в виде индексации массива.

4. Модуль управления ресурсами

После того, как модуль упакован, могут быть сгенерированы js, css и другие статические файлы ресурсов. модуль не будет перечисляться вручную. Поэтому мне нужен инструмент для упаковки, чтобы вывести список ресурсов после упаковки, но плагин webpack очень хорош, не беспокойтесь об этом.

5. Загрузка ресурсов модуля

Рассмотрим сценарий межмодульных зависимостей: если A зависит от B, как узнать, что B был загружен? Рассмотрим другой сценарий, модули C и D, запрос на загрузку одних и тех же ресурсов одновременно, как управлять? Поэтому мне нужно знать, что это за модуль, если он полностью загружен, а также нужен отдельный загрузчик ресурсов, чтобы избежать повторных запросов ресурсов.

6. Конфликты модулей в среде разработки

Рассмотрим такой сценарий: система А (платформа) имеет встроенный модуль Б (ресурсы Б указывают на адрес тестовой или производственной среды) Как указать ресурсы модуля Б на среду разработки во время разработки? (В идеале рассчитывайте на чистую платформу, но на самом деле всегда будут сюрпризы)

7. Функциональное тестирование модулей в нескольких средах

Запуск функции должен пройти через: среда разработки> тестовая среда> предварительная среда> производственная среда, Каждая платформа и модуль имеют свои соответствующие среды. В вышеперечисленных разных процессах, за исключением разных доменных имен, нет никакой разницы между самим кодом и средой его выполнения.Как сделать так, чтобы платформа тестовой среды загружала ресурсы модуля тестовой среды? Производственная среда загружена производством?

8. междоменная проблема

Это также самая неприятная проблема для решения.Запрос модуля на самом деле состоит из двух частей: ресурсы модуля (js/css и т. д.) и ресурсы данных (запрос ajax). Обычно разные модули соответствуют разным бэкэнд-сервисам (b.com). Когда модуль интегрируется в платформу для запуска, на самом деле не сам модуль делает запрос, а платформа (a.com). Конечно, мы можем перейти к тому же прокси-серверу платформы или попросить сервер модулей доверять запросу от источника платформы. Во-вторых, с точки зрения разработки в принципе запрещена любая форма жесткого кодирования доменных имен в коде, а в модуле нет записи доменных имен, так откуда платформа должна знать доменное имя ресурса данных запрос модуля?

9. Изоляция модуля

Например, платформа выбирает использование axios для предоставления услуг http.Если модуль A ссылается на axios и случайно предоставляет глобальную конфигурацию, например, добавляя baseUrl, другие модули могут быть уничтожены. . . Я не хочу, чтобы каждый модуль вводил свой собственный http-сервис, что очень запутывает и принесет много кода с дублирующими функциями, я также не хочу использовать iframes, которые будут тратить ресурсы и производительность, а также принесут некоторые ямки в макете. Я сделал частичную изоляцию, чтобы избежать непреднамеренного AOE.

10. другие вопросы

На самом деле, есть и некоторые другие детали, такие какnpm run devПосле функции автоматического открытия браузера мне нужно запустить службу платформы и службу модуля соответственно.Это два процесса.Мне нужно убедиться, что компиляция кода платформы завершена, так что интер- коммуникация процесса стала необходимостью. Другой пример: команда глобальной компиляции была удалена, горячая перезагрузка также заставила меня наступить на яму и так далее. . .

моя цель

1. Не меняйте привычки исследований и разработок

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

2. При разработке модулей вам не нужно заботиться о деталях, например о том, как писать междоменный код.

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

3. Реализовать модульное и распределенное развертывание переднего плана в соответствии с указанными выше требованиями.

конкретные вопросы

1. Трансформация команды компиляции, поддержка платформы, упаковка кода модуля, что также является необходимым шагом для решения вышеуказанных проблем.
2. Интегрированная функциональность шаблонов команды компиляции (шаблоны для платформ и модулей)
3. Инструмент управления модулями (клиентский запуск)
4. Добавьте правила eslint, чтобы запретить неправильные межмодульные ссылки на код.
5. Отдельный http-сервис, фиктивный сервис
6. Документация

Следующий. . .

1. Дизайн интерфейса модуля
2. Реализация менеджера модулей
3. Определение и реализация зависимостей модулей
4. Модуль, реализация коммуникационной функции платформы
5. управление маршрутом
6. государственное управление
7. Обработка запросов между источниками
8. Модификация инструмента компиляции
9. Архитектура режима разработки
10. разработка и тестирование

Указанный выше порядок вывода или структура могут быть скорректированы

ФЛАГ: относитесь к себе в будущем с самодисциплиной