Видел несколько дней назадGeek Time Библиотека внешних компонентов для обмена видео, хорошо сказано, вот резюме
Для студентов, изучающих интерфейс, библиотека бизнес-компонентов определенно не является чем-то незнакомым.
- Проблема межпроектного повторного использования бизнес-компонентов
- В то же время унифицированная реализация кода и унифицированное качество кода
Тем самым повышая эффективность развития бизнеса. Но я обнаружил, что когда я начал исследовать технические решения после четких требований, многие студенты не знали, какие технические моменты исследовать, как найти решение в конкретном направлении, какие кейсы попробовать после нахождения решения и как эти решения реализовать. , объединены вместе и так далее.
На самом деле, вам не нужно думать об этом так сложно, вам нужно только следовать ключевым моментам следующих трех технических реализаций.
- Первый шаг: «создайте основу» — общий архитектурный проект библиотеки бизнес-компонентов.
- Второй шаг: «построить основную структуру» — базовый технический проект библиотеки бизнес-компонентов.
- Шаг 3: «Покраска фасада» — Служба внешней документации для библиотеки бизнес-компонентов
Вы должны думать, что эти три пункта все еще слишком макроскопичны и трудны для понимания, поэтому далее я объясню, что это за три ключевых момента. Вы можете обратиться к этим ключевым моментам для проведения соответствующих технических исследований.
1. Общая архитектура библиотеки бизнес-компонентов
Для общего проектирования архитектуры библиотеки бизнес-компонентовОсновная проблема заключается в том, как организовать и управлять кодом библиотеки бизнес-компонентов..
Во-первых, мы создаем репозиторий кода. Промышленность обычно поддерживает один и тот же тип библиотеки компонентов в виде единого хранилища и разрабатывает компоненты в виде пакетов NPM.Смысл здесь в том, ** Вам следует подумать о том, чтобы упаковать все компоненты в большой пакет NPM или разделить Это небольшой независимый пакет NPM. **Не недооценивайте эту проблему, эти два варианта сделают структуру каталогов хранилища совершенно другой, что в дальнейшем повлияет на технический дизайн разработки, построения, выпуска и внедрения следующих компонентов.
Единая пакетная архитектура
что
Если вы решите рассматривать все компоненты как единое целое, упакуйте их вместе для распространения. это называетсяЕдиная пакетная архитектура. Единый склад, единый пакет, единое обслуживание и единое управление. такие как Антд
преимущество
Его самым большим преимуществом является то, что он может получать ссылки между компонентами и ссылки на общий код через относительные пути.
недостаток
Недостатком является то, что компоненты полностью соединены друг с другом и должны быть упакованы как единое целое. Даже изменение очень небольшой функции компонента требует выпуска обновления для всего пакета.
Antd, например, управляется как единый пакет. Если вы решите использовать архитектуру с одним пакетом, вы должны предоставить возможность загрузки по запросу, чтобы снизить стоимость пользователей.Вы можете рассмотреть возможность поддержки функции встряхивания дерева модулей ES, чтобы получить возможность загрузки по запросу. Конечно, вы также можете выбрать другое решение, называемое «многопакетной архитектурой».
Многопакетная архитектура
что
Каждый компонент независим друг от друга, упакован и выпущен отдельно, несколько пакетов на одном складе, единое обслуживание и отдельное управление.
.
├── lerna.json
├── package.json
└── packages/ # 这里将存放所有子 repo 目录
├── project_1/ # 组件1的包
│ ├── index.js
│ ├── node_modules/
│ └── package.json
├── project_2/ # 组件2的包
│ ├── index.js
│ ├── node_module/
│ └── package.json
...
преимущество
Его самым большим преимуществом является то, что он гибок в выпуске компонентов и, естественно, поддерживает использование по требованию.
недостаток
Недостатком является физическая изоляция компонентов от компонента к компоненту. Для таких сценариев, как взаимозависимость, общая абстракция кода и т. д., это может быть достигнуто только с помощью ссылок на пакеты NPM.
--
Унифицированный выпуск разработки в этих сценариях относительно неудобен, а многопакетная архитектура в отрасли называется «монорепо».
В области внешнего интерфейса мы обычно используем стороннюю библиотеку Lerna для поддержки такой архитектуры.Lerna сделала некоторые специальные оптимизации для сценариев с зависимостями между пакетами.В режиме разработки он будет передавать все пакеты с зависимостями через мягкую цепочку , Соединённые вместе, это очень удобно для локальной разработки и совместной отладки. Так что это требует, чтобы вы ясно мыслили,
- Являются ли компоненты между библиотеками компонентов взаимозависимыми, и если да, то может ли Lerna обработать их.
- «Однопакетная архитектура» также может быть выбрана, если компоненты зависят от специальной проверки.
2. Базовые технические возможности библиотеки бизнес-компонентов
После того, как вы определили общую архитектуру, вы можете приступить к реализации конкретных функциональных точек. Библиотека бизнес-компонентов требует, чтобы общая структура обеспечивала пять основных технических возможностей.
1. Наращивание потенциала
Это требует от нас предоставить возможность сборки продуктов.Здесь много вариантов, вы можете выбрать Webpack, Rollup Gup Grunt..... Rollup рекомендуется для сборки библиотек компонентов, а Webpack рекомендуется для сборки проектов.Здесь нам нужно обратите особое внимание на требования к формату продуктов, так как мы обычно используем форматы cjs, esm, umd.
- Например, если ваш компонент предполагает поддержку среды узла, например поддержку ssr, вам необходимо упаковать код в формате cjs.
- Если ваш компонент предполагает поддержку
<script >Ссылка на тег, вам нужно упаковать код в формате umd
Затем вам нужно настроить его в соответствующем инструменте сборки
Кроме того, есть несколько моментов, которые очень легко упустить, например:
- Совпадает ли конфигурация библиотеки компонентов Bable с конфигурацией Babel в проекте.
- Упакован ли пакет зависимостей в продукт или использует пакет зависимостей в проекте. Такие как: lodash, момент...
- Запакован ли стиль зависимого пакета в продукт и конфигурация полифилла (подробное описание открою здесь позже 😂)
2. Документация
Вам необходимо предоставить службу документов, которая может работать в режиме реального времени. Включая поддержку отображения статического контента и возможность просмотра реализации и работы исходного кода, в этом отношении существует множество отличных библиотек с открытым исходным кодом, таких какStoryBook&Styleguidist,Docz
Тут нужно обратить внимание на типичное неправильное поведение, то есть при исследовании исследовать только какие-то базовые функции и начинать делать выбор, которым легко копать ямы для спины, и нужно рассмотреть как можно больше ситуаций. Например
- Могут ли поддерживаться примеры кода с внутренними состояниями, такие как компоненты всплывающего окна, вам нужно переключить состояние отображения в примере
- Если вы планируете размещать мобильные компоненты, может ли поддерживаться эффект отображения?Вообще говоря, мобильные примеры нужно запускать на отдельной странице в виде iframe. Например, мобильный компонент, позиционируемый fiexd, является очень распространенной формой.Если это не iframe, элемент, позиционируемый fiexd, будет охватывать всю веб-страницу документа.
- Будет ли пакет зависимостей веб-сайта документации конфликтовать с пакетом зависимостей компонента? Предполагая, что две зависимые версии пакетов несовместимы, необходимо реализовать изоляцию стиля.
3. Местные службы
В отрасли обычно используются службы обработки документов в качестве локальных служб. Запустите локальную службу документов, чтобы увидеть результат операции. Здесь вам нужно обратить внимание на то, хорош ли опыт использования местных сервисов, таких как
- Скажите, что нет горячего обновления
- Достаточно ли высока скорость компиляции?
Также есть особый момент, иногда мы будем выполнять сборку локально. Созданный продукт и локально сгенерированный временный продукт должны иметь возможность быть изолированными друг от друга и не влиять друг на друга.
4. Обеспечение качества
С одной стороны, нам нужно предоставить унифицированную функцию eslint. Гарантированный стиль реализации и качество фундамента
С другой стороны, вы можете рассмотреть возможность внедрения модульного тестирования.В отрасли также есть очень хорошие фреймворки для модульного тестирования, такие как Jest и Karma.
5. Статистика
Необходимо подсчитать, в скольких проектах используется компонент и где он используется. Основная цель этой возможности — предоставить статистику и понять справочное влияние изменений.
ты можешь пройти
-
Добавьте закопанные точки в компонент для статистики. Для решения скрытой точки будет установлен предел своевременности.В течение периода времени, который вы считаете, если функция компонента не используется пользователем, она не будет учитываться.
-
Регулярно сканируйте и анализируйте все зависимости репозитория кода для получения статистики. Вы можете искать дерево зависимостей ключевых слов
В дополнение к возможности апеллировать к нескольким пунктам, библиотека бизнес-компонентов также требует общей структуры для обеспечения унифицированных возможностей создания скинов, возможности быстрого создания новых стандартных компонентов, возможности пакетной обработки компонентов, предустановленного именования и т. д.
Такие команды, как отправка пакетов, команды самотестирования, автоматическое создание журнала изменений и так далее.
3. Внешний документооборот библиотеки бизнес-компонентов
Когда основные возможности готовы, наконец обращаем внимание на внешний вывод. Это наш сайт документации. Здесь нам нужно построить его как онлайн-сервис, здесь нужно учитывать, что такое конкретная архитектура
- Могут быть чисто статические ресурсы
- Как построить назначенный CI
Суммировать
Выше приведены несколько ключевых моментов технической реализации библиотеки бизнес-компонентов, а ниже приведено краткое изложение интеллект-карты.