zmNgFrameWork 架构升级ng1.5和md5静态资源缓存方案【angular1.x】
前言:
在我前面的博客,angular项目总结——angular + browserify + gulp + bower + less 架构分享 把我开发angular的架构进行了分享,并上传到了github https://github.com/zimv/zmNgFrameWork 。
而后我又在我的 gulp系列 里分享了 gulp-rev:项目部署缓存解决方案----gulp系列(六) ,也更新了github上gulpStart的rev分支 https://github.com/zimv/gulpStart, rev 分支 。
最近我在更新这个项目,把angular1.4.7更新到了1.5.5,关于angular的升级,我想说性能方面有提升,载入速度和流畅度都得到了提升。
比较坑的一点,我似乎安装错包了,之前的路由hash是用#,升级之后变成了#!,甚至控制台会报一些不影响任何功能的错误。
我打开angular.min.js,发现里面version显示的是 1.5.5-build.4567。于是我又重新bower安装了1.5.5,
版本注释信息才变成了version:1.5.5。这个时候路由hash才是正常的#,之前的报错也不存在了。
毕竟还是1.x,升级之后并没有需要修改代码什么的,api是兼容的。关于升级1.5.5就说到这里。
升级后,我把zmNgFrameWork 分为三个分支1.4.7、1.5.5 、1.5.5&md5-cache。如果需要md5方案,可以用1.5.5&md50cache这个分支。
md5方案:
md5的缓存部署是现在比较合适和流行的解决方案。根据目前项目和架构,我觉得可以在zmNgFrameWork引入此项配置。
项目中的构建工具,我使用的是gulp,gulp-rev就是解决当前问题的插件。
gulp-rev的基本用法这里我就不做过多介绍,需要了解的可以先看这篇文章 gulp-rev:项目部署缓存解决方案----gulp系列(六) 。
升级前,再啰嗦一下,我们最终需要达到什么效果(以下截图使用gulpStart里的实例):
如图可以看出
最终build的css和js后缀都带有md5签名,rev.json是存储文件名路径的。(我们把这一步骤叫做 ① )
最终html里的文件名路径要和build同步(我们把这一步骤叫做 ② )
要实现一键gulp就把这一切事情做好,就需要我们来配置它:
配置less:
(1) 首先还是在zmNgFrameWork npm安装依赖gulp插件:
npm install --save-dev gulp-rev npm install --save-dev gulp-rev-collector
gulp-rev 来实现 步骤 ①
gulp-rev-collector 实现 步骤 ②
(2)先配置gulp的css任务,打开less.js
require gulp-rev,并加入方框内的代码。
A 执行在gulp.dest之前,这样输出的文件将会带上md5签名,
B 执行在gulp.dest之后,这样将会输出存储文件名路径的rev.json到指定文件夹,
如此一来 步骤 ① 就完成了
(3) 新建rev-collector任务,配置好revJson的文件夹路径和html路径,执行这个任务的时候,gulp会找到所有rev.json,与html里的路径匹配,最终就完成了 步骤 ②
对,这篇文章不是教大家怎么使用gulp-rev的~ 以上只是简单介绍配置less并大致回顾一下。
回顾:
我们再来回顾一下,zmNgFrameWork 的架构:
(1)单页面应用,目前只有一个入口,根目录的index.html
(2)src:
common 包含主要的less(三方库、抽象层和通用样式),所有图片,和一部分js工具
modules 所有模块,模块层的less样式,模块的template,模块的控制器、服务和指令
主模块app.js 将会依赖注入所有 modules 文件夹的子模块
(3) build:
所有图片会被打包到build->common->img,所有css样式最终打包为一个css,被index引用
模块的所有控制器、服务和指令打包为一个js,被index引用
主模块app.js,被index引用
继续配置:
配置md5缓存部署方案,将会让build里所有js和css加上md5签名,并且更新到index.html中。
根据之前的配置,css已经Ok了,如下图:
gulp的时候新建了一个临时输出文件build:temp-build,最开始我其实是直接把rev文件夹放在build文件夹里的,
后来觉得build里面的所有文件都应该是用来部署的静态资源,不需要这些预编译的临时文件。
所以就创建了temp-build作为预编译文件的临时存储。
做到这一步其实还算顺利,而后我开始配置js的md5。
在配置过程中,按照之前的写法,我发现gulp会出现报错。
报错的意思是当前管道流不支持。我想这是gulp-rev 不兼容browserify的管道的原因。
而后我用一个新任务rev-js,把browserify打包好的js,载入到gulp管道,再执行一次输入输出,就能成功生成md5签名了。
但是这个时候build里面会变成这样:
build里面会存在browserify执行后的无签名的js和md5签名的js。
不应该在build里面有预编译文件,于是也同样把browserify生成的js放到临时文件夹里去。
好了 一切OK。现在 步骤 ① 全部完成。
最后再执行一次rev-collector任务,把 步骤 ① 生成的rev.json和index.html进行匹配
现在 步骤 ② 全部完成。
曲折:
看起来很简单嘛~但是过程还有有点曲折。
特别有一件曲折的事情,我已经同步处理了gulp任务执行顺序,使用gulp-sync
rev-js要操作browserify生成的文件,所以要执行在browserify之后,下图是cmd下gulp执行的日志:
rev-js确实是执行在browserify之后,但是我发现rev-js并没有输出任何东西。
当我执行完gulp default之后,rev-js像是没有运行一样,什么也没输出。
而后我再单独运行一下rev-js任务,这个时候就有输出了(因为这个时候browserify已经完全执行完毕)!
后来纠结了很久,又遇到了各种情况,又发生了各种猜测和验证实验。最终的结论确是:
gulp-aync无法获取browserify的管道,也无法得知它的任务是否完成。之所以gulp日志里面显示的是完成,不过是gulp默认的处理而已。
而后,我给rev-js任务加上了延迟,rev-js延迟之后,还需要给rec-collector延迟,rev-collector依赖rev-js。这样才勉强能完成工作。
暂时没有想到更好的办法了。加上延迟之后,gulp-aync无法正确判断它是否完成了任务,所以也会默认处理为完成。
不过这里这样使用暂时不会造成其他问题,这种处理方式实在不优雅。
当然我也想过在browserify任务里,添加监听事件,但是根据目前里面的逻辑,我觉得最好不要那么做。
如果能使node的pipe同步就好了,可以吗?好像不行~求大牛指点!!
小结:
架构调整和升级是一件有风险,又非常有意思的事情。而最终的目的还是适应业务、提升效率、解决问题。
最后奉上zmNgFrameWork 运行后的样子,两个测试页面:
gulp问题已经解决:
browserify同步问题已经得到解决,由下面评论的 @心成 解决的。如他所说,我确实没有返回数据流,through2也帮我解决了browserify循环bundle的问题,总之非常感谢。
而后我还得知,他一年前gulp入门是看我博客入门的,而如今他已经帮我解决了问题了。得多向他学习。。自己都落后了~
调整之后build目录有所改变,之前重命名app.js为文件名:test/test.js ,现在不重命名: test/app.js 。
browserify管道流不被rev支持也解决了, 引入vinyl-buffer,在browserify任务后buffer()一下,详情见最新的git
标签:
相关文章
-
无相关信息