工作中的前端工程化问题

看过张云龙在git上关于前端集成的讨论,总结下工作中的问题。去年初的时候读过,之后也思考总结过我们平时开发项目中遇到的问题。现在再重新梳理一遍,主要是组件化。InfoQ 上的文章 && github 上文章

先谈谈在工作中遇到的问题。平时工作中负责的管理系统较早的开始在两三年之前,采用了某个 SPA 框架,以及搭配的 UI。有几个现基于此技术系统需要不时升级维护。在开发过程中,经常遇到该 UI 引起的很诡异的 bug,并且该 UI 源码较难读懂维护。于是在新的系统中使用了另一套 UI,新的 UI 代码容易理解,也容易在此之上扩展。

遇到的问题

最开始接触这些项目时,规规矩矩按照框架的配置规范开发页面,遇到问题看着代码排查,觉得还很顺手。时间久了,做的多了,感觉有不少重复的工作,比如每次添加页面做的事情有些过程是完全重复的。在一个项目中有一个复杂的页面,代码有 1000 多行。维护这个复杂的页面实在麻烦,于是开始思考解决这种问题。

在那个复杂的页面中,确实有很多事情要做,主要有几个大块头:一个按钮点击之后弹出对话框,选择几个数据,这样的组件有5个左右。然后显示在页面上;还有个是选择后的资源列表有优先级要求,要求支持排序;还有最下面的非常独特的功能强大的可编辑表格。

组件封装

对这个问题,解决的方法是在原来的基础UI上,封装业务UI。将上面提到的大块头封装为一个业务级的UI组件,每个UI组件只对外暴露 setValue(编辑页面时,填充内容), getValue(提交表单时,获取组件数据),render (渲染组件)。封装完业务UI之后,工作轻松了不少,不过还有些重复的劳动力,就是刚提到的每个页面很相似,只有少许的不同,每次新增模块,复制一份修改,也显得太不专业了。不过项目快结束了,不管了。

多个项目中的组件模块化

重构完那个项目之后,接手了几个项目的维护工作。发现了更多的问题,总结一下大的问题:

  1. 几个项目的组织不尽相同,虽然项目大体是一致的,但在配置信息、用户信息、导航处风格不一样(插一句:导致如此的原因与选用的框架有关)。
  2. 有些项目还处于之前提到的状态,类似功能在几个项目中多种实现。
  3. 上面提到的新增一个模块,复制修改,在几个地方配置。
  4. 维护公共模块。几个项目中公用框架和基础UI,都是独立的。
  5. 采用的框架是独立的,遇到问题只能看代码,前人踩过的坑后人接着踩。

受上面文章影响,平时也用 grunt 工具,考虑用 yeoman 解决这些问题。对第一三问题,除了规范,就是使用 yo 定义 generation 生成项目脚手架,新增模块和组件都能用命令生成一个空的文件。对第四个问题最好的解决办法是,在一个独立的项目上维护这些公用库,搭建自己的私有 bower,维护自己的 cdn。对公用库,要求严格些,必须通过测试,有齐全的文档和 demo。第五个问题,可以在 gitlab 上记录 issue。

后来

跟大家讨论过上面的问题之后,大家普遍觉得那个框架太旧了,不如投奔开源的,先看看 angularJS 吧。

文章之外

业务UI 为什么有差异?项目时间长,前后负责项目的产品和码工都不是同一个人,更不用说几个不同的项目了。如果前端UI库齐全,可以反过来要求产品设计遵循规范的UI。