组件库介绍
软件组件：封装好的可复用的程序“零部件”
组件库：一系列UI组件的合集
- 一致性
- 效率
- 协同
组件库的使用
组件库快速上手
引入组件库
暗黑模式
局部使用：本质上是控制暗色颜色变量的挂载位置，提高我们所需要的颜色变量的优先级
主题定制
国际化（语言国际化，视图国际化）
全局配置组件默认行为
常见业务问题
自定义组件
业务组件库基础搭建
关键点
- 架构设计
- 技术方案
- 对外文档
架构设计
- 单包架构
一个代码仓库里所有组件打包成一个整体，发布出去一个npm包
优点：
- 公共代码易复用
- 展示更聚合，便于维护
- 引入一个包即可使用全部组件 缺点：
- 修改一个组件需要更新整个库
- 需要考虑按需加载
- 多包架构
一个代码仓库包含多个组件代码，会发布出去多个npm包
优点：
- 单独发包，升级灵活
- 在同一个仓库下，便于代码管理
- 使用者无需考虑按需加载 缺点：
- 组件间相互依赖，需要通过npm引入
- 组件使用时需要安装每一个用到的npm包
技术方案
开发环境 样式方案 产物构建 质量保障
对外文档
文档部署 组件API提取 版本日志生成
业务组件开发
项目组织：
- 语义化命名：组件的命名应当具有语义，并且避免与基础组件冲突
- 包名和组件名一致：NPM包名应当尽量与组件名保持一致，包含明确的场景使用信息
- 单独维护类型文件：推荐将需要对外导出的TS类型维护在单独的interface.ts中，并将其在index.ts中导出
组件设计：
- 组件属性定义：在为组件定义接口类型时，应继承原生DOM（或基础组件）属性，避免属性遗漏或重复声明
- 类名前缀统一：组件使用特殊且统一的类名前缀，尽量降低与用户类名冲突的可能性
- 避免行内样式：确保外部可以通过类名进行样式覆盖
- 避免在JS中耦合CSS：应尽量保证逻辑与样式的分离，确保用户可以分别引入JS和CSS，避免由于构建环境的不同导致的用户编译失败的问题
- 注意样式的按需加载：在基于基础组件库如Arco进行业务组件的逻辑封装时，应注意按需引入所依赖的Arco基础组件的样式文件
示例实践
Guide Tip
