Write a reusable modern React component module

今天这篇文章主要讲怎么用一种科学、优雅的方式开发一个可复用的 React Component，其实实际上不仅限于 React Component，如果想要写任何一个可以被 npm install 的模块都是可以适用的！

听起来很简单？这个事情的结论是可以用一句话概括的，在我研究了半个月之后发现确实是的（，我们走了一些弯路）。为了照顾那些大忙人，可以直接下拉到文章最底端，使用我推荐的库就行了，我可以保证那个库和它背后的模板是 best practice。

有人说，既然你已经给出了答案，那么还要读这篇文章干什么呢？因为写一个 js module 有很多种写法。可是要做到可复用还要做一些额外的工作。以最简单的方式，我写一个 mymodule.js，在最下方写上 export default MyModule，然后在另一个调用其的文件里面写上 import MyModule from ‘./mymodule’ 这个事情就算完了。我可以对外宣称，这是一个可复用的组件！真的吗？

我担心的事情有：

  1. 这个组件依赖于 React， React-dom，怎么让用户知道他们也必须用这两个东西呢？
  2. 如果用户在自己的应用上面用了 React 16.2，但是我的组件使用了 React 16.8，用户在使用我的组件的时候会出现兼容性问题吗？会不会为了兼容性问题而装两个版本的 React 呢？
  3. 用户调用我的包，是通过文件直接调用的，怎么才能把我的包放在 node_modules 里，即，通过 npm install 的形式安装？
  4. 我的包使用了某些先进的语言特性。通过文件直接调用是无法通过 babel 转义为较低版本的 Javascript 的。甚至，用户都不能通过 import MyModule from './mymodule' 的形式调用！

但是在使用 npm 上面的包的时候，我似乎完全不用担心上面这些问题。所以为了写一个可复用的模块还需要某些额外的操作。

第一个实例

如果我们在 Google 上搜索 “write a reusable react component module” 等词语，我们可以找到一些号称自己是模板的东西，比如说这个 rinse-react，它是一个可以作为 boilerplate 的项目。让我们去看看它为了让 rinse-react 模块化做了哪些工作。

如果你去你的任何一个项目里的 node_modules 里看，你会发现 package.json 至关重要，因为它指定了一个模块的入口点，那就是 main 这个 field。对于 rinse-react 这个模块，其入口点是 dist/rinse.js，可以猜出这个文件是经由 webpack 打包后输出的。

于是我们打开 webpack.config.js, 里面的输入和各种 loader 同正常的 SAP 配置大同小异。但是需要重点指出的是 output.libraryTarget，它的含义就是把 src/index.js 里的返回值以怎样的形式作为模块输出。这里面要指定的值与模块会被怎样调用有关。我们除了 import MyModule from 'mymodule' 这种方式，还可能以 var MyModule = require('mymodule') CommonJS 的形式调用，也可能会以 define('MyModule', [], function() { ... }) 的 AMD 形式调用。为了兼容所有的调用方式，在 rinse-react 里面设置 output.libraryTarge = 'umd' ，这样被 webpack bundle 之后的模块就可以以任何一种形式调用。

对模板的优化

一部分人可以欢呼了， 因为看起来找到了一个可以拿来用的模板。但是有没有发现其中的问题？

  1. 它看上去也把当前版本的 react, react-dom 和 styled-components 打包了进去，增加了库的大小；
  2. 它实际上是先通过 babel 的转译再被下游应用调用的模块，所以下游应用使用 ES6 的 import 的时候，并不会有真正的 tree-shaking （所谓 tree-shaking，就是 ES6 通过分析 import 和 export 判定哪些代码被真正地调用，从而在执行前就把不被调用的代码给去掉）。
  3. 我也没有必要在下游应用 bundle 的时候对源模块进行二次 bundling。

对于第一个问题，在 package.json 里面可以使用 peerDependencies 解决。在 peerDependencies 里面的东西，应该是下游应用也同时依赖的东西。如果你不把依赖放在peerDependencies 而是放在 dependencies 里（就像 rinse-react 一样），它们就会成为私有的依赖。

那么自然地，有没有 peerDependencies 在模块里的版本和下游应用的版本不匹配的情况呢？当然会有。这时候如果出现了不可兼容的版本，npm install 的时候会有提示，而在实际开发中，我发现安装的是最高指定版本。

但是我们还没有解决如何真正地实现 tree-shaking 特性。幸运的是，最佳实践告诉我们，rollup.js 正是为了解决这一问题而来的。rollup 也是一种打包工具，但是和 webpack 的目的不同，rollup 的初衷是为了尽量把模块的依赖打平并且高效地利用 tree-shaking。从这一出发点来讲，编写可复用的模块应该使用 rollup.

在 rollup 打包的过程中，在 package.json 里面会提供两个入口：传统的 main 指向打包后兼容 UMD 的打包内容；前卫的 module 应该会指向一个类似于 main.es.js 的文件：它使用 ES6 的先进特性。这样，在一个实际应用试图 import 一个模块的时候，它会先查看 package.json 是否有 module，如果有的话就以 module 指向的文件作为入口，避免了 babel 转译并且最大限度利用 tree-shaking. 如果应用在 build 的时候不支持 module，就 fallback 到 main 所指向的 UMD.

一个基于 rollup 的库模板

由于很偶然的原因，在我试图研究 Ant Design 如何开发出如此优雅的组建库的同时，我发现了一个可以自动生成基于 rollup bundling 的库模板生成器。这个东西基本上解决了我上面所有的困惑。我诚邀各位试一试这个 create-react-library，并且劝退那些想要研究 Ant Design 的人，他们家自己研发的 rc-init 连文档都没有且都没有人维护的。

当然，在我使用这个模板生成器的时候，他们只能生产出基于 babel 6 的配置。为了与实际开发环境匹配，我又手动修改到了 babel 7。

剩下的问题

看来怎样开发一个 js 库这个问题到现在算是解决了。但是这样的库真的能与 Ant Design 相媲美了吗？在实际下游应用开发过程中会有按需加载的需要，为了能让用户按需加载 Ant Design，babel-plugin-import 应运而生。怎样优雅地面向按需加载开发是一个需要研究的问题。

参考文献

  1. Rinse-react: https://rinsejs.io/
  2. Webpack: output.libraryTarget: https://webpack.js.org/configuration/output/#outputlibrarytarget
  3. Writing Reusable Components in ES6 https://www.smashingmagazine.com/2016/02/writing-reusable-components-es6/
  4. CommonJS vs AMD vs RequireJS vs ES6 Modules https://medium.com/computed-comparisons/commonjs-vs-amd-vs-requirejs-vs-es6-modules-2e814b114a0b
  5. 你的 Tree-Shaking 并没什么卵用 https://juejin.im/post/5a5652d8f265da3e497ff3de
  6. Webpack and Rollup: the same but different https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c

留言

▲