【第643期】百度FEX黄子毅：React & Npm 组件库维护

前言

铺垫了好几期react相关的，今天我们来看看由百度FEX@黄子毅童鞋的分享，内容丰富，需要多花点时间（准备下葛优躺）。本文由@互联网技术联盟授权。

正文从这开始～

为什么是 React？

我们先来回顾一下 React ，Facebook 是这么描述的：

A JavaScript library for building userinterfaces

官方定义其为 UI 库，这名字似乎太低调了些。从 React-Native 的发展就能看出来其野心勃勃，但官方的定义反而使其成为了开发者的宠儿 —— “为什么要用React?” “它只是个UI库”。

从 jQuery开始，前端组件遍地花开，有jQuery官方提供的成套组件，也有活跃社区提供的第三方组件，从最简单的文本截断功能，到复杂的拖拽排序都应有尽有。业务使用的时候，经常会给 window 挂上 $，代码中组织也非常灵活，在需要复杂 dom操作时，jQuery 总能帮忙轻松完成。

React 这个 UI库进入大家的视野后，我们猛然发现『万物皆组件』，就连最不加修饰的业务代码也可以作为组件被其它模块所引用，这极大的激发了大家的热情。写代码的时候感觉在造轮子，在写导航栏、稍微通用点儿的功能时都自觉的将其拆了出来，刚要把标题写死，猛然想到 “如果这里用传参变量，UI加个参数配置，这不就成通用组件了吗！”。最早、最彻底的把后端模块思维引入到前端，所以 React 组件生态迅速壮大。

应该说 React 的出现加快了前端发展的进程，拉近了前端与后端开发的距离，之后各个框架便纷纷效仿，逐渐青睐对 Commonjs 规范的支持。业务开发中，将组件化思想彻底贯彻其中，许多人都迫不及待的希望发布自己平时积累的组件，下面就来谈谈如何从零开始构建组件库。

如何从零构建组件库

组件库的教程不只对 React 适用，其中提到的思想，对大多数通用组件编写都有效。

本篇介绍的全部构建脚本代码都可以在 https://github.com/fex-team/fit/blob/master/scripts 找到。

分散维护 VS 集中维护

准备搭建组件库之初，这估计是大家第一个会考虑到的问题：到底把组件库的代码放在一起，还是分散在各个仓库？

调查发现 Antd 是将所有组件都写入一个项目中，这样方便组件统一管理，开发时不需要在多个仓库之间切换，而且预览效果只需运行跟项目，而不是为每个组件开启一个端口进行预览。其依赖的 react-components 组件库中的组件以 rc 开头，不过这个项目没有进行集中管理。

Material-UI、 React-UI 采用集中式管理等等。但是集中管理有一些弊端：

• 引用默认是载入全部，虽然可以通过配置方式避免，（Antd 还提供了 webpack 插件做这个事情），但安装时必须全量。

• 无法对每个组件做更细粒度的版本控制。

• 协作开发困难，每个人都要搭建一套全环境，提 pr 也具有不少难度。

分散维护的弊端更明显，无法在同一个项目中观察全局，修改组件后引发的连带风险无法观察，组件之间引用需要发布或者 mock，不直观，甚至组件之间的版本关联、依赖分析都没法有效进行管理。

因此 Fit 组件库在设计时，也经历了一番酝酿，最后采用了两者结合的方案，分散部署+集中维护的折中方式，而且竟能结合了两者各自的优点：

• 建立根项目 Root，用来做整体容器，顺便还可以当对外网站

• 建立 Group，并在其中建立多个组件仓库

• 开发时只要用到项目 Root，根据依赖文件编写脚本自动拉取每个仓库中的内容

• 主要负责人拉取全部子项目仓库，子组件维护者只需要下载对应组件

• 发布时独立发布每个组件

• 管理时，统一管理所有组件

package 版本统一

组件的依赖版本号需要统一，比如 fit-input ,fit-checkbox,fit-auto-complete 都依赖了lodash，但因为先后开发时隔久远，安装时分别依赖了 2.x 3.x 4.x，当别人一起使用你最新版的时候，就会无辜的额外增加了两个lodash 文件大小。

更可怕的是，连 React 的版本都不可靠，之前就遇到过一半组件留在 0.14.x ，一半新组件装了 15.x 的情况，直接导致了线上编译后项目出错，因为多个 React 组件不能同时兼容，这只是不能并存的其中一个例子。

因为项目开发时组件在一起，使统一版本号成为可能。我们将所有依赖到的组件都安装在 Root 项目中，每个组件的 package.json由脚本自动生成，这个脚本需要静态扫描每个组件的 Import 或 require 语法，分析到依赖的模块后，使用根目录的版本号，填写在组件的 package.json 中，核心代码如下：

先收集每个组件中的依赖，如果在根目录的 package.json 中找到了，就使用根目录的版本号。

完整代码仓库：https://github.com/fex-team/fit/blob/master/scripts/module-manage/utils/upgrade-dependencies.js

依赖联动

依赖联动是指，fit-button 更新了代码，如果 fit-table 依赖了 fit-button，那么其也要发布一个版本，更新 fit-button 依赖的版本号。

除了依赖第三方模块，组件之间可能也有依赖，如果将模块分散维护，想更新一下依赖模块都需要发布+下载，非常消耗时间，而且依赖联动根本没法做。集中维护使用 webpack 的 alias 方案，在 typescript 找不到引用，总之不想找麻烦就不能写 hack 的代码。

回到 Fit 组件库结构，因为所有组件都被下载到了 Root 仓库下，因此组件之间的引用也自然而然的使用了相对路径，这样组件更新麻烦的问题迎刃而解，唯一需要注意的是，发布后，将所有引入非本组件目录的引用，替换成为 npm 名称，例如：

依赖联动，需要在发布时，扫描所有组件，找出所有有更新的组件，并生成一项依赖配置，最后将所有更新、或者被依赖的组件统一升级版本号加入发布队列。

完整代码仓库：https://github.com/fex-team/fit/blob/master/scripts/module-manage/utils/version.js

inline Or ClassName?

React 组件使用 inline-style 还是 className 是个一直有争论的话题，在此我把自己的观点摆出：className 比 inline-style 更具有拓展性。

首先 className 更符合 css 使用习惯，inline-style 无疑是一种退步，既抛弃了 sass less post-css 等强大预编译工具的支持，也大大减弱了对内部样式的控制能力，它让 css 退化到了没有优先级，没有强大选择器的荒蛮时代。

其次没有预编译工具的支持，别忘了许多 css 的实验属性都需要加上浏览器前缀，除非用库把强大的 autoprefixer 再实现一遍。

使用 className 可以很好的加上前缀，在追查文件时能得到清晰的定位，下面是我们对 CSS 命名空间的一种实现 ——html-path-loader css-path-loader 插件 配合 webpack 后得到的调试效果：

文件结构

DOM结构对应 className

直接从 dom 结构就能顺藤摸瓜找到文件，上线时再将路径 md5 处理。这个插件会自动对当前目录下的 scss或less 文件包一层目录名，在 jsx 中，使用 className="_namespace" ，html-path-loader 会自动将 _namespace 替换为与 css 一致的目录名称。

typescript 支持

既然前端模块化向后端看齐，强类型也成为了无可阻挡的未来趋势，我们需要让开发出的组件原生支持 typescript 的项目，得到更好的开发体验，同时对 js 项目也能优雅降级。

由于现在 typescript 已原生支持 npm 生态，如果组件本身使用typescript 开发，我们只需要使用 tsc -d 命令在目录下生成对应的 d.ts 定义文件，当业务项目使用 typescript 的时候，会自动解析 d.ts 作为组件的定义。

再给 package.json 再上 typings 定义指向入口文件的 d.ts ，那么整体工作基本就完成了。

最后，对于某些没有定义文件的第三方模块，我们在根项目 Root 中写上定义文件后， 导入时将文件拷贝一份到组件目录内，并修正相对引用的位置，保证组件独立发布后还可以找到依赖文件。

完整代码仓库：https://github.com/fex-team/fit/blob/master/scripts/module-manage/push.js

更强的拓展性

React 组件的拓展性似乎永远也争论不休，无论你怎样做组件，都会有人给你抱怨：要是这里支持 xxx 参数就好了。

毕竟使用了组件，就一定不如自己定制的拓展性更强，节省了劳动力，就要付出被约束的代价，Fit 作为一个大量被业务线使用的组件库，使用了透传方式尽可能的增强组件拓展性。

我们写了一个很简单的透传组件：fit-transmit-transparently，使用方法如下：

它会将 this.props 中，除了 defaultProps 定义了的字段抽到 _others 中，直接透传给外围组件，因为 defaultProps 中定义了的字段默认是有含义的，因此不会对其进行操作，避免多次定义产生的风险。

现在 fit-input 就将 props 透传到了原生 Input 组件上，因此虽然我没有处理各类事件，但依然可以响应任意的 onKeyDown onKeyUp onChange onClick 等事件，也可以定义 style 来覆盖样式等等。

fit-number 继承了 fit-input，因此依然支持所有原生事件，fit-auto-complete 也继承了 fit-input，对其添加的例如 onBlur 等事件依然会被透传到 input 框中。

组件的 dom 结构要尽量精简，透传属性一般放置在最外层，但对于 input 这种重要标签，透传属性最好放置与其之上，因为用户的第一印象是 onChange 应该被 input 触发。

同构模块引用技巧

当依赖的模块不支持 node 环境，但还必须加载它的时候，我们希望在后端忽略掉它，而在前端加载它；当依赖模块只处理了后端逻辑，在前端没必要加载时，我们希望前端忽略它，后端加载它，下面是实现的例子：

前端加载&后端不加载的原理是，前端静态扫描到了这个模块，因此无条件加载了它（前端引用是静态扫描），后端会因为判断语句而忽略掉这个引用（后端引用是运行时）。

后端加载&前端不加载的原理是，将模块引用拆成非字面量，前端静态扫描发现，这是什么鬼？忽略掉吧，而 node 会老老实实的把模块拼凑起来，发现还真有 module-only-support-in-node这个模块，因此引用了它。

一份代码 Demo & 源码显示

webpack 提供了如下 api 拓展 require 行为：

• ！    打头的，忽略配置文件的 preLoaders 设置

• ！！打头的，忽略所有配置文件的设置

• -！   打头的，忽略 preLoaders 和 loaders ，但 postLoaders 依然有效

一般来说，我们都在配置文件设置了对 js 文件的 loader，如果想引用源码，正好可以用 !! 打头把所有 loaders 都干掉，然后直接用 text-loader 引用，这样我们就得到了一份纯源码以供展示。

组件编写一些注意点

理解 value 与 defaultValue

defaultValue 属性用于设置组件初始值，之后组件内部触发的值的改变，不会受到这个属性的影响，当父级组件触发 render 后，组件的值应当重新被赋予 defaultValue。

value 是受控属性，也用来设置值，但除了可以设置初始值（优先级比 defaultValue 高）之外，还应满足只要设置了 value，组件内部就无法修改状态的要求，这个组件的状态只能由父级授予并控制，所以叫受控属性。

value 与 defaultValue 不应该同时存在，最好做一下检查。

render 函数中最小化代码逻辑

React 的宗旨是希望通过修改状态来修改渲染内容，尽量不要在 render 函数中编写过多的业务逻辑和判断语句，最好将能抽离成状态的放在 state 中，在componentWillReceiveProps 中改变它。

使用 auto-bind

如果你也使用 ES6 写法，那么最好注意使用 auto-bind 插件，将所有成员函数自动绑定 this，否则 .bind(this) 会返回一个新的函数，一来损耗性能，二来非常影响子组件的 shouldComponentUpdate 判断！

慎用 componentWillMount

对于同构模块，React 组件的生命周期 componentWillMount 会在 node 环境中执行，而 componentDidMount 不会。

要避免在 willMount 中操作浏览器的 api，也要避免将可有可无的逻辑写在其中，导致后端服务器渲染吃力（目前 React 渲染是同步的），无关初始化逻辑应当放在 didMount 中，由客户端均摊计算压力。对于影响到页面渲染的逻辑还是要放在 willMount 中，不然后端渲染就没有意义。

巧用 key 做性能优化

React 组件生命周期中shouldComponentUpdate 方法是控制组件状态改变时是否要触发渲染的，但当同级组件量非常庞大时，即便在每个组件做是否渲染的判断都会花费几百毫秒，这时我们就要选择更好的优化方式了。

新的优化方式还是基于 shouldComponentUpdate ，只不过判断条件非常苛刻，我们设定为只有state 发生变化才会触发 render，其它任何情况都不会触发。这种方式排除了对复杂 props 条件的判断，当 props 结构非常复杂时，对没有使用 immutable 的代码简直是一场灾难，我们现在完全忽略 props 的影响，组件变成为了完完全全封闭的王国，不会听从任何人的指挥。

当我们实在需要更新它时，所有的 props 都不起作用，但是可以通过 key 的改变来绕过 shouldComponentUpdate 进行强制刷新，这样组件的一举一动完全被我们控制在手，最大化提升了渲染效率。

组件级 Redux 如何应用

组件级 Redux 使用场景主要在于组件逻辑非常复杂、或使用时，父子 dom 强依赖，但可能不会被用于直接父子级的场景，例如 fit-scroll-listen 组件，用来做滚动监听：

ScrollListenBox 是需要监听滚动的区域，ScrollListenNail 是滚动区域中需要被标记的节点，ScrollListen 是显示滚动监听状态的 dom 结构。

由于业务需求，这三个节点很可能无法满足直接父级子关系，而且上图应用中，ScrollListen 就与 ScrollListenBox 是同级关系，两者也无办法通信，因此需要使用 Redux 作数据通信。

我们从 createStore 实例化了一个 store，并传递给每一个fit-scroll-listen，这样他们即便隔着千山万水，也能畅快无阻的通信了。

npm 资源加载简析

webpack&fis 最核心的功能可以说就是对 npm 生态的支持了，社区是编译工具的衣食父母，支持了生态才会有未来。

为了解决业务线可能遇到的各种 npm 环境问题，我们要有刨根问底的精神，了解 npm 包加载原理。下面会一步一步介绍一个 npm 模块是如何被解析加载的。

文件查找

无论是 webpack、fis，还是其它构建工具，都有文件查找的钩子，当解析了类似 import '../index.js' 时，会优先查找相对路径，但解析到了import 'react' 便无从下手，因为这时构建工具还不知道这种模块应该从哪查找，我们就从这里开始截断，当出现无法找到的模块时，就优先从 node_modules 文件夹下进行查找（node_modules 下查找模块放到后面讲）。

由于 npm 模块打平&嵌套两种方案可能并存，每次都递归查找的效率太低，因此我们首先会把 node_modules 下所有模块缓存起来，这里分为两种方案：

• 根据node_modules 下文件夹遍历读取，优点是扫描全面，缺点是效率低。
  

• 根据 package.json 中 deps（可以设置忽略devDeps）进行扫描，优先是效率高，缺点是忘记 –save 模块会被忽略。

将所有模块存到 map 后，我们直接就能 get 到想要的模块，但是要注意版本问题：如果这个模块是打平安装的，那毫无疑问不会存在同模块多版本号问题，npm@3.x 后即便是打平安装，但遇到依赖模块已经在根目录存在，但版本号不一致，还是会采用嵌套方式，而 npm@2.x 无论如何都会用嵌套的方式。

因此我们的目的就明确了，不用区分 npm 的版本，如果这个当前文件位于非node_modules 文件夹中，直接从根目录引用它需要的模块，如果这个当前位于 node_modules 中，优先从当前文件夹中的 node_modules 获取，如果当前文件夹的 node_modules 不存在依赖文件，就从根目录取。

解读 package.json

找到了依赖在 node_modules 里的根目录，我们就要解析 package.json 进行引了，main 这个属性是我们的指明灯，告诉我们在复杂的包结构中，哪个文件才是真正的入口文件。

我们还要注意 package.json 里设置了 browser 属性的模块，由于我们做的是前端文件加载，所以这个属性对我们有效，将依赖模块的路径用 browser 做修正即可，一般都是同构模块使用它，特意将前端实现重写了一遍。所以当 browser属性为字符串时我们就放弃对 main 信任，转而使用 browser 属性来代替入口路径。

当 browser 属性为对象时，情况复杂一些，因为此时 browser 指代的含义不是入口文件的相对路径，而是对这个模块内部使用的包引用的重定向，此时我们还不能信任 main 对入口的引导，初始化时将 browser 对象保存，整体查找顺序是：优先查找当前模块的 browser 设置，替换 require 路径，找到模块后，如果browser 是字符串，优先用其路径，否则使用 main 的路径。

环境变量

npm 生态非常惯着用户，我们希望直接在模块中使用Buffer process.env.NODE_ENV 等变量，而且通常会根据当前传入的变量环境做判断，可能开发过程中载入了不少影响性能，但方便调试的插件，当NODE_ENV 为 production 时会自动干掉，如果我们不对这种情况做处理，上线后无法达到模块的最佳性能（甚至报错，因为 process 没有定义）。

编译脚本要根据用户的设置，比如 CLI 使用了 NODE_ENV=production ，或者在插件中申明，就将代码中 process.env.NODE_ENV 替换为对应的字符串，对与 Buffer 这类模块也要单独拎出来替换成 require。

模块加载

为了让浏览器识别 module.exports （es6 的 export 语法交给 babel 或者 typescript 转换为 module.exports）、define、require，需要给模块包一层 Define，同时把模块名缓存到 map 中，可以根据文件路径起名字，也可以使用 hash，最后 require 就从这里取即可。由于是简析，不做更深入的分析，剩下的工作基本上是优化缓存、对更多功能语法的支持。

同构方案

为了保证传统的首屏体验，同时维持单页应用的优势，替代方案走了不少弯路。从单独写一份给爬虫看的页面，到使用 phantomjs 抓取静态页面信息，现在已经步入了后端渲染阶段，由于其可维护性与用户体验两者兼顾，所以才快速壮大起来。

后端渲染

无论何种后端渲染方案，其本质都是在后端使用 nodejs 运行前端的 js 代码，有的库使用同步渲染，也有异步，React目前官方实现属于同步渲染，关于同步渲染遇到的问题与解决方案，会在 “同构请求” 这一节说明。

使用 React 进行后端渲染代码如下：

稍稍改造，将其与 Redux 结合，只需要将 Provider 作为组件传入，并传入 store 来存储页面数据，最后获得的 initialState 就是页面的初始数据：

这样，将页面初始数据打在 window 全局变量中，前端 Redux 初始化直接用后端传来的初始数据，就可以将页面状态与后端渲染衔接上。

对于 Redux，是项目数据结构的抽象，最好按照 state 树结构拆分文件夹，将 Redux 数据流与页面、组件完全解耦。

同构请求

同构请求是对后端渲染的进一步处理，使后端渲染不仅仅能生成静态页面数据，还可以首屏展现依赖网络请求数据所渲染出的 dom 结构。

同构请求的优化主要体现在后端处理，因为前端没有选择，只能体现在 Http 请求。现在有两种比较理想的方案：

http 请求

这种方案依赖同构的请求库，例如 axios，在后端渲染时，能和前端一样发出请求并获取数据。主要注意一下，如果使用的是同步渲染的框架，例如 React，我们需要将请求写在生命周期之外，在其运行之前抽出来使用 Promise 调用，待请求 Ready 之后再执行一遍渲染即可。

这种方案修改成本中等，需要把所有同构请求从组件实例中抽离出来，可能获取某些依赖组件实例的数据源比较困难，不过可以满足大部分简单数据请求。

这种方案稍加改造，可以产生一套修改成本几乎为零的方案，缺点是需要渲染两遍。第一遍渲染，将所有组件实例中的请求实例抽取出来，第二步类似使用 Promise.all 等数据获取完毕，最后再执行一遍渲染即可，缺点是渲染两遍，而且网络请求耗费 IO，访问外网数据速度很慢，和直接调用函数的速度完全不在一个数量级。所以我们在想，能不能将前端的 http 请求在后端转换为直接调用函数？

直接命中函数

这个方案基于上一套方案优化而来，唯一的缺点是渲染了两遍，对项目改动极小，后端请求效率最大化。

希望后端直接命中函数，需要对整体项目框架进行改造，因为我们要提前收集全部的后端方法存储在 Map 中，当后端请求执行时，改为从 Map 中抽取方法并直接调用。后端响应请求的方法，我们采用装饰器定义路由与收集到 Map：

fit-isomorphic-redux-tools 组件导出的 routerDecorator 方法做了两件事，第一件是绑定路由，第二件是将收集到的函数塞到 Map 中，key 就是 url，用于同构请求在后端定位查找。

前端代码中，action 中调用 fit-isomorphic-redux-tools 提供的 fetch 方法，这个方法也做了两件事，第一件是前端模块根据配置发请求，第二件在后端环境下，通过url 查找上一段代码在 routerDecorator 注册的函数，如果命中了，会直接执行该函数。

上面的 fetch 方法内部封装了对浏览器与node环境的判断，如果是浏览器环境则直接发送请求，node环境则直接调用 promise。在前后端都经过 redux 处理，为了让 reducer 拿到 promise 后的数据，我们封装一个 redux 中间件：

上述代码对所有包含 promise 的 action 起作用，在前端会在 promise 执行完毕后触发 [actionName]_PROMISE_DONE ，在 reducer 里监听这个字符串即可。后端会直接调用方法，因为方法可能是同步也可能是异步的，比如下面就是异步的：

所以做了两套处理，async 最终返回一个 promise，如果不用 async 包裹住则没有，因此 result.then === 'function' 便是判断这个方法是否是 async 的。

给出一套上述理论的完整实现，有兴趣的同学可以安装体验下：https://github.com/ascoders/isomorphic-react-redux-app

编译优化

为了避免模块太大导致的加载变慢问题，我们通过 require.ensure 动态加载模块，这也对 HTTP2.0 并发请求相当友好。

webpack&Fis 按需加载

使用了 require.ensure 的模块，webpack&fis会将其拆分后单独打包，并在引用时转换为 amd 方式加载，下面是与 react-router 结合的例子：

这样遍做到了对业务模块的按需加载，而且业务模块代码不多，可以忽略编译时对性能的影响：

如果是同构的模块，需要在 node 端对 require.ensure 做 mock 处理，因为 nodejs 可不知道 require.ensure 是什么！.

现在访问 /home 这个 url，前端模块会先加载基础库文件，再动态请求Home 这个组件，获取到组件后再执行其中代码，渲染到页面，但对于后端渲染，希望直接获取到动态加载的组件，并根据组件设置页面标题就变得困难，因此上面代码中， callback(require) 将 require.ensure 在后端改为的同步加载，因此可以直接获取到组件中静态成员变量，我们可以将例如页面标题写在页面级组件的静态成员变量中，例如：

在 node 端这样处理：

并将获取到的 title 插入到模板的 title 中，让页面初始化时标题就是动态组件加载后就要设置的，而且更利于搜索引擎对页面初始状态的抓取，实现了前端对后端的控制反转。

相比业务代码，npm 生态的模块比起来真是庞然大物，动辄 2000+ 细文件的引用，虽然开启了增量 build，但文件的整合打包依然非常影响开发体验，因此有必要在开发时忽略 npm 模块。

webpack 的编译优化

编译优化的最终目的是将大型第三方模块拆开，在编译时直接跳过对其的编译，并直接在页面中引用编译好的脚本，因此第一步需要将所有不顺眼的模块全部打包到 vendor.js 文件中：

entry 定义了哪些文件需要抽出，output 中，library 定义了暴露在 window 的 namespace， plugins 注意将 name 设置为与 library 相同，因为引用时参考的是这个名字。

我们执行 webpack，执行结果如下：

产出了 dll 与 mainfest 两种文件，dll 是打包后的文件，mainfest 是配置文件：

发现配置了两个重要属性，一个是暴露在 window 的 namespace ，另一个是所有相对路径引用的模块名，webpack打包后会转化为数字进行查找，防止路径过长在 windows 下报错。

下面开始配置开发配置 webpack.config.js:

执行结果只有很小的大小：

再将所有文件引用到页面中，这样初始化构建时先执行 dll 脚本，生成打包文件后再仅对当前项目打包&监听，这就解决了开发时体验问题。

可视化拖拽平台组件

最后分享一下我们的终极解决方案 fit-gaea，它是一个组件，是可视化拖拽平台，安装方式如下：

Gaea 是编辑器本身，它主要负责拖拽视图，并生成对应 json 配置。 Preview 是部署组件，将 Gaea 生成的 json 配置传入，可以自动生成与拖拽编辑时一模一样的页面。

最大特色在于组件自定义，右侧菜单栏罗列了可供拖拽的组件，我们也可以自己编写 React 组件在 Gaea 初始化时传入自定义组件，自由设置这个组件可以编辑的字段，并且在组件中使用它。

对于粗粒度的运营招聘页，甚至可以将整个页面作为一个自定义组件传入，因为每个页面非常雷同，只需要定义几处文字修改即可，生成一个新页面，只需要将自定义组件拖拽出来实例化，并且简单修改自己字段即可。

同时 fit-gaea 也提供了很多细粒度的通用组件，例如 按钮、段落、输入框、布局组件 等等，我们也可以自己编写一些细粒度组件，通过任意嵌套组合的方式，生成更加复杂的组合，平台也支持将任意组合成组，打成一个组件保存在工具栏，我们可以通过嵌套组合的方式生成新的组件。

这个平台本质就是一个组件，业务线不需要花费大量精力重复编写非常复杂的拖拽平台，只需要将精力关注在编写与业务紧密结合的定制组件，再传入 fit-gaea，就可以让写的组件变得可以拖拽编辑。

fit-gaea api 文档地址：http://fit.baidu.com/components/pc/gaea
fit-gaea demo 体验地址： http://fit.baidu.com/designer

总结

分享进入了尾声，对以上经验做一个总结。通过对组件库灵活分散的管理，同时透传暴露更多 api 提高组件可用性，提供从组件，到同构方案，最后到开发体验优化与打包性能优化，可以说提供了一套完整的开发方案。

同时通过 React-Native 方案提高三端开发的效率，开发出 web、native 通用的组件，通过 fit-gaea 可视化编辑组件的支持，让编辑器生成横跨三端的页面，并且不受发版、前端人力资源限制，运营&产品都可以快速创建任何定制化页面。

最后，Fit 组件我们一直在努力维护中，我也希望将编写组件的经验分享给更多人，让更多人参与到构建组件生态的队伍中，愿组件社区这棵大树枝繁叶茂。

谢谢大家。

关于本文

作者：@黄子毅

原文链接：http://dwz.cn/3Mgboz

欢迎投稿到前端早读课

投稿邮箱：[e-mail]