В поиске можно найти много статей о проектировании библиотек компонентов, но большинство из них относятся к UI или визуальному уровню спецификации, однако с развитием и итерацией фронтенд-технологии фронтенд-технология перестала занимать важное место. стиль реализации, определенный в прошлом Так просто, эта статья расскажет о дизайне библиотеки компонентов с точки зрения технического студента и на что еще можно обратить внимание, кроме стиля.
Сценарное мышление приложения библиотеки компонентов
Суть компонента заключается в повторном использовании и абстрагировании кода для повышения эффективности разработки.Можно сказать, что душа компонента заключается в деконструкции бизнес-сценариев, таких как абстракция различных элементов управления, абстракция события, абстракция стилей и т. д., а также реализовывать бизнес-требования посредством комбинирования и настройки. В определенной степени библиотека компонентов подобна набору инструментов, предоставляющему различные части для разработки бизнес-сценариев, и то, как спроектировать эти части, требует знание сценариев применения, глубокое понимание и размышления.
Например, библиотеки компонентов C-стороны должны больше думать о пользовательском интерфейсе, производительности и совместимости с браузерами, а также стремиться к более экстремальному интерактивному и визуальному опыту.В то же время пользовательский интерфейс приложений C-стороны часто переключается в зависимости от темы. фестивалей и мероприятий Дизайн библиотеки компонентов также должен учитывать персонализированное пространство расширения.
Библиотека компонентов B-стороны больше ориентирована на простоту использования и возможность повторного использования, обеспечивая высокую скорость итерации и эффективное использование инструментальных приложений среднего уровня или B-стороны. В то же время приложение на стороне B будет включать в себя множество операций отображения и добавления, удаления, модификации и запроса данных, что требует от библиотеки компонентов более четкого разделения обязанностей и более богатого выбора в интерактивных элементах управления.
В дополнение к различным бизнес-сценариям приложения также может быть диверсификация сценариев платформы, например, можно ли повторно использовать один и тот же набор библиотек компонентов в H5 и апплетах. Все это необходимо учитывать разработчикам библиотек компонентов в начале планирования.
Анализ текущей библиотеки основных компонентов
Первая категория реализована на основе экологии нескольких основных фронтенд-фреймворков, у них сформировались свои стили и спецификации в дизайне, а также есть свои осадки, такие как element на основе экологии Vue, antD на базе react и т.д. Их преимущество в том, что они разработаны очень зрело и могут в основном охватывать большинство бизнес-сценариев, а недостаток в том, что стоимость межфреймовой миграции библиотек компонентов высока.
Существует также тип библиотеки компонентов, предназначенный для перекрестных требований. Обычно нижний уровень опирается на набор кросс-платформенных сред разработки, таких как taro Jingdong, mpVue Meituan, Rax Taobao и т. д. Их основная идея также заключается в том, чтобы написать один запуск в любом месте.С точки зрения реализации, этот тип библиотеки компонентов в основном использует основу, предоставляемую платформой.Реализуйте как можно больше, чтобы сгладить различия каждой платформы, чтобы пользователи могли реализовать бизнес нескольких платформ на основе набора спецификаций разработки. Преимущество этого типа компонента заключается в том, что он может снизить затраты на кросс-платформенное обучение для разработчиков.Недостатком является то, что богатство библиотеки компонентов по-прежнему отсутствует, а сценарии, которые можно охватить, также ограничены.
В дополнение к двум вышеупомянутым категориям, omi от Tencent использует характеристики веб-компаний для достижения кросс-энда и кросс-фреймворка, что можно рассматривать как попытку интерфейсного фреймворка следующего поколения.
Планирование библиотеки компонентов
Процесс проектирования библиотеки компонентов на самом деле очень похож на процесс проектирования продукта: предварительное исследование сцены, анализ конкурентного продукта, сортировка спроса, пользовательский опыт (это следует называть опытом разработки) и непрерывные итерации проб и ошибок. .
Основываясь на некоторых из вышеизложенных размышлений и анализа, я попытаюсь спланировать библиотеку компонентов следующим образом:
Требования к компонентам:
-
Связующий слой компонентов --> Осознайте связь между компонентами и реальным бизнесом.
-
Уровень прокси компонента --> гибкие вызовы и частичные обновления внутри компонентов могут быть реализованы на основе прокси.
-
Уровень взаимодействия компонентов --> абстрактные функции, основанные на событиях взаимодействия в соответствии с бизнес-сценариями, и внедрять их через декораторы.
-
Уровень расширения компонента --> реализовать клонирование, наследование и расширение между компонентами.
-
Библиотека компонентов cli --> облегчает итерацию и проектирование компонентов
-
Производительность --> добиться минимальной детализации повторного рендеринга
Библиотека компонентов решает болевые точки
- Неудобно наследовать и расширять за пределами функционального компонента
- Реализуйте локальные обновления при взаимодействии компонентов и вызывающих объектов для повышения производительности.
- Сокращение затрат на миграцию фреймов благодаря клеевому слою и интерфейсному соединению фреймов.
- Инкапсулирует управляемое событиями управление состоянием, а также может быть расширено с помощью компонента состояния.
Компонент внутренней системы:
-
стиль
-
мероприятие
-
условие
-
наследовать
Выбор архитектуры библиотеки компонентов (предварительно, может быть скорректировано позже)
Основанный на rax в сочетании с монорепозиторием, одноранговым депонированием и разработкой компонентов полиморфного протокола, он может быть введен по запросу, обеспечить унифицированный интерфейс уровня бизнес-вызовов в сценариях между концами и максимизировать характеристики каждого конца.
Возможности библиотеки компонентов (предварительно, позже могут быть изменены):
- Частичное обновление и межуровневые вызовы
Modal.proxy.visible = true;
Modal.show(config)
-
расширенное наследование
//克隆 const Modal2 = Modal.clone();//扩展 const Modal2 = genModal({ methods: { cancel() { console.log('%c rewrite the cancel','color:#299865',this); this.visible = false; } } });//批量扩展 import {factoryAuto} from 'component' const {Button, Modal} = factoryAuto(pubConfig);//继承 const Button2 = genButton(Button1.proxy, newFeature) -
Облегченные компоненты состояния
<Button
x-for={(item, key) in statusList}
type="+success"
onClick={_ => trySingle(item)} >
wait{key}
</Button>
function trySingle (item) {
performance.watch()
item.choosed = !item.choosed
if (item.choosed) {
return new Status('pending...', { backgroundColor: 'green' })
} else {
return new Status(null)
}
}
- Внедрение декоратора
@addTransition('visible')
class BaseMix extends Base {}
- Компоненты области действия (локальный рендеринг)
<Button scope={item}
x-for={(item, key) in scopeList}
type="+success"
onClick={_ => {tryScope(item)}} >
wait{key}
</Button>
function tryScope(item) {
performance.watch();
item.choosed = !item.choosed;
}
- Декораторы событий (загрузка, блокировка и т.д.)
@addLoading
class EventCtxMix extends EventCtxBase {}
function Okfunc() {
return new Promise((resolve, reject) => {
//封装了防重锁和loading效果
setTimeout(() => {
resolve()
}, 1600)
})
}
Будущие перспективы библиотеки компонентов
Одной из характеристик интерфейсных технологий является то, что они быстро меняются.В дополнение к возможностям компонентов, предоставляемым основными фреймворками, концепция веб-компонентов постепенно становится горячей темой в последние годы. Кроме того, с появлением реактивных хуков также последовала эра функциональных компонентов.По сравнению с классовыми компонентами функциональные компоненты, основанные на хуках, более гибки по дизайну, но имеют относительно плохую внешнюю масштабируемость.Исходя из этого соображения, I A здравый смысл Идея состоит в том, чтобы инкапсулировать интерфейс логического слоя и слоя стиля компонента на верхнем уровне фреймворка и использовать компонент только для завершения рендеринга слоя представления через связующий слой и соединение компонентов, тем самым нарушая размерную стену. между библиотекой компонентов и фреймворком, ядром библиотеки компонентов. Части могут быть перенесены в другие фреймворки или даже веб-компоненты, просто перекодировав связующий слой. Конечно, эта идея еще нуждается во многих практических основаниях, прежде чем она, наконец, воплотится в жизнь.