很多人喜欢对 UI 框架进行二次封装。

例如 table 组件，封装几层，用自己定义一套参数的形式控制显示。这样带来的优点是什么？

我发现很多大公司都这么做。

分享优点即可

当升级这些组件时，如果组件的 api/属性发生了改变， 你可以只在封装层做适配， 尽量少的改动业务代码

真正的大公司有自己的组件库

正常来说 应该是 1 楼的观点 一般情况下 封装是为了解耦 模块解耦，尽量让组件不要过于依赖模块或者其他依赖，这样有利于项目重构

还有一种是，项目内多处使用到相同的组件，尽量要做到功能和 ui 的一致性。

根据自己的业务封装 少写点代码 没什么优点

根据业务来封装可以简化组件参数，但那也要维护好文档，否则别人很难接手。

UI 有要求，统一代码风格。

总结来看，就是脱裤子放屁多此一举。

可封装另外一些比如说单行双击可输入、编辑 的 table 针对多处使用的时候比较方便，有时候不仅仅是你一个人在写代码，协同工作，保证只修改一处所有都可以修改，而不是你需要记得每一处这个地方在那怎么去改，解放劳动力吧。

我真对 element-UI 的 table 没少封装，因为原来干的是外包，很多时候客户有不同的需求，会针对 table 有不同的操作，俩三个项目经历下来，其实还是觉得封装一个好使，只需要在这一个封装好的组件里不断进行改造迭代，这个组件可重复利用性就会更高

看来很多人都重新封闭了 table

赞同一楼观点，做一层 adapter，后期框架升级 api 变更，或者换其他框架，都只需要在 adapter 处理就行

想法总是美好的，先不说框架跟框架之前千差万别，iview 和 elementui 就是两个完全不同的框架。光 elementui1 和 elementui 2 就不是所谓的 adapter 层能处理的了的。
另外 大的 API 变成，实际上 2 年都遇不上一次，如果框架有大的 api 更新，必然要调整到之前定义到的内容。

很少大公司有自己的组件库，一个大公司涉及到的平台是在是太多了，内部的用户中心、各种管理平台不下十几个。专门写一套自己的组件库，很难满足所有的需求，另外也没有这个必要。除非是阿里腾讯体量的，但是他们内部项目也不全都是用自己的组件库。

UI 的设计规范和 antd 不一样 , 不可能那么多完全一样的 table 页面我每一个都去重写一遍样式

样式的改变应当通过样式覆盖的形式调整。结构的设计应通过 class 等父级 div 控制，UI 框架提供的组件已经是最小化的形式，真的需要每个组件重写只能说明当初选型的错误。

这种第三方再次封装还是留很多坑的.版本升级问题.新版本多了新组件.代码兼容问题. 本来就是组件拿起来就用了.一个页面多个组件组合起来用.多用数据处理清洗合适合理的 data 结构.总比封装来得实际
一个前端不要搞成 java 语言那样复杂.说是为了以后重构..到时候看代码多就头疼了.
没有哪家公司是真的会去重构.基本都是拿数据库重写写新的业务代码.

我接手的项目封装的更恐怖，只需要传入一个 api 地址就可以用，相反的，如果出了问题或者需求不一致，那我找问题真是日了狗了

封装是为了复用

我司也一样封装一层。好处一是抽象，简单地说就是少写同样的代码。二是解耦，升级的时候不需要大动干戈到处改。第三是用起来更简单，学习成本更低。第四种情况不是很多，就是几种组件可以打包在一起作为一个组合使用。

凡事都要有度，过犹不及。我们在封装的时候就很注意不过度封装。

当然是为了 996 有事干啊。

业务类型单一，封装后的组件才能复用（这种应该叫业务组件了吧），不然会出现各种魔改，或者属性过多还不如自己写的情况

antd 本来就是封装的别人的，又不是完全自主开发出来的

所以大公司可以没有自己的一套组件库，但是可以有自己的多套组件库 :)
Table 是个麻烦活，我做过，找了一圈的结果是没有一个开源组件能在保持基本性能的基础上完全满足各种乱七八糟的需求，所以自己封装了一个
其他组件其实都有类似的情况，但是 Table 是最麻烦的，因为技术上就无解。其他组件主要是这个组件库有 A，那个组件库有 B，业务上要 A B C，没办法，自己做吧

是这样的，table 的不同需求实在太多了。基本都是写完一个，别的页面直接复制过来改改名字，有新的函数再封装...做多了就成了二次封装的、自己用着顺手的 Table 了，哈哈

代码复用罢了，一个项目中，一般逻辑相似，不写重复代码

antd 底层的 rc 组件和 antd 是同一批人写的。

kpi
不封装给别人用怎么讲功劳

简单的封装一下还是可以的。

「如果产品突然修改某个页面的需求，可能仅仅只是在这个页面需要文字有不同的颜色，你就需要重新添加一个控制参数进行控制。」
难道直接使用 Element UI 可以规避这个问题？
「样式的改变应当通过样式覆盖的形式调整……UI 框架提供的组件已经是最小化的形式」
怎么说呢，「想法总是美好的」。

用 Element UI 可以只修改产品需要修改的页面，不会影响到所有页面，也不会在所有页面都有条件判断。
如果要大改 样式 Element UI，正常人应该通过 用 Element UI 官方提供的 SCSS LESS 途径进行调整，而不是特意封装一层垃圾上去。

你能提出这些观点很好，很好的说明你初入职场技术不行公司项目也不行，所以也没遇到过这些问题。

实际就算是阿里腾讯。。也大多有部门用的组件库是针对内部用的大的组件库做一层封装的情况，所以有啥担心的