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

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

<!-- more -->

设坑

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

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

入坑

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

webpack

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

fis3

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

现坑

gulp

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

出坑

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

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