组件（库）开发相关总结

现状

没有统一组件库，具体问题表如今如下几点：

1. 数量：可复用组件少，常常须要造轮子，而且造完没有抽出来以供其余项目复用；
2. 文档：文档缺失，更换开发者大几率须要摸瞎看源码，并且极可能 A 项目已经存在了解决方案，B 项目的开发者并不知道（或者知道了却根本无从下手拷贝），重复造轮子；
3. 维护：1 中的轮子复用依靠复制粘贴，可维护性差，出现问题多方同步修改。

可复用组件类型

4. UI 组件：譬如弹层（Mask,SlideUp）、轻提示(Toast)以及输入框（Input）等组件（每每还存在一些兼容性问题）；
5. 业务组件：相同业务类型可复用的组件，譬如抽奖转盘组件；
6. 逻辑组件：譬如传送门（Portal）、切换器（Toggler）以及校验器（Validator）等能够用来优化代码结构并减小重复代码等无形态组件。

我的思考

TO C 业务当然千奇百怪，但总有类似之处，如何与业务结合，分离可变与不可变，提升开发效率，正是工程师存在的意义（固然也须要产品【业务抽象】以及设计【ui 规范】同窗的共同参与）。

若是不一样项目设计风格实在差别较大，也可以经过改改样式复用，而非重写一遍逻辑以及兼容性处理。

既要有造轮子的能力（我的），也要有不造轮子的觉悟（团队）。

开发相关

模块处理

一般咱们通常会提供三种形式的模块：

• commonjs，简称 cjs。
• es module，简称 esm。便于应用打包时进行 tree-shaking。
• umd。供使用方外链使用，兼容 cjs 以及 amd。

想要深刻能够看import、require、export、module.exports 混合详解这篇文章，此处只须要知道提供何种形式的模块以及何提供它们便可。

语法转译

应用开发者一般会在 babel-loader 中 exclude 掉 node_modules，因此咱们发出的包须要转成 es5 语法，避免在低版本浏览器上不兼容，可使用 babel 以及 tsc 进行处理，如今 babel 也支持 typescript，建议直接使用 babel，还能够进行相关插件配置。

在转译时，会存在一些辅助函数（helpers），这些函数式会在每个文件生成，建议使用@babel/plugin-transform-runtime以及@babel/runtime将辅助函数抽离，能够减少打包体积的大小且能够复用宿主项目的@babel/runtime。

Polyfill

1. 不许使用@babel/polyfill污染宿主环境；
2. 可使用@babel/plugin-transform-runtime结合@babel/runtime-corejs3，避免污染全局，但存在"foobar".includes("foo") 的代码的话也是无能为力；
3. 建议告知使用方依赖了哪些须要 polyfill 的 API，交由使用方自行配置 polyfill，不然可能会致使重复依赖或不一样版本之间的冲突。

若是宿主应用直接一个import '@babel/polyfill'，咱们基本躺着就好。

其实关于语法转译还有 polyfill 有一种名为后编译的操做。后编译：指的是应用依赖的 NPM 包并不须要在发布前编译，而是随着应用编译打包的时候一块编译。是一种性能优化手段，更多可参见webpack 应用编译优化之路。

样式处理

先谈谈单组件开发，相似react-slick这种包含样式的典型组件。

单组件样式处理和平时开发的应用样式处理较为相似，直接打包出一份 css 样式文件，交由使用方引入便可。

固然也能够直接将 css 打入 js 文件，使用方无需引入。

组件库（如 antd）则较为麻烦，由于要达到样式按需引入的效果。

首先咱们组件库的模块处理方式有如下 3 种：

• cjs 与 esm：只编译不打包（为了按需引入）、依赖外置
• umd：既编译也打包、部分依赖外置，部分依赖须要一同打包

若是是 umd 形式，很明显和按需引入无缘，只须要经过rollup直接打包抽离 css 文件，交由使用方外链引入。

而 cjs 以及 esm 的形式，要实现样式的按需引入，则有如下 4 种方式：

1. 使用 sass/less/stylus 等预处理器开发，相应组件内部直接 import 相应(.scss/.less/.styl)文件。

   • 优势：1. 使用预处理器，开发体验佳；2. 使用方无需手动引入样式文件。
   • 缺点：1. 使用方须要关注预处理器适配问题。

2. 使用 css 开发，相应组件内部直接 import 样式文件。

   • 优势：1. 使用方不须要关注预处理器适配问题（css-loader 仍是要的）；2. 使用方无需单独引入样式文件。
   • 缺点：1. 开发体验较差。

3. antd 处理方案。使用 sass/less/stylus 等预处理器开发，相应组件不 import 样式文件，编写 style/index.js 管理组件间的样式依赖（sass/less/stylus），生成 style/css.js 管理组件间样式依赖（css），使用方根据宿主项目预处理器选择引入 style/index.js 或 style/css.js。

   • 优势：1. 使用预处理器开发体验佳；2. 使用方能够选择引入 css.js 样式，不用关心预处理器适配问题。
   • 缺点：1. 使用方须要单独引入 style/index.js 或 style/css.js（这一点可用 babel 插件解决）；2. 开发时须要编写一份 style/index.js 用于维护组件间的样式依赖；3. 打包时须要使用比较 tricky 的方式生成一份 style/css.js。

4. css in js 方案。使用 styled-components，相关文章：精读《请中止 css-in-js 的行为》。

   • 优势：1. 开发体验较好；2. 使用方无需单独引入样式文件；3. 使用方无需关注预处理器适配问题。
   • 缺点：1. 生态(postcss?没怎么使用过这个方案不太了解); 2. 缓存问题

总结

1. 不管是组件仍是组件库，最好提供 cjs/esm/umd 等三种形式的模块供不一样使用情景使用；
2. 组件库 esm/cjs 的形式须要达到按需引入， 推荐使用 gulp 结合 typescript 或 babel，只编译不打包，单独使用 tsc 或 babel 也能够，但考虑到须要处理样式，最好结合一个工具将流程串起来。umd 形式则直接使用 rollup 打包；
3. 组件库样式按需引入有上文四种方案，根据业务形式进行选择，须要进行权衡取舍；
4. 单组件不存在按需引入，直接使用 rollup 打包出 esm/cjs/umd 三种形式模块便可。

附录：

- [dora-ui](https://github.com/worldzhao/dora-ui "dora-ui")
- [react-component-template](https://github.com/worldzhao/react-componet-template "react-component-template")
复制代码