【威尼斯手机娱乐官网】前端自动化构建,吐槽
分类:计算机知识

吐槽前端组件化的踩坑之路

2016/05/10 · 基础技术 · 前端构建, 组件化

本文作者: 伯乐在线 - 亚里士朱德 。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

这篇文章分享的不是成功的经验,而是失败的教训~

前端自动化构建方案#

随着web应用的规模与日俱增,以及用户对前端界面的要求愈加严格,前端开发 “ 刀耕火种 ” 的旧石器时代已经逝去,伴随而来的,是围绕【开发效率】以及【运行性能】的工程化问题。

设坑

关于为什么要研究组件化以及之前对组件化实现方式的理解都在这篇文章——《利用handlebars实现后端组件化》。本来按照之前的思路,觉得组件化应该有三种实现方式,一种是后端模板;一种是浏览器端由js实现,包括reactjs的组件、angular的指令等,不过这些对css文件无法管理(有个插件号称完美实现组件化,研究完之后再分析);最后一种就是利用构建工具实现组件化。

如果真能找到这样一种构建工具,不依赖前后端语言、模板、框架,在构建代码的时候直接直接将组件打包是不是很完美?如果你也这么想,那么恭喜你可以跟我一其踏上一段踩坑之旅了。

一、自动化构建

【自动化构建】作为前端工程化中重要部分,承担着若干需要解决的环节。包括【流程管理】【版本管理】【资源管理】【组件化】【脚手架工具】等。

入坑

目标已经明确的话开始寻找工具。理想的是有工具插件直接实现组件化,差一点的话自己稍加改造实现也可以接受。看看现在比较流行的工程化工具:

1、流程管理

完整的开发流程包括本地开发,mock调试,前后端联调,提测,上线等。在每个团队的基础设施当中(如cms系统,静态资源推送系统等),都会存在一定程度将前端开发流程割裂。如何运用自动化的手段,对开发流程进行改善将可以大幅降低时间成本。

webpack

首先研究这个最新最火的工具,一进入官网就被那个炫酷的css3立方体吸引了,看上去很高大上的样子。官网上内容很多,虽然是英文的但是问题不大。看到菜单上有一系列教程(list of tutorials)非常欣喜,心想好软件就是不一样,教程都写得这么多。一点开傻眼了,根本就不是什么学习教程,就是各种语言凑起来的文章,完全无法引导新手很好的学习,也没有分类。照着例子使用了之后发现如其所说只是个模块打包工具,恨不能让任何页面只引用一个js一个css,对第三方依赖的处理也是狗血,要么合并成一个,要么一个一个配置,手动在html中维护,而且还是侵入式的改变源代码内容。功能很简单,实现过程很复杂,蛋疼之后更是伴随一阵心疼,遂放弃。
如有不对之处,欢迎webpack资深玩家拍砖指点。

2、版本管理

web应用规模愈加复杂,迭代速度也愈加频繁。而前端界面作为一种远程部署,运行时增量下载的特殊GUI软件,如何使用自动化构建工具,对不同版本的资源文件进行管理,并让用户第一时间感知版本的回撤以及升级(尤其是在浏览器缓存以及cdn广泛使用的今天),将对企业有更好的安全保障,对用户有更佳的使用体验。

fis3

其实从fis刚出来的时候我就在关注fis,那时候因为觉得插件不够丰富,再加上项目中使用的是grunt,所以放弃了。这次看到fis的教学视频和fis3的时候我是内心有些激动的。一方面见其生机勃勃,另一方面介绍了百度产品实现组件化的经验。
事情真的那么完美吗?首先不得不承认fis3是一个比较成熟的构建工具,但是一上手就坑了我,release发布代码的时候不能清除目录,只能覆盖发布,号称400多个插件中也没找到可以实现的,我只能用一个字形容——囧。这种感觉就像你来到了一栋摩天大楼,但是它没有电梯,你只能自己爬上去。再细致研究发现其组件化也是依赖后端语言实现的,和后端模板集成在一起,做事情做一半,真是无语。至于Angular和Angular2这种靠前端模板的例子也不是我要找的答案。
不过其目录划分可能还有一些借鉴意义吧。

3、资源管理

随着每个团队业务复杂程度的加深,对于功能模块封装的粒度必将愈加精细。衍生出来的,将会是资源数量以及依赖关系等的管理问题。以人工的方式考虑单个页面或单个功能的资源优化是片面的,并且效率低下。通过工程化的手段,在前端构建过程中自动化地以最优方式处理资源的合并以及依赖,是提升性能以及解放人力资源的重要途径。

现坑

4、组件化

组件化方案,是以页面的小部件为单位进行开发,在系统内可复用。如何以最优化方式实现组件化(js、css、html片段,以就近原则进行文件组织,以数据绑定方式进行代码开发,业务逻辑上相对外部独立,暴露约定的接口);并且随着组件化的程度加深,如何对组件库进行管理,合并打包以及多人共同维护等,都是无法避免的问题。

gulp

gulp和grunt功能上差不多,丰富的扩展性决定了其能成为最强大的前端构建工具。gulp效率高一些,所以这里只讨论gulp。当不停地寻找合适插件的时候终于发现一个关键性的功能似乎不能实现,那就是组件的嵌套引用以及依赖资源的自动合并,如果需要实现这个功能那么要动态处理html代码识别资源然后进行整合,这个功能是不是有些熟悉,对,这就是之前写过的利用后端模板引擎做的事情。
想到这里,这个坑就明显了:我在试图用构建工具来侵入代码来完成模板引擎该做的工作而同时它还无法像模板引擎一样填充数据。这就好比我在用羽毛球拍打乒乓球,还一直觉得是球拍品牌不够好所以打不好球。

5、脚手架工具

我们希望每次研发新产品不是从零开始,不同团队不同项目之间能有【可复用的模块】沉淀下来。对于前端而言,【可复用的模块】除了【组件】,另外就是【脚手架工具】。运用脚手架工具,一键安装,自动化搭建不同类型项目的完整目录结构,工程师将有更多时间专注在业务逻辑代码的编写上。

出坑

回过头来看看构建工具的职能到底是什么?
fis3给其定义了三大职能

  • 资源定位:获取任何开发中所使用资源的线上路径;
  • 内容嵌入:把一个文件的内容(文本)或者 base64 编码(图片)嵌入到另一个文件中;
  • 依赖声明:在一个文本文件内标记对其他资源的依赖关系;——很可惜这个任务没有完全完成
    这三大职能看似很完美,但实际上都是需要在修改源代码的基础上实现,这种耦合程度就很不友好。一方面造成代码混乱,另一方面如果要替换构建工具也变得不可能。
    再看gulp/grunt这种自动化构建工具,将压缩、编译、单元测试、lint等重复性工作自动化,不要求改变源码,我觉得这种无耦合的方式才通用更利于维护。
    总之,如果编写fis3插件来自动处理依赖声明的话,利用构建工具来实现组件化应该是可以的。只是在前后端分离、行为结构样式分离的今天来做这样一件事显然不是最佳最友好的实现方式~

打赏支持我写出更多好文章,谢谢!

打赏作者

二、技术元素

现如今前端技术元素包罗万象,在进行技术选型时,让开发者有了更多的空间。而每个元素应该在自动化构建中承担不同的角色,但职责上不耦合,当前端领域在某一环节有更优方案出现时,能以最低成本进行替代。

【webpack】作为当前最优秀的打包工具,以模块为设计出发点,所有资源都可以作为模块自动化进行合并打包以及依赖处理。目前而言,是解决【资源管理】以及【版本管理】的最佳方案。

【gulp】是一款优秀的构建工具,通过流式是文件管理,以及定制化的任务管理,可完美兼容任何形式的【流程管理】。

【vue】与【avalon】作为数据驱动的 js 框架,都拥有其优秀的【组件化】方案。vue拥有其强大的技术生态,可驾驭不同复杂度的项目,在移动端上性能也尤为卓越;而avalon在兼容性方面作了最大化地努力,可兼容ie6的亮点,则让其在传统项目中拥有先天的优势。

【yo】提供了一个强大的generator构建系统,让开发者可以搭建定制化的【脚手架工具】,快速启动任何类型的项目。

总的而言,【gulp】是粘合剂,进行【流程管理】;【yeoman】制作【脚手架工具】;【webpack】是打包工具,负责【版本管理】和【资源管理】;【vue】及【avalon】则落实逻辑细节,实现【组件化】。

威尼斯手机娱乐官网 1

打赏支持我写出更多好文章,谢谢!

任选一种支付方式

威尼斯手机娱乐官网 2 威尼斯手机娱乐官网 3

2 赞 1 收藏 评论

威尼斯手机娱乐官网 ,三、支线

前端的【自动化构建程度】,与每个团队的【基础设施】以及【项目类型】存在强关联性。“ 一刀切 ” 是鲁莽的,也将受到更多的阻力。更优的选择,是结合现有的基础设施,以及提取过往项目的共同点,为新项目提供更好的技术以及流程支持。

自动化的构建方案,分为【三条支线】。

本文由威尼斯手机娱乐官网发布于计算机知识,转载请注明出处:【威尼斯手机娱乐官网】前端自动化构建,吐槽

上一篇:威尼斯手机娱乐官网其次局地 下一篇:没有了
猜你喜欢
热门排行
精彩图文