前言
我一直在考虑一个问题。当下,前端组件库层出不穷,发展非常快速。但当我们在业务中使用某个组件库后。
业务与三方组件库就变成了紧耦合,试想如果几年后,有更优秀的组件库出现,我们想替换的话,就会有两个显著的问题:
- 业务代码耦合部分需要重构
- 业务开发人员要熟悉新的组件库
那么,如何让业务代码在无感知的情况下,去进行组件库的替换呢?或者换句话:业务如何应对前端组件快速变化的风险呢。我们可以通过组件代理的方式来解决
组件代理
什么是组件代理:
- 不是重新造轮子,而是开源组件的整合
- 是组件名称的统一
- 是组件方法的固化
- 是业务页面的唯一依赖

通过图可以看到,我们让业务代码依赖组件代理,所有的变化都封装在代理里面,写后端的会比较了解,就是一个代理模式。通过组件代理,我们对业务提供统一的标签,统一的API。当我们要替换组件库的时候,只需要修改组件代理。业务代码更新npm包重新编译发布一次即可。
实现
- 固定名称
我们在使用三方组件会带有特定前缀。比如element是el-select,vant是van-select。
我们可以固定一个业务相关的名字,比如pc-select,mobile-select。
可以用类似下面的方式简化实现components.forEach(function (item) { Vue.component(item.name.replace('El','Tp'), item); });
-
固定API
这个工作量就会必须大,需要每一个组件都进行代理。比如element的select组件,参数如下:
image.png
我们可以定义一个pc-select.vue,在其中定义的props包含上图所有内容,并传递给组件

由于内容较多,就不一一列举
如果更换组件库
- 组件名称都已经固化,写在业务代码中的部分不用动
- API上依然保持已经声明的props中的参数,如果新组件不具备或者名称不同,我们需要在pc-select.vue中
进行代理或装饰,有必要时需要修改三方组件源码。
小结
其实这篇文章并没有太多的技术细节,更多的是一种思路。
目的就是业务代码能最小代价的享受技术进步的红利
网友评论