万神劫

万物天地为剑,神鬼妖邪为剑
劫波万渡,宇宙苍穹尽为剑
是为万神劫!

46条评论 2012-09-25

Why SeaJS

前言

本文主要面向刚接触 SeaJS 的同学。
文章会先提出传统 Javascript 开发上遇到的一些难以解决的问题(即“冲突”与“依赖”两节),然后介绍如何使用 SeaJS 来解决这些难点(即 “Why SeaJS” 一节)。
实际上,如果你想了解 RequireJS 等其他模块加载器,也可以阅读本文

冲突

我们从一个最简单的例子开始
以前我做项目时,常常会将一些通用的、底层的功能抽出来,独立成一个函数,比如

function print(str) {
    // 代码!
};

然后像模像样的将这个函数丢到 util.js 里面,最后告诉大家:你们想用 xx 功能时候,引入 util.js 就行啦
这是一个很好的习惯(嘻嘻),但是项目做久了,难免会遇到问题,比如常有人问我:

  • 你这个函数为啥叫 print 啊!正好我也刚写了个函数叫 print 啊!要不我改名叫 print2 吧!(我靠……)
  • 你这个函数为啥叫 print 啊!我引入了个开源的模块,里面也有个函数叫 print 啊!改人家的怕有问题,要不改你的吧!(我再靠……)

在没有命名空间的 Javascript 中,发生这样的情况一点都不奇怪,幸亏有补救方案,可以用对象模拟命名空间

var FocusTech = {};
FocusTech.print = function(str){
    // 代码!
}

这样需要调用这个函数时,得带上命名空间 FocusTech.print(‘我是字符串啊’)
虽然麻烦一点,不过能降低函数命名冲突的概率,可惜也只是降低而已
比如这里我选择了用公司名字作为命名空间,但是我们公司几百号研发人员,跟我一样想法的人肯定大有人在
所以命名空间依然有可能会冲突。那么为了继续降低冲突概率,只好拉长命名空间,比如学 Java 用项目的网址做命名空间
下面这段代码节选自 Yahoo! 的一个开源项目

if (org.cometd.Utils.isString(response)) {
    return org.cometd.JSON.fromJSON(response);
}
if (org.cometd.Utils.isArray(response)) {
    return response;
}

看到这里我其实还是挺同情他们的,为了避免冲突用了那么长一个命名空间,对记忆和书写的负担实在太重了
好了,冲突的问题暂且放着,我们继续往下看

依赖

继续讲简单的例子,我开始编写一个通用的展示组件,提供给项目组使用,这样其他同学就不用重复造轮子了
我告诉大家:组件写在 componet_one.js 中,你们要用的时候引入一下就行啦
于是另一位同学就这么做了:

<script src="componet_one.js"></script>
<script>
  FocusTech.ComponetOne.init();
  // 代码!
</script>

看上去很好,可是报错了!
我赶紧查找原因,发现原来是我的组件中,调用了上面一个例子中提供的 print 方法,而页面中没有引入 util.js ,赶紧加上!

<script src="util.js"></script>
<script src="componet_one.js"></script>

很快就修复了,看上去好像挺简单的,不过让我们看看这个例子的后续发展:

  • 某天,我扩充了组件的功能,除了需要 util.js 之外,还需要 ooxx.js

这时候,项目中已经有 N 个地方用到了我的组件……
于是我只好全局搜索每一个调用的地方,都给页面加上对 ooxx.js 的引用

  • 某天,需求砍掉了组件上的一个交互效果

我修改了 componet_one.js 的代码,然后发现我不再需要 util.js 中提供的 print 方法了
于是我再次全局搜索每一个调用的地方,去掉对 util.js 的引用

  • 测试同学告诉我,改完之后,好多个页面报错!

我赶紧检查,发现有些页面上是这样的

<script src="ooxx.js"></script>
<script src="componet_one.js"></script>
<script src="componet_two.js"></script>

页面还引入了 componet_two.js ,而且 componet_two.js 中用到了 util.js 的 print 方法!
所以 BUG 原因找到了,我不能武断地把 util.js 全都去掉,而是需要仔细检查页面上的其他的 JS 文件或代码是否需要它!
崩溃……

  • 一段时间后,测试同学又来找我,说页面又报错了!

再次检查,发现原来是某人动过了 ooxx.js ,在里面调用了 util.js 的方法……害死人不偿命啊!
好吧,我只好再次全局搜索所有使用到 componet_one 组件的地方,给页面加上 util.js 的引用

小结

我已经不忍心再讲下去了,正所谓:看到哪句你哭了,不顶不是中国人!
相信做过大一点项目的同学,应该都遇到过上面的这种破事。
为什么会这么费神呢?因为 javascript 的语法中天生缺少引入其他 JS 文件的语法。
相比之下,我们的好战友设计师们就轻松很多了,比如:

@import url("base.css");

#test {...}
.classA {...}
.classB {...}

看到吧,人家只要用一个 @import 就解决了,页面中引入 css 时,只需要引入这个 css ,浏览器会自动去下载 base.css
css 文件的依赖能够实现自动管理,而不是像 js 一样,需要手动地去编写

OK,下面终于可以进入重点了

Why SeaJS

先不谈理论,直接来看看上面的这两个例子中如果引入 SeaJS 该怎么写
首先是 util.js ,我们改用 SeaJS 的 CMD 规范来书写

define(function (require, exports) {
    function print(str) {
        // ...代码
    }

    exports.print = print;
});

可以看到,其实改变并不大,主要是外部包裹了一层,再加最后多写了一行
最后这行很重要,通过它,文件对外提供一个叫做 print 方法的接口
另外大家发现没,这里我没有使用命名空间,为什么呢?看下面的 componet_one.js

define(function (require, exports) {
    var util = require('./util.js');

    var ComponetOne = {
        doSth : function() {
            util.print('我是字符串');
            // ...代码
        }
    }

    return ComponetOne;
});

高潮终于到了!
首先是 var util = require('./util.js'); 这句,有没有觉得很熟悉?是不是很像上面提到的 @import url("base.css");
没错!这里的 require 可以认为是 SeaJS 给 Javascript 增加的一个关键词语法,就像 @import 这个关键词一样!

通过这个函数,SeaJS 赋予了 Javascript 直接加载 js 文件的功能,并且这个函数是 同步 的!
函数直接就有一个返回值,那么返回值是什么呢?相信你已经猜到了,就是 util.js 里面的 exports 对象
所以下面我们就可以使用 util.print() 来调用 util.js 提供的对外接口了

刚才那个问题有答案了:因为 require 函数的返回值赋值给哪个变量完全由 componet_one 决定,变量名可以随便起,与 util.js 毫无关系(这里为了方便变量也叫 util ),所以 util.js 里面自然就不需要命名空间了!

那么页面中该怎么引入呢?很简单

<script src="sea.js"></script>
<script>
seajs.use('./componet_one.js')
</script>

我们需要先引入 SeaJS 这个加载器,然后通过它提供的 API 来加载文件
而且最重要的是:因为有了 require ,这里我们只需要加载 componet_one.js 即可,util.js 会由 SeaJS 自动加载!
也就是说,因为有了 require ,我们获得了类似 css 的文件依赖自动管理机制!

小结

仔细琢磨一下这几行代码,我想大家应该能看出 SeaJS 带给 Javascript 开发的巨大好处:

  • 一般来说,不再需要冗长的命名空间了,也不再需要担心命名的冲突
  • 不需要手动管理 js 文件的依赖,依赖关系写在代码中,SeaJS 会自动处理

别小看这两点,对于稍微有些规模的项目来说它们非常重要,我想这也是 SeaJS 备受青睐的原因。
最后,SeaJS 的 CMD 规范非常简单易懂,SeaJS 的 API 也非常简洁优雅,相信有一定开发经验的同学很快就能上手
更多信息可以移步 SeaJS官网

comments powered by Disqus