DOOFOX BLOG

9月 29 2019 Category:

了解 UI 框架二次封装的弊端和危害

从事前端开发以来,尤其是接触了 React、Vue 后,发现越来越多的项目在使用 ElementUI 或 Ant Design等 UI 框架时,会重新封装一套自己语言的在框架之上。

我之前也通过这样的方式,来解决大量页面采用同样风格和结构时,通过简单的配置即可生成这个页面。
之所以说是“之前”,因为我发现永远不要低估产品经理,以及要对项目有一定的远见。通常我们很难预料到这个项目会发展到什么复杂程度。

学习成本

我问过一个准备离职正在交接的同事,我问她为什么你会觉得这样封装会好,她给我的答案是,“简单快速” 或 “之前的人交接给我就是这样的”。
我认同确实这样开发可能在项目刚立项时,对前端开发来说,简单又快速。
但对于日后交接这个项目的人,会极大的增加交接成本,因为除了框架外,还得熟悉之前前端自己定义的一套语言,因为每个框架都有不同的设计模式和结构,所以不会存在行业通用的封装格式。

我遇到一个从事物流行业的同事,他们正在开发维护的一套物流订单管理系统。我在聊天时提到这个问题,他说他们公司也是通过这样的方式,在 ANTD 上重新封装一套,那我说交接的时候不会很麻烦吗,他说在他们公司,新入职的同事通常需要 3-4 个月的时间来熟悉他们的代码。这个项目已经产生无数迭代的代码,重构几乎不可能,只能在性能上进行优化。我认为这是严重的资源浪费。

无奈的扩展

通常在被封装的组件内,会有大量的 if 语句,
因为需要根据不同的配置加载不同的内容。例如针对 table 组件,每个列显示字符、按钮、单选框、下拉框等需求,这些都需要配置不同的参数进行控制。
如果产品突然修改某个页面的需求,可能仅仅只是在这个页面需要文字有不同的颜色,你就需要重新添加一个控制参数进行控制。长此以往,table 代码被封装的越来越臃肿。
另外这些 if 语句,通常在前端进行计算,将会严重消耗客户端的性能。

对用户的影响

现在越来越多的JS框架提供的路由支持页面懒加载,以及现在互联网速度越来越快,我们并不需要过分考虑文件额外加载的时间开支。
相比较于将所有封装的 js 打包到一起并通过 if 去判断可能导致的页面的迟缓和操作的卡顿,用户更愿意去等待那么 几百 ms 的 loading 过程。

Q&A

https://www.v2ex.com/t/607129