使用seajs主要解决了现有项目前端开发中的如下问题:
- js文件依赖,js文件的加载顺序。
- js命名空间。
- js模块化开发。
- 业务模块的版本问题。
- 性能提升,主要是网络传输。
- js文件跨域异步加载问题。
- js、css文件打包和压缩合并。
简单的做了一个demo,项目使用maven构造,结构如下:
- webapp/resources:静态资源目录
- webapp/resources/js:js文件目录
- webapp/resources/js/core :业务模块目录,各个子模块单独构造。
- webapp/resources/js/core/hello:hello模块目录,包含package.json,独自构造。
- webapp/resources/js/core/user:user模块目录,包含package.json,独自构造。
- webapp/resources/js/modules:第三方js库目录,不需要单独构造,使用spm构造完成之后放入当前目录即可。
- WEB-INF/views:前端页面目录
具体的seajs应用、相对于传统js开发的改进及api,参考:http://seajs.org/docs/ 。 以下主要说明seajsdemo中的相关实践内容。
引入 seajs依赖。sea.js和seajs-warp.js,其中seajs-wrap.js只需要在开发阶段引入,主要为了给每个js模块动态添加define(function(require , exports , module )){ }的包装。使用spm压缩合并后能够为每个js文件添加define包装,所以压缩完成之后部署时不要引入seajs-wrap.js。
模块配置管理。在一个单独的js配置文件(seajs.config.js)中进行配置,主要配置了三部分内容,分别是第三方js库、业务模块库和业务模块basepath。第三方js库:通过绝对路径配置,在开发和生成环境中不需要改变,能够启用浏览器缓存;业务模块库:主要为了方便不同模块的相互引用,使用相对路径配置。在打包时,只合并本模块内部的js,忽略其它模块的js依赖,在生产环境中每个业务模块库单独加载,降低模块之间的耦合;业务模块basepath:业务模块所处的根路径,如果启用了浏览器缓存,在版本升级时可以改变根路径目录,例如添加版本号目录,加载新的静态文件。参考如下:
seajs.config({ //use absolute path for the third lib alias: { //the third lib 'jquery': '/seajsdemo/resources/js/modules/jquery/1.9.1/jquery' , 'cookie': '/seajsdemo/resources/js/modules/jquery_cookie/0.0.1/jquery.cookie' , //local lib 'user' : 'user/main' }, //base path for business module base: '/seajsdemo/resources/js/core/0.0.1', charset: 'utf-8' });业务模块管理。每个业务模块一个文件夹,并且包含一个package.json,在package.jso中需要指定name、spm.main和spm.buildArgs,其中name是打包之后输出文件的目录,必须和模块文件夹名称相同;spm.main指定需要模块入口的js文件;spm.buildArgs是spm build的参数,需要指定在seajs.config.js中忽略的第三方库和其他业务模块库。参考如下:
{ "name": "hello", "spm": { "main": "index.js", "buildArgs": "--ignore jquery,user,cookie" } }业务模块打包。打包工具spm的安装参考 http://lpyyn.iteye.com/blog/2232659 ,为了方便每个模块的打包,在模块文件夹同级目录下建了一个打包脚本package.sh,能够将各个模块打包到指定的目录下。参考如下:
#!/bin/bash
# package module js
spm build -I ./hello -O ../dist
spm build -I ./user -O ../dist
echo 'spm complete .'
注: 附件seajsdemo.rar解压后放到tomcat下运行。