四十五----组件库设计

组件库设计主要考虑几点。
有意义：

• 命名准确，充分表意。
• 参数准确，必要的类型检查。
• 适当的注释
  通用性：
• 不要耦合特殊的业务功能。
• 不要包含特定的代码处理逻辑。
  ⽆状态，⽆副作⽤：
• 状态向上层提取，尽量少⽤内部状态。
• 解耦IO操作。
  避免过度封装：
• 合理冗余。
• 避免过度抽象。
  单一职责：
• ⼀个组件只完成⼀个功能。
• 尽量避免不同组件⻅相互依赖、循环依赖。
  易于测试：
  更容易的单元测试覆盖。

组件库设计主要有几大模块。

一、组件库架构选择----仓库管理

Multirepo
⼀个仓库内只⼀个项⽬，以⼀个npm包发布，适⽤于基础组件库。
优点

• 项⽬简单，调试安装⽐较⽅便。
  缺点
• 项⽬庞⼤时构建和发布耗时⻓。
• 组件库使⽤时需整体引⼊，造成⼀定的资源浪费。（可通过es module⽅式解决）
  比如：antdsign

管理工具
git submodule
（git提供的一种管理子仓库的方案
可以批量管理和维护多个git repo
本质上是一个父repo维护了一份各个子repo 的清单
有坑: Git Submodule的坑
替代方案: git subtree

Monorepo
⼀个仓库内管理多个项⽬，以多个npm包⽅式发布，依赖集中管理，npm包版本可以集中管理，也可以 单独管理。通常适⽤于有⼀定关联的组件，但各组件需要⽀持单独的npm包发布和安装。
优点：

• 共同依赖统⼀管理，版本控制更加容易，依赖管理会变的⽅便。
• ⽀持组件的单独发布和单独构建。
• 使⽤时可以单独引⼊。
  缺点：
• 项⽬搭建复杂度⾼。
  比如react

管理工具：

• lerna
• yarn workspace
• pnpm

二、代码规范

⼀个⾼质量的组件库，eslint和prettier是必须的，能够帮助我们统⼀整个仓库的代码规范。 常⽤的eslint配置：

"eslint:recommended",
"plugin:react/recommended",
"plugin:react-hooks/recommended",
// 如果使⽤ts
"plugin:@typescript-eslint/eslint-recommended",
"plugin:@typescript-eslint/recommended",
"prettier"

也可以使⽤业界成熟的eslint配置: @umijs/fabric
.eslintrc.js

module.exports = {
   
  extends: [require.resolve('@umijs/fabric/dist/eslint')],
};

.stylelintrc.js

module.exports = {
   
  extends: [require.resolve('@umijs/fabric/dist/stylelint')],
};

.prettierrc.js

const fabric = require('@umijs/fabric');
module<