浅谈React组件库开发（二）：组件库最佳实践

在React大生态中，一个相对成熟的前端团队都会面临一个问题：如何提高团队的开发效率？一个系统有大量的业务场景和业务代码，类似的页面和代码层出不穷。如何管理和抽象这些相似的代码和模块，绝对是很多团队都会遇到的问题。不断复制代码？或者抽象成UI组件或者业务组件？显然后者效率更高。所以现在我们面临一个选择：一是选择React生态中已有的组件库，比如antDesign、Material-UI等相对成熟的组件库；另一种是为团队开发一套自己的组件库。有赞的前端团队选择了后者，制作并开源了Zent。Zent提供了一套完整的基础UI组件和常用的业务组件。目前我们有超过45个组件，这些组件已经应用到有赞的各个PC业务中。广泛应用于。在本文中，我们将讨论如何开发一个优秀的React组件库以及一个完整的组件库的组成。1、选择开源？还是自己造轮子？React环境中有很多优秀的UI组件库。国内知名的antDesign和国外的Material-UI都是比较稳定优秀的组件库。那么为什么一定要自己开发一套组件库呢？原因大致如下：有赞对各业务PC产品都有独立的设计规范，包括但不限于组件样式、交互方式等。有赞微博商城、零售、美业等PC产品业务场景相对复杂，一些通用组件，如Design、SKU组件等，需要进行深度定制。需要同时支持有赞多个业务部门的PC产品。团队成员以开源的方式参与组件库的开发。在这期间，彼此之间会有很多的讨论和碰撞，这也是对团队的磨练过程。2.组件库构成构建一个完整的组件库需要考虑：组件设计思路组件代码规范组件开发流程组件测试组件维护（包括PR/issue管理、签约、文档）1.组件设计思路同一个业务对于场景和交互方式代码的抽象，组件库首先要保证各个组件的视觉风格和交互规范是一致的。X组件是业务场景A中的交互，业务场景B中是另一种UI风格，所以X无法实现。抽象大大增加了组件的构建成本。因此，在设计组件之初，首先需要抽象约定统一的视觉风格和交互规范。其次，组件库的props定义需要有足够的可扩展性，内部完全控制组件，保持组件统一输入输出。让我们看一个Button的例子。//Button是Zent{children}/Button>这是一个按钮组件。我们定义了很多标记状态的props，比如type表示Button的视觉风格，size表示大小，disabled，loading状态等，这些状态不会维护组件内部的状态，所有的状态都是确定的通过传入的props。自定义className方便我们自定义样式，children方便我们自定义Button的显示内容。Button甚至提供了标签的功能，只要在Button上传入props:href即可。//Buttonas像首页我们需要做几个约定：组件的所有状态由props控制组件子级支持自定义Dom结构不要硬编码组件内部的Dom结构2.组件代码规范你喜欢前端内部组件库，使用开源的lint工具--猫科动物。felint是一款前端代码检查工具，集成了eslint、stylelint和githook。felint为您的项目做了以下三件事：初始化eslint/stylelint配置文件。无论是react项目，vue项目，es5还是es6，都提供了针对性的配置方案。将eslint/stylelint及其依赖安装到当前项目的node_modules中，在提交代码时挂载githook进行强制校验。具体使用请参考官方文档——felint文档地址。3.组件开发流程在对组件的设计思路和代码规范达成一致后，我们就可以参与到组件的开发中了。组件库的基本开发流程包括以下几点：组件初始化component编码组件DemoZent有一个组件初始化命令：yarnnew-component，该命令完成了组件的大部分初始化工作，包括自动创建目录和模板组件需要的代码，添加组件js和css代码。然后，我们就可以开始编写组件代码了。代码风格和规范严格按照lint规范编写。如果不符合规范，则无法提交代码。编写好组件后??，需要编写组件Demo并运行，通过在本地启动服务器来运行组件Demo，可以作为组件的调试工具。4、组件测试js单元测试框架有很多，比如chai、jest、mocha、karma等，Zent组件库采用jest+enzyme的组合。这是一个例子：//ButtonUItestimport{mount}from'enzyme';describe('Button',()=>{it('ButtonUItest',()=>{constwrapper=mount(OK);expect(wrapper.hasClass('zent-btn')).toBe(true);expect(wrapper.text()).to.equal('OK');});});使用jest进行UI测试有局限性，只能测试基本的dom结构和样式，无法检测到一些逻辑交互，只能覆盖大部分情况。yarntest用于执行测试脚本，测试结果会显示在终端上。5.组件维护组件的日常维护占整个组件库生命周期的很大一部分。组件库构建完成后，组件功能会不断迭代，可能是bug修复，也可能是新特性。这些组件的迭代我们通过PR和issue来管理，同时，我们需要管理组件的changelog。一般来说，组件维护主要包括：PR/issue处理、合约发布和changelog管理。下面以Zent为例介绍PR规范。PR标题规则：[bugfix/breakingchange/newfeature]组件名称：修改内容描述前面的方括号用于区分PR/issue的类型：bugfix-组件bugfix；重大变更-不兼容的变更；新特性——新功能修改的内容尽量简洁。总结PR的变化或者描述issue描述。组件名称请使用中文。请使用首字母大写的英文。PR用于生成变更日志。标准化的PR有助于生成更清晰的changelog，一目了然。我们看一下Zent的例子：发送组件out.只有有发包权限的人才可以操作.Zent是以组件库为单位发布的.yarnbuild会打包整个Zent代码,使用命令yarnpublish发包,发包前运行组件测试.包只能测试通过后发布组件文档好的文档是优秀组件库的标准，好的文档可以提升组件库的整体质量和好感度，一个愿意花时间写好文档的团队应该出品一个好的组件库。去吧，组件库文档维护也是组件库生命周期的重要组成部分，有时甚至需要做中英文双语doc。这里是Zent组件库的doc地址：Zent。3.小结本文从组件设计思路、编码规范、开发流程、测试、日常维护五个方面阐述了如何构建React组件库，并以Zent为例，讲述有赞是如何做到的，任何一个组件库都需要经历这个生命周期，但我们需要思考的是：如何打造一个良好的组件库生态环境？我们需要找到一种方法让更多的人参与进来，作为组件库的维护者。我们选择开源输出到React生态。在前端组件化已经成为既定事实的今天，我们不需要重蹈覆辙，而是需要在组件化上尝试新的突破，摆脱前端技术的束缚，从工程师的高度抽象出手头的代码。在组件化的道路上，我们要做的还有很多，Zent只是一个开始。