从0到1教你搭建前端团队的组件系统（高级进阶必备）

本文主要是介绍从0到1教你搭建前端团队的组件系统（高级进阶必备），对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

前言

随着vue/react这类以数据驱动为主的web框架的不断完善和壮大，越来越多的前端团队开始着手搭建内部的组件库。虽然目前市面上已经有很多功能强大且完善的组件库供我们使用，比如基于react的开源组件库ant-design，material，又比如基于vue的开源组件库elementUI，iView等。

我们在开发管理系统或者中台产品时，完全可以使用这种第三方库来开发，因为首先其服务的用户群体比较小众，一般是企业或者运营人员来使用，重点在于功能和业务，所以在B端产品比较适合；另一点就是设计要求相对于C端产品会低一些，因为B端产品或者管理系统风格统一简单反而会降低使用者的学习成本。所以对于上述情况，我们完全可以使用ant-design-pro或者element-admin-vue这类集成管理框架开开发。

我们使用第三方组件库搭建一个企业级应用是完全没有问题的，但是另一方面，随着我们对用户体验以及网站性能的要求越来越高，流量及金钱，速度即王道，对于专注于做C端的企业来说，尽可能的减少用户等待才能留住更多的用户，比如我们在某宝，某东上买一个商品，结果我们花了一分钟商品列表还没有出来（形容的有点夸张），这种情况下客户可有可能直接选择某拼了。很明显像ant-design和elementUI这样的组件不适合做C端产品，因为体积太大了，除非用高性能服务器或者其他方式弥补。所以说采用轻量级组件库对于C端项目来说有以下几点好处：

• 打包体积小，高度可控
• 采用内部组件库安全性更高，防止嵌入攻击
• 构建和开发更灵活，且组合型更高

但是开发组件库还是需要投入时间和成本的，毕竟这东西不是每个团队都玩的起的。说了这么多，接下来我们就来分析和实现一个团队内部的组件库吧。

你将收获

• 如何从0搭建一个组件库
• 前端组件系统设计思路和模式
• 组件库的划分及设计思路
• 组件库的package.json文件配置说明
• 将组件库部署到github并发布到npm上

正文

1. 开发组件库的几种方式

目前我们开发组件库的方式有很多，只要根据npm发包原则去配置就好了，我们可以用webpack自己大家一个library，也可以直接使用create-react-app/vue-cli3来快速改造一个组件库的脚手架，或者采用之前比较火且自动集成tree-shaking的rollup，这些方式都可以搭建我们组件库的脚手架。关于如何使用webpack4.0和rollup，可以参考笔者的以下几篇文章：

• 前端组件/库打包利器rollup使用与配置实战
• 基于create-react-app打包编译自己的第三方UI组件库并发布到npm
• 用 webpack 4.0 撸单页/多页脚手架 (jquery, react, vue, typescript)

其实还有一种最快的方式就是直接去ant-design或者elementUI的github仓库，把代码copy下来改成自己的组件库脚手架，当然，这也不是随便就能改好的，如果想尝试这种方案，建议大家先学好typescript和webpack。

笔者这里采用的是目前比较流行的工具链umi，umi的father专门是提供组件库或者工具库打包的集成工具，我们只需要更改配置文件就能轻松搭建一款自带说明文档的组件库。笔者接下来会具来教大家如何使用它。

2. 前端组件系统设计思路和模式

以上是笔者画的一个简陋的分层图，我们可以看到最底层的是我们的基础视图组件，它是上层建筑的基石。对于一个包含很多子系统的复杂的项目系统来说，要想设计一个好的架构，第一步就是合理划分组件，组件的粒度拆成的足够细，这样才能最大限度的复用组件。

对于任何一个复杂系统来说，最重要的就是实现错综复杂的业务功能，但是不同模块或者子系统之间很多业务往往是相通的或者相似的，如果这个时候我们每个页面对于实现类似的业务场景都去重复去写一遍业务代码，那完全是没必要的，对于可维护性来说也是一种打击，所以基于这种场景我们的 业务组件 就很有必要出场了。我们可以把功能或者需求类似的有机体封装成一个业务组件，并对外暴露接口来实现灵活的可定制性，这样的话我们就可以再不同页面不同子系统中复用同样的逻辑和功能了。

同理，不同页面中往往有可能出现视觉或者交互完全相同或者类似的区块，为了提高可复用性和提高开发效率，我们往往会基于基础组件和业务组件再进行一次封装，让其成为一个独立的区块以便直接复用。

通过这样一层层封装，我们就逐渐搭建了一套完整的组件化系统，基于这种模式的开发往往也是一个好的前端架构的开始。但要注意一点就是高层次的组件一定会依赖低层次的组件，但是低层次的组件不可以包含高层次的组件。（听起来有点像rudex的单向数据流法则），他们的关系就好像下图：

3. 组件库的划分及设计思路

组件库的划分其实可以参考成熟组件库划分。由于业务组件和区块划分完全取决于不同公司的实际项目情况，这里不能形成一套统一的思维框架，所以我这里说的组件库划分主要指基础组件库的划分。我们先来看看antd的划分，它划分为：通用组件，布局组件，导航组件，数据录入和数据展示组件，反馈型组件和其他。elementUI的组件划分为：基础组件，表单组件，数据呈现组件，通知类组件，导航类组件和其他，这些分类发都是非常合理的划分，所以我们在设计组件库时也可以参考或者直接使用，具体总结如下：

• 通用型组件: 比如Button, Icon等.
• 布局型组件: 比如Grid, Layout布局等.
• 导航型组件: 比如面包屑Breadcrumb, 下拉菜单Dropdown, 菜单Menu等.
• 数据录入型组件: 比如form表单, Switch开关, Upload文件上传等.
• 数据展示型组件: 比如Avator头像, Table表格, List列表等.
• 反馈型组件: 比如Progress进度条, Drawer抽屉, Modal对话框等.
• 其他业务类型

至于组件实现的设计思路，其实笔者之前也写过很多文章来做铺垫，第一要义就是需求，一切要从需求出发。不仅仅是react的组件设计，vue或者angular等都是类似的方法和思路，这里简单给大家举一个组件开发的例子—— 弹窗组件（Modal）的开发思路：

1. 需求分析

   
   

   这篇关于从0到1教你搭建前端团队的组件系统（高级进阶必备）的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！