seajs+spm之再研究

好久没有用seajs了,之前对spm也只是一知半解,这些天再次拿起来研究.谈谈我的认识与理解.

声明:本文不适合对seajs完全不了解的同学阅读.对于想知道seajs来龙去脉以及spm相关的同学"可能"有帮助.对于我自己也是个梳理的机会.

一.seajs部分

1.seajs由来:

传统web前端的js开发,主要基于script标签的引入,一个文件一个script标签,或者对他们进行简单的压缩与合并,以减少http请求.

没错,我们以前都是这么干的,甚至现在还有很多人这么干.

 

随着这些年的发展,前端越来越被重视,逻辑越来越复杂,前端代码的维护变得越来越难.

2009年,nodejs诞生(nodejs是什么东西,可以自行google),其模块化的编程思想,给攻城师牛人们(包括但不限于前端攻城师)带来了很大的启发.特别是它的模块化依赖管理系统.工程师们想把这个依赖管理机制移植到浏览器端.但是浏览器端目前还没有高度统一的规范,更别说依赖管理机制了.于是工程师们绞尽脑汁,日思夜想.

 

不久后,requireJS诞生了,也的确火了,但它所坚持的原则规范并不被前面那些的大部分工程师们接受.

这时,我国的一位前端大牛也逐渐参与到模块化开发的研究中来.经过不断的虚心学习,借鉴,摸索,seaJS诞生了.他的作者是玉伯(--仰视,尊敬).

 

以上历史介绍,只是我简单的整理与理解.详细的可以参考玉伯本人的描述https://github.com/seajs/seajs/issues/588

2.seajs是什么,能做什么

它是模块加载器(也即js文件加载器),所有模块都可以通过它加载,而且很重要的是,它可以帮你很好的管理模块依赖.当你的页面上有十几二十个js文件的时候,用了seajs,你就会知道它有多么美妙.

3.怎么用

这里只讲个大概,教程随便google就一打.

所有的模块几乎(下面会讲为什么不是全部)都被define(function(require,exports,module){})这个全局函数包围,require参数用于表明被依赖模块,exports和module用于输出接口,让别的模块可以调用.对于开发者,按照它的规范写代码,就能很好的管理依赖了.

 

现在来讲,上面那个"几乎".其实也是后来看aralejs(aralejs是基于seajs的组件库,其开放程度可以用包罗万象来形容,具体可自行google)上的模块才发现的(只是个别模块这样做).

 

对于我们后来写成的模块,seajs官网是推荐上面那种方式的,而且也没有什么问题.之前随着requireJS的推出,一些开源的类库或者框架(比如jquery,backbone等)都纷纷加入了requireJS的行列,后续的新版本默认支持AMD模块规范.这些开源代码为了兼容页面上有无requireJS的情况,并没有将所有代码都包在define函数中,而是判断页面中是否定义了define函数进行模块定义,类似于下面这样

1 if ( typeof define === "function" && define.amd && define.amd.jQuery ) {
2 
3  define( "jquery", [], function () { return jQuery; } );
4 
5 }

而arale或者说seajs官方的做法是,可能为了兼容AMD,将其改成了

1 if ( typeof define === "function" ) {
2 
3  define("jquery/jquery/1.7.2/jquery-debug", [], function () { return jQuery; } );
4 
5 }

可能有其他更特殊的原因吧,还有json的模块更简单,直接在最后追加

1 define("gallery/json/1.0.3/json-debug", [], function() {
2 
3     return window.JSON;
4 
5 });

而underscore和bockbone就是按照"标准",在最外层包上define.不是特别清楚为什么有这么些个做法.可以再看看其他被包装过的模块的都是什么样子的.

4.seajs的原理

这个可以参考我之前的文章(差不多一年前了囧,现在才来写这篇) : http://www.cnblogs.com/webstone/articles/3043119.html

5.引出下一节

其实说到这里,seajs以及它的模块都可以在浏览器里正常运行.那么为什么还要有spm呢? 且继续往下看

二.spm部分

1.spm由来:

各个模块开发测试完毕后,为了进一步提升页面性能,我们还要对代码进行压缩,合并操作.

于是问题产生了.

为什么压缩后,被依赖的模块不加载了?

为什么合并后的模块一个都不执行了?(新版本不执行任何操作,1.3.1及以前会只执行第一个模块)

 

对于第一个问题,这涉及到seajs模块依赖处理的原理,对于第一节中谈到的模块组织方式define(factory),seajs寻找依赖是依靠正则判断factory.toString()中的require关键字,如下代码片段

 1 var REQUIRE_RE = /"(?:\"|[^"])*"|'(?:\'|[^'])*'|/*[Ss]*?*/|/(?:\/|[^/
])+/(?=[^/])|//.*|.s*require|(?:^|[^$])requires*(s*(["'])(.+?)1s*)/g;
 2 
 3 ...
 4 
 5 function parseDependencies(code) {
 6 
 7   var ret = []
 8 
 9  
10 
11   code.replace(SLASH_RE, "")
12 
13       .replace(REQUIRE_RE, function(m, m1, m2) {
14 
15         if (m2) {
16 
17           ret.push(m2)
18 
19         }
20 
21       })
22 
23  
24 
25   return ret
26 
27 }
28 
29 …
30 
31 // Parse dependencies according to the module factory code
32 
33   if (!isArray(deps) && isFunction(factory)) {
34 
35     deps = parseDependencies(factory.toString())
36 
37   }

而代码经过压缩后,require就不见了,自然就找不到依赖了.还有就是,这种依赖分析很消耗性能.

 

第二个问题,涉及到模块标识问题.其实上述的模块组织方式称为"匿名模块".多个没有名字的模块合并到一起后,各自都返回了输出接口,那么对于这个"大模块",应该返回哪一个接口呢?所以理想情况下每个模块都需要一个模块标识,这样就可以任何合并了.

 

其实seajs支持两种规范:

第一种就是第一节中的那种,叫做CMD规范,即define(factory)只传入一个callback.

第二种是给define传入三个参数define(id, deps, factory),id为模块标识,reps为依赖模块数组,第三个factory同上面那个factory.

这种模块属于 Modules/Transport 规范 ,参考https://github.com/seajs/seajs/issues/242 

 

第二种方式下,seajs的工作原理略有不同.它不再对factory进行正则依赖分析,直接加载deps中的依赖模块(数组中的字符串即模块标识,要与被依赖模块的id相匹配,或者与seajs.config别名中的映射后相匹配),这样一来,依赖处理的速度更快了,同时所有模块均可以任意压缩合并.

另外,路径与模块标识的问题可以参考这篇文章: https://github.com/seajs/seajs/issues/930 

 

所以呢,为了使CMD模块(也即匿名模块),更加便于管理,包括模块的压缩,合并,打包,部署,甚至公用下载安装,spm就应运而生了.

2.spm是什么,能做什么

spm是CMD模块管理器,就像npm,其实spm本身就是nodejs的一个模块,负责CMD模块的打包发布删除等操作.当然对外输出的模块已经不是CMD模块了,是 Modules/Transport 模块.

 

接着要说的是spm的源,就像npm有个代码集中管理的地方,甚至svn的代码仓库也有些类似.

 

当然,这个源可以是官方默认的https://spmjs.org/ ,也可以是私有源,搭建方法参考:https://github.com/spmjs/spm-yuan,然后需要通过修改配置文件中的soucre值来将spm的源地址改为私有源(默认为官方)

 

然后我们就可以开发我们的模块了.个人认为,最终生成的模块不一定要发布到源上.具有公共特性的组件类的模块才需要放到源上,业务模块放到项目中就好.只是build出来的id会看起来比较怪异,因为必须要与加载的路径一致.

3.spm的主要功能

nodejs和spm及其插件的安装这里就不说了,也是google一大把

我们从使用的角度,按开发顺序走下来

A.如果是开发一个公用组件,将来是要上传到spm源的模块,可以这么干(这种情况,除了源配置,我们暂时使用默认的配置信息):

1)spm init

打开终端,进入你将要开发组件的那个目录,执行

spm init

然后,spm为你生成一个基本目录结构,像下面这样

{{newModuleName}}/                                                //这一层是你执行spm init前创建的

        src/

                {{newModuleName}}.js 

                {{newModuleName}}.css 

        examples/ 

                index.md 

        tests/

                {{newModuleName}}-spec.js        

        dist/                                //这一层现在不会有,后面build完会出现,输出的文件在这一层下 

        README.md 

        HISTORY.md 

        package.json  

         

然后你就可以在src下的js和css里开发组件了,这两个文件初始化了一小部分代码,在src下你可以自由创建文件夹与其他js,css甚至模板文件等,用于被依赖

2)spm build

 

组件开发完成后,在终端下,同样是在上一步的目录下,执行

spm build

然后,就生成了上一步看到的dist目录,下面有打包好的具名模块,其中如果有依赖,默认是会被打包进来的

3)接着开始测试模块

官网说,spm test以及spm totoro都是支付宝内部才能使用的插件,不推荐外部使用,我还没有深入研究过.

所以呢,我们只能暂时自己创建测试环境,不过也不太麻烦啦

4)spm publish

测试通过后,我们就可以把它发布到源上了,就像nodejs模块可以通过npm发布一样.

在终端,同样的目录下执行

spm login

按照提示,登陆你的源账号,如果没有账号则按照提示创建账号登陆

接着执行

spm publish

如果没有意外,就可以发布成功了

打开浏览器,访问你的源地址,就能看到你刚刚发布的模块了

其他同学就可以通过spm install {{family}}/{{moduleName}} 安装(即下载)你发布的模块了

 

B.如果是开发业务模块,按照我个人的观点,业务模块不需要被发布到源上,或者说不需要和公用组件放在一块

 

这里我想起一个误区,而且我之前就一直是这么认为的:

"源上的模块是可以被http访问到的"

走出误区:简单讲,源只是一个存储模块文件的地方,不提供模块的web服务.于是就有了"部署"这件事情.但是spm deploy也是支付宝内部插件,我也没深入研究.

通常大型项目,静态资源文件与应用服务是分离的,也即模块文件是存放在另一台服务器上的.

但是小型项目,放在一起也基本能够满足需求.

但好像没有看到有人将公用模块与业务模块分离的.经过个人简单试验,这样是行的通的,并打算应用在项目中.

 

之前一直在探索如何使用spm构建业务模块,但总找不到合适的资料,尤其是它要求的目录结构以及生成的id让我束手无策.后来看到有大牛使用grunt-cmd-transport构建模块,自己跟着试了一下,的确可行.但似乎有些问题,比如:依赖的css没有被打包进来.在咨询了官方的人员后,并没有给出我这些问题的答案,而是建议我用spm,并给出了一些方案.我又重新拿起spm开始尝试.终于研究出了可行的方案,相对公用组件的开发方式,只需要修改package.json中的一些配置即可,而grunt的配置实在太多,看的人眼花.再次感谢支付宝贯高(github @popomore)给我的建议

 

由于需要比较多的笔墨,我将在下一篇讲述如何使用spm构建业务模块.