组件库
01组件库的介绍
组件库：一系列UI组件的集合
工业品组件:具有标准接口和某种功能且可复用的标准零部件；
软件组件：封装好的可复用的程序“零部件”
前端UI组件：“按钮”、“输入框”、“下拉框”都是组件，组件和组件组合就变成了一个更复杂的组件。
社区组件库：Arco.design(字节)、material UI（谷歌）、Ant Design(阿里)、TDesign（腾讯）、bootsrap等
什么是组件库：需要组件一致性、高效率、协同
02、组件库的使用（均以Arco.design为例）
02_1、快速上手
引入组件库
需要同时安装react>=16.8和react-dom>=16.8
npm i @arco-design/web-react
基础使用
import React from "react";
import ReactDom from "react-dom"
import{Buttom} from"@arco-design/web-react";
import "@arco-design/web-react/dist/css/arco.css"
React DOM.render{
<Button type"primary">Hello Arco</Button>
document.querySelector("#root")
};
安装按需加载插件（运行时js运行空间太大）
<yarn add babel-plugin-import -D
通过CDN使用
02_2、主题定制
- 通过CSS进行样式覆盖
- 修改less变量
02_3、黑暗模式
在不同模式下改变页面的颜色，但是尺寸距离没有变
局部黑暗模式
核心思路：本质上是控制暗色颜色变量的挂载位置，提高我们所需要的颜色变量的优先级
02_4、国际化
语言国际化
当语言未支持时
RTL试图（一些地方的人习惯此视角）
如何开启
import {ConfigProvider} from '@arco'
import arEG from '@arco-design/web-react'
export function App(){
return {
<ConfigProvider locale ={arGE} retl>//rel={true}即可开启
{
//...
}</ConfigProvider>
};
}
02_5、ConfigProvider-全局配置组件
修改组件默认的属性值，从而改变组件的默认表现
使用方式：通过ConfigProviderder的componentConfig属性，传入定义好的配置文件，组件配置将会对ConfigProvider组件所包裹的所以组件生效。
03、自定义组件库
03_1、业务组件库搭建
单包架构
一个代码仓库里所以组件打包成一个整天，发出去一个npm包
优点
- 公共代码易复用
- 展示更聚合，便于维护
- 引入一个包即可使用全部组件
缺点
- 修改一个组件需要更新整个库
- 需要考虑按需加载
多包架构
一个代码仓库包含多个组件代码，会发布出去多个npm包
优点
- 单独发包，升级灵活
- 在同一个仓库下，便于代码管理
- 使用者无需考虑按需加载
缺点
- 组件间相互依赖时，需要通过npm包引入
- 组合使用时需要安装每一个用到的npm包
技术方案
对外档案
03_2组件开发规范
什么是好的组件
高内聚、低耦合
对外提供简单稳定的接口，对内关注内部逻辑的实现，组件和组件之间能简单实现定制功能。
通用性、易拓展
基础组件适用广泛的业务场景，即适用于不同的业务平台；业务组件适用于针对性平台，即具备显著的业务属性，一般基于基础组件开发。
项目组织
- 语义化命名：组件的命名应当具有语义，并且避免与基础组件冲突，同一团队/仓库下的业务组件，也可以采用相同的命名前缀。
- 包名和组件名最后一致：NPM包名应当与组件名保持一致，包含明确的使用场景信息
- 单独维护类型文件：推荐将需要对外导出的TS类型维护在单独的interface.ts中，并将其在index.ts中导出。
组件设计
- 组件属性定义：在为组件定义接口类型时，应继承原生DOM（或基础组件）属性，避免属性遗漏或者重复声明。
- 类名前缀统一：组件使用特殊且统一的类名前缀，尽量降低与用户类名冲突的可能性。
- 避免行内样式：确保外部可通过类名进行样式覆盖。
- 避免在JS中耦合CSS：应尽量保证逻辑与样式的分离，确保用户可以分别引入JS和CSS文件，避免由于构建环境的不同导致的用户编译失败的问题。
- 注意样式的按需加载：在基于组件库如Acro进行业务组件的逻辑封装时，应注意按需引入所依赖的Arco基础组件的样式文件。
03_3实例实践guide-tip
引导气泡
