推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
对 Element Ui 、Ant Design 二次封装的优点是什么？
hoythan · 2019-10-08 17:25:13 +08:00 · 12582 次点击这是一个创建于 1873 天前的主题，其中的信息可能已经有所发展或是发生改变。
很多人喜欢对 UI 框架进行二次封装。
例如 table 组件，封装几层，用自己定义一套参数的形式控制显示。这样带来的优点是什么？
我发现很多大公司都这么做。
分享优点即可
第 1 条附言 · 2019-10-09 10:23:37 +08:00
从事前端开发以来，尤其是接触了 React、Vue 后，发现越来越多的项目在使用 ElementUI 或 Ant Design等 UI 框架时，会重新封装一套自己语言的在框架之上。
我之前也通过这样的方式，来解决大量页面采用同样风格和结构时，通过简单的配置即可生成这个页面。 之所以说是“之前”，因为我发现永远不要低估产品经理，以及要对项目有一定的远见。通常我们很难预料到这个项目会发展到什么复杂程度。
学习成本
我问过一个准备离职正在交接的同事，我问她为什么你会觉得这样封装会好，她给我的答案是，“简单快速” 或 “之前的人交接给我就是这样的”。 我认同确实这样开发可能在项目刚立项时，对前端开发来说，简单又快速。 但对于日后交接这个项目的人，会极大的增加交接成本，因为除了框架外，还得熟悉之前前端自己定义的一套语言，因为每个框架都有不同的设计模式和结构，所以不会存在行业通用的封装格式。
我遇到一个从事物流行业的同事，他们正在开发维护的一套物流订单管理系统。我在聊天时提到这个问题，他说他们公司也是通过这样的方式，在 ANTD 上重新封装一套，那我说交接的时候不会很麻烦吗，他说在他们公司，新入职的同事通常需要 3-4 个月的时间来熟悉他们的代码。这个项目已经产生无数迭代的代码，重构几乎不可能，只能在性能上进行优化。我认为这是严重的资源浪费。
无奈的扩展
通常在被封装的组件内，会有大量的 if 语句，因为需要根据不同的配置加载不同的内容。例如针对 table 组件,每个列显示字符、按钮、单选框、下拉框等需求，这些都需要配置不同的参数进行控制。 如果产品突然修改某个页面的需求，可能仅仅只是在这个页面需要文字有不同的颜色，你就需要重新添加一个控制参数进行控制。长此以往，table 代码被封装的越来越臃肿。
对用户的影响
现在越来越多的JS框架提供的路由支持页面懒加载，以及现在互联网速度越来越快，我们并不需要过分考虑文件额外加载的时间开支。 相比较于将所有封装的 js 打包到一起并通过 if 去判断可能导致的页面的迟缓和操作的卡顿，用户更愿意去等待那么 几百 ms 的 loading 过程。
第 2 条附言 · 2019-10-22 18:00:33 +08:00
总结来看，就是脱裤子放屁多此一举。
想法总是美好的，先不说框架跟框架之前千差万别，iview 和 elementui 就是两个完全不同的框架。光 elementui1 和 elementui 2 就不是所谓的 adapter 层能处理的了的。
另外 大的 API 变成，实际上 2 年都遇不上一次，如果框架有大的 api 更新，必然要调整到之前定义到的内容。
很少大公司有自己的组件库，一个大公司涉及到的平台是在是太多了，内部的用户中心、各种管理平台不下十几个。专门写一套自己的组件库，很难满足所有的需求，另外也没有这个必要。除非是阿里腾讯体量的，但是他们内部项目也不全都是用自己的组件库。
样式的改变应当通过样式覆盖的形式调整。结构的设计应通过 class 等父级 div 控制，UI 框架提供的组件已经是最小化的形式，真的需要每个组件重写只能说明当初选型的错误。
想法总是美好的，先不说框架跟框架之前千差万别，iview 和 elementui 就是两个完全不同的框架。光 elementui1 和 elementui 2 就不是所谓的 adapter 层能处理的了的。
另外 大的 API 变成，实际上 2 年都遇不上一次，如果框架有大的 api 更新，必然要调整到之前定义到的内容。
很少大公司有自己的组件库，一个大公司涉及到的平台是在是太多了，内部的用户中心、各种管理平台不下十几个。专门写一套自己的组件库，很难满足所有的需求，另外也没有这个必要。除非是阿里腾讯体量的，但是他们内部项目也不全都是用自己的组件库。
样式的改变应当通过样式覆盖的形式调整。结构的设计应通过 class 等父级 div 控制，UI 框架提供的组件已经是最小化的形式，真的需要每个组件重写只能说明当初选型的错误。
 |
1
cnanyi 2019-10-08 17:35:30 +08:00  2
当升级这些组件时，如果组件的 api/属性发生了改变， 你可以只在封装层做适配， 尽量少的改动业务代码
|
 |
2
cuzfinal 2019-10-08 19:47:35 +08:00 via Android
真正的大公司有自己的组件库
|
 |
3
zhuzhibin 2019-10-08 23:36:39 +08:00 1
正常来说 应该是 1 楼的观点 一般情况下 封装是为了解耦 模块解耦，尽量让组件不要过于依赖模块或者其他依赖，这样有利于项目重构
|
 |
4
Vogan 2019-10-09 07:35:02 +08:00 via iPhone
还有一种是，项目内多处使用到相同的组件，尽量要做到功能和 ui 的一致性。
|
 |
5
nianyu 2019-10-09 08:44:36 +08:00
根据自己的业务封装 少写点代码 没什么优点
|
 |
6
zhw2590582 2019-10-09 09:16:43 +08:00
根据业务来封装可以简化组件参数，但那也要维护好文档，否则别人很难接手。
|
 |
7
realkaiway 2019-10-09 09:27:00 +08:00 via iPhone
UI 有要求，统一代码风格。
|
 |
8
hoythan OP 总结来看，就是脱裤子放屁多此一举。
|
 |
9
Asyncway 2019-10-09 09:48:17 +08:00
可封装另外一些比如说单行双击可输入、编辑 的 table 针对多处使用的时候比较方便，有时候不仅仅是你一个人在写代码，协同工作，保证只修改一处所有都可以修改，而不是你需要记得每一处这个地方在那怎么去改，解放劳动力吧。
|
|
10
Asyncway 2019-10-09 09:50:52 +08:00
我真对 element-UI 的 table 没少封装，因为原来干的是外包，很多时候客户有不同的需求，会针对 table 有不同的操作，俩三个项目经历下来，其实还是觉得封装一个好使，只需要在这一个封装好的组件里不断进行改造迭代，这个组件可重复利用性就会更高
|
 |
11
Radom 2019-10-09 09:57:28 +08:00
看来很多人都重新封闭了 table
|
 |
12
zzlove 2019-10-09 10:05:37 +08:00
赞同一楼观点，做一层 adapter，后期框架升级 api 变更，或者换其他框架，都只需要在 adapter 处理就行
|
|
13
hoythan OP @zzlove 想法总是美好的，先不说框架跟框架之前千差万别，iview 和 elementui 就是两个完全不同的框架。光 elementui1 和 elementui 2 就不是所谓的 adapter 层能处理的了的。
另外 大的 API 变成，实际上 2 年都遇不上一次，如果框架有大的 api 更新，必然要调整到之前定义到的内容。 |
|
14
hoythan OP @cuzfinal 很少大公司有自己的组件库，一个大公司涉及到的平台是在是太多了，内部的用户中心、各种管理平台不下十几个。专门写一套自己的组件库，很难满足所有的需求，另外也没有这个必要。除非是阿里腾讯体量的，但是他们内部项目也不全都是用自己的组件库。
|
 |
15
hgrx 2019-10-09 11:00:22 +08:00
UI 的设计规范和 antd 不一样 , 不可能那么多完全一样的 table 页面我每一个都去重写一遍样式
|
|
16
hoythan OP @hgrx 样式的改变应当通过样式覆盖的形式调整。结构的设计应通过 class 等父级 div 控制，UI 框架提供的组件已经是最小化的形式，真的需要每个组件重写只能说明当初选型的错误。
|
 |
17
version 2019-10-09 12:59:27 +08:00
这种第三方再次封装还是留很多坑的.版本升级问题.新版本多了新组件.代码兼容问题. 本来就是组件拿起来就用了.一个页面多个组件组合起来用.多用数据处理清洗合适合理的 data 结构.总比封装来得实际
一个前端不要搞成 java 语言那样复杂.说是为了以后重构..到时候看代码多就头疼了. 没有哪家公司是真的会去重构.基本都是拿数据库重写写新的业务代码. |
 |
18
Frank520 2019-10-09 15:15:58 +08:00
我接手的项目封装的更恐怖，只需要传入一个 api 地址就可以用，相反的，如果出了问题或者需求不一致，那我找问题真是日了狗了
|
 |
19
fewok 2019-10-22 17:53:54 +08:00
封装是为了复用
|
 |
20
xuanbg 2019-10-22 17:53:59 +08:00
我司也一样封装一层。好处一是抽象，简单地说就是少写同样的代码。二是解耦，升级的时候不需要大动干戈到处改。第三是用起来更简单，学习成本更低。第四种情况不是很多，就是几种组件可以打包在一起作为一个组合使用。
|
 |
22
duan602728596 2019-10-22 17:56:06 +08:00
当然是为了 996 有事干啊。
|
 |
24
Caballarii 2019-10-22 18:41:27 +08:00
antd 本来就是封装的别人的，又不是完全自主开发出来的
|
 |
25
secondwtq 2019-10-22 23:12:41 +08:00
|
 |
26
HytonightYX 2019-10-22 23:25:19 +08:00
@secondwtq 是这样的，table 的不同需求实在太多了。基本都是写完一个，别的页面直接复制过来改改名字，有新的函数再封装...做多了就成了二次封装的、自己用着顺手的 Table 了，哈哈
|
 |
27
optional 2019-10-22 23:28:22 +08:00 via Android
代码复用罢了，一个项目中，一般逻辑相似，不写重复代码
|
 |
28
DiamondYuan 2019-10-23 00:04:53 +08:00
@Caballarii antd 底层的 rc 组件和 antd 是同一批人写的。
|
 |
29
kimown 2019-10-23 08:45:34 +08:00 via Android
kpi
不封装给别人用怎么讲功劳 |
 |
30
justdoit123 2019-10-23 09:44:45 +08:00
简单的封装一下还是可以的。
|
 |
31
SilentDepth 2019-10-23 21:15:05 +08:00
「如果产品突然修改某个页面的需求，可能仅仅只是在这个页面需要文字有不同的颜色，你就需要重新添加一个控制参数进行控制。」
难道直接使用 Element UI 可以规避这个问题？ 「样式的改变应当通过样式覆盖的形式调整……UI 框架提供的组件已经是最小化的形式」 怎么说呢，「想法总是美好的」。 |
|
32
hoythan OP @SilentDepth 用 Element UI 可以只修改产品需要修改的页面，不会影响到所有页面，也不会在所有页面都有条件判断。
如果要大改 样式 Element UI，正常人应该通过 用 Element UI 官方提供的 SCSS LESS 途径进行调整，而不是特意封装一层垃圾上去。 |
|
33
hoythan OP @SilentDepth 你能提出这些观点很好，很好的说明你初入职场技术不行公司项目也不行，所以也没遇到过这些问题。
|
 |
34
clare233 2019-10-26 22:33:40 +08:00
实际就算是阿里腾讯。。也大多有部门用的组件库是针对内部用的大的组件库做一层封装的情况，所以有啥担心的
|
Select Language