现在大概三十个页面,五大模块
做的时候是把所有的 JS 文件和到一起了~ 保留了一个 config 给后端去配置
CSS 同样也是合到一起...
大概唯一的好处就是只需要加载一次。。。
也看了很多说模块化之类的东西,但是都是知其然而不知其所以然
共用的东西很少~~~
所以也不知道怎么分 >_<
所以说, what can i do ?
------------------ >_< ----------------------------
单说分模块的问题吧~~~
还是需要大家的努力啊 >_< 23333
现在文件大小来说,还是比较小的, 压缩后才 30 KB ~~~~
那些第三方库肯定是不会打包的哟 ~
因为我用的 gulp 嘛 (俺的文章 https://www.lilonghe.net/arch... )
现在是开发的时候 JS 比较多的页面单分出来
其它的都写在一个 JS 里面,然后有很多个 initXXXXPage
因为写的时候每个页面的 class 不同, 比如 "page-wrapper page-index"
所以会在 init 里面判断这个 class
最后统一调用所有
$(function(){
initXXXPage();
initXXX1Page();
initXXX2Page();
....
});
啊啊啊啊 好烦呐!好纠结啊!
有条件就把静态资源放CDN,没条件就合并,或者在自己服务器对静态文件做缓存
应该是把这个页面需要的文件合并一起吧
不是都放在一个文件吧
30个页面肯定不能把所有的
js
,css
打包在一起,这样文件体积比较大,资源浪费比较多,不太适合多页面应用,比较合理的做法应该是将每个页面依赖的js
,css
打包在一起,产物是一个页面对应一个私有js
,一个私有css
,当然公共的js
就没必要打包进去了,比如你的项目依赖了jquery
,没必要将jquery
打包进私有js
,这样做的好处是可以利用缓存,一个页面加载了jquery
,其他页面就不需要再加载了。我个人来说,有两层合并层级。
第一层文件上的通用化
base、common、特殊模块/功能模块/子模块。这种文件命名方式可以运用在资源、脚本、配置等。
第二层代码上的模块化
如一个母版页面,其骨架是
然后通过url param来判断当前显示的是什么页面,需要哪些模块(但这里还需要设计人员的辛劳)。如
这里再细分,则可以把纯静态、半动态、实时,以及接口调用、自身调用等按照功能模块分开,这样可以极大的优化代码加载量、请求次数、以及代码重用次数。
所以,一般默认按照3个层级来把功能模块化后,再看哪些功能需要提升影响范围的等级。
服务器有合并js,css的功能,不用手工合。
激活合并方法:static.boss.com/js/??a.js,b.js?ver=2016