JavaScript之无题之让人烦躁的模块化

  我怎么记得我好像写过相关类型的文章,但是我找遍了我的博客没有~那就再写一遍吧,其实模块化的核心内容也算不上是复杂,只不过需要整理一下,规划一下罢了。嘻嘻。

  开始写标题的时候我就在纠结一件事情,就是,先吃喜欢吃的,还是后吃喜欢吃的,翻译过来就是我应该先写CommonJS和ES6 Module,还是先写CMD和AMD。嗯,我决定了,谁先做好了我就先吃谁

  其实模块化的缘由很简单,就一句话,不对,就一个词,两个字,分类。如果一定让我在加一点,那应该是“隔离”。没了~~但是这么少不太好,我举个可能不那么恰当的例子吧。

  刚开始这个世界上只有三个人,起名字的时候会“刻意”的避开彼此已经叫过的名字,他们在一起生活,日子欣欣向荣,一片美好,对未来充满了期待。

  时间飞逝,三个人变成了三十人,他们勉强还是住在一起,起名字的时候虽然费事一点,但是也还能不重复,日子还是欣欣向荣,一片美好,对未来充满了期待。

  时间又飞逝,三十人变成了三百人,那这不太好管理了,于是三位首领就说,你们有领导能力的几个人站出来,组成各自的部落,去吧,我相信你们可以的。于是每个部落住在一起,部落与部落之间的人可以重名,叫名字的时候再加上一个部落的名称呗,嗯~又一片欣欣向荣。

  时间继续飞逝,三百人变成了三千人,这三千人住在几个大部落里也很不方便,你拿我的苹果,我偷了你得猪,这肯定不行,有碍于社会的稳定发展,于是三个创始者叫上部落的组长说,我们给每个人分一块地,盖一个房子,把三五个人分割成一个家庭,家庭之间由部落作为纽带,关联彼此,在形式上又相互独立,不可以随便拿别家的苹果。很完美~

  时间飞飞飞飞逝,三千人变成了三百万人……我们需要法律了。

  OK,上面的小例子,人,就是函数,部落就是命名空间,房子就是IIFE,法律就是后续发展的模块化规范。那么我们依照上面的描述,如何转换成代码?

一、社会的起源与法律的雏形

  最开始的时候,浏览器只需要简单的图文展示就是可以了,没什么复杂的交互和逻辑的处理,所以,当我们只有三个人的时候,我们可以很自由,很随意:

function a(){}  function b(){}

  随着Web的发展,交互的增多,项目的扩大,很容易有人也声明了同样名称的函数,于是纷争开始了,那咋解决纷争呢?嗯,命名空间也就是拆分部落,就像这样:

var zaking1 = {     a:function(){},     b:function(){} } var zaking2 = {     a:function(){},     b:function(){} }

  但是这样并不能真正的解决问题,因为虽然从形式上区分了部落,但是部落之间没有任何的隔离,部落内部也是混乱的,所以各个首领就制定了一个方案,IIFE,利用闭包的特性,来实现数据的隔离,暴露出对外的入口:

var module = (function () {     var name = "zaking";     function getName() {     console.log(name);     }     return { getName }; })(); module.getName();

  我们盖好了房子,还给房子建好了可以出入的门,但是我怎么邀请别人进来呢?

var module = (function (neighbor) {     var name = "zaking";     function getName() {     console.log(name + "和邻居:" + neighbor);     }     return { getName }; })("xiaowangba"); module.getName();

  传个参数呗,这就是依赖注入。在这个阶段,最有代表性的就是jQuery了,它的封闭性的核心实现,跟上面的代码几乎无异,我们可以看下jQuery的模块的实现:

(function (global, factory) {   factory(global); })(typeof window !== "undefined" ? window : this, function (window, noGlobal) {   if (typeof noGlobal === "undefined") {     window.jQuery = window.$ = jQuery;   }   return jQuery; });

  当然我这里略了很多,你看它,无非就是一个闭包,传入了window和jQuery本身,然后再绑定到window上,这样,我们就只能访问到暴露出来的$以及$上的方法和属性,我们根本无法修改内部的数据。

  OK,到了这个阶段,其实算是一个转折点,我们有了初步的法律,还需要后续针对法律的完善,

二、法律的初现与CommonJs

  随着社会的发展,出现一种规则已成必然,于是commonJs统领举起模块化的大旗,让JavaScript迈向了另一个阶段。commonJs最初由 JavaScript 社区中的 Mozilla 的工程师Kevin Dangoor在Google Groups中创建了一个ServerJs小组。该组织的目标是为web服务器、桌面和命令行应用程序以及浏览器构建JavaScript生态系统。嗯,它的野心很大~,后来,他就就把ServerJs改成了commonJs,毕竟ServerJs的范围有点小,commonJs更符合他们的初衷。

  而后,在同一年的年底,NodeJs出现了,Javascript不仅仅可以用于浏览器,在服务器端也开始攻城略地。NodeJs的初衷是基于commonJs社区的模块化规范,但是NodeJs并没有完全遵循于社区的一些腐朽过时的约束,它实现了自己的想法。

  commonJs规范的写法,如果大家写过NodeJs一定都有所了解,大概是这样的:

// a.js module.exports = 'zaking' // b.js const a = require("./a"); console.log(a); // zaking

  看起来挺简单的,但是这里隐藏了一些不那么容易被理解的特性。

  在NodeJs中,一个文件就是一个模块,有自己的作用域,在一个文件里面定义的函数、对象都是私有的,对其他文件不可见。并且,当第一次加载某个模块的时候,NodeJ会缓存该模块,待再次加载的时候,会直接从模块中取出module.exports属性返回。比如:

// a.js var name = "zaking"; exports.name = name;  // b.js var a = require("./a.js"); console.log(a.name); // zaking a.name = "xiaoba"; var b = require("./a.js"); console.log(b.name); // xiaoba

  诶?为啥你写的是“exports.”,不是module.exports?NodeJs在实现CommonJs规范的时候为了方便,给每个模块都提供了一个exports私有变量,指向module.exports。有一点要尤其注意,exports 是模块内的私有局部变量,它只是指向了 module.exports,所以直接对 exports 赋值是无效的,这样只是让 exports 不再指向 module.exports了而已。

  我们回到上面的代码,按理来说,我第二次引入的b的name应该是“zaking”啊。但是实际上,在第一次引入之后的引入,并不会再次执行模块的内容,只是返回了缓存的结果。

  另外一个核心的点是,我们导入的是导出值的拷贝,也就是说一旦引入之后,模块内部关于该值的变化并不会被影响。

// a.js var name = "zaking"; function changeName() {   name = "xiaowangba"; } exports.name = name; exports.changeName = changeName;  // b.js var a = require("./a.js"); console.log(a.name); // zaking a.changeName(); console.log(a.name); // zaking

  嗯,一切看起来都很不错。

三、争奇斗艳,百家争鸣

  在上一小节,我们简单介绍了模块化的始祖也就是CommonJs以及实现了该规范的NodeJs的一些核心内容。但是NodeJs的实现的一个关键的点是,它在读取或者说加载模块的时候是同步的,这在服务器没什么问题,但是对于浏览器来说,这个问题就很严重,因为大量的同步模块加载意味着大量的白屏等待时间。

  基于这样的问题,从CommonJs中独立出了AMD规范。

1、AMD规范与RequireJs

  AMD,即Asynchronous Module Definition,翻译过来就是异步模块化规范,它的主要目的就是解决CommonJs不能在浏览器中使用的问题。但是RequireJs在实现上,希望可以通吃,也就是可以在任何宿主环境下使用。

  我们先来看个例子:

<!DOCTYPE html> <html lang="en">   <head>     <meta charset="UTF-8" />     <meta http-equiv="X-UA-Compatible" content="IE=edge" />     <meta name="viewport" content="width=device-width, initial-scale=1.0" />     <title>Document</title>   </head>   <script src="https://requirejs.org/docs/release/2.3.6/comments/require.js"></script>   <body></body>   <script>     require(["./a"]);   </script> </html>

  然后,我们的a.js是这样的:

define(function () {   function fun1() {     alert("it works");   }    fun1(); });

  define用来声明一个模块,require导入。我们还可以这样:

require(["./a"], function () {   alert("load finished"); });

  导入前置依赖的模块,在第二个参数也就是回调中执行。RequireJs会在所有的模块解析完成后执行回调函数。就算你倒入了一个没有使用的模块,RequireJs也一样会加载:

<!DOCTYPE html> <html lang="en">   <head>     <meta charset="UTF-8" />     <meta http-equiv="X-UA-Compatible" content="IE=edge" />     <meta name="viewport" content="width=device-width, initial-scale=1.0" />     <title>Document</title>   </head>   <script src="https://requirejs.org/docs/release/2.3.6/comments/require.js"></script>   <body></body>   <script>     require(["./a", "./b"], function (a, b) {       a.fun1();     });   </script> </html>

  然后分别是a.js和b.js:

// a.js define(function () {   function fun1() {     alert("it works fun1");   }    return {     fun1: fun1,   }; });  // b.js define(function () {   function fun2() {     alert("it works fun2");   }    return {     fun2: fun2,   }; });

  结果大家可以试一试~

  以上就是RequireJs的简单用法,我们据此知道了两个核心内容,RequireJs基于AMD规范,RequireJs会加载你引入的所有模块,哪怕你并不会真的用到它。

2、CMD规范与SeaJs

  由于RequireJs的一些问题,又出现了基于CMD规范的SeaJs,SeaJs和RequireJs有一个最大的不同就是RequireJs希望可以通吃,但是SeaJs则更专注于浏览器,哦对了,CMD的全称叫做:Common Module Definition,即通用模块规范。

  SeaJs的简单用法如下:

// 所有模块都通过 define 来定义 define(function(require, exports, module) {    // 通过 require 引入依赖   var a = require('xxx')   var b = require('yyy')    // 通过 exports 对外提供接口   exports.doSomething = ...    // 或者通过 module.exports 提供整个接口   module.exports = ...  }) // a.js define(function(require, exports, module){     var name = 'morrain'     var age = 18      exports.name = name     exports.getAge = () => age }) // b.js define(function(require, exports, module){     var name = 'lilei'     var age = 15     var a = require('a.js')      console.log(a.name) // 'morrain'     console.log(a.getAge()) //18      exports.name = name     exports.getAge = () => age })

  上面的代码是从网上抄的,大概说明白了基本的使用方法。我们可以看到,SeaJs的导入和导出的方式,跟NodeJs好像~~而SeaJs从书写形式上,更像是CommonJs和AMD的结合。当然,我只是说书写形式上。

  而AMD和CMD,RequireJs和SeaJs,都是由社区发起的,并没有语言层面的规范,包括CommonJs以及NodeJs,所以,这个时代还是一个百花争艳,没有统一的时代,不过在现在,这些都不重要了。如果非要我说些什么,那就是,忘记这两个东西,去学下面的重点。

四、大一统

  百花争艳的时代确实有些烦人,这个那个那个这个,又都不被官方认可,还好,官方终于还是出手了,ES6的出现,在语言层面上就提出了对于模块化的规范,也就是ES6 Module。它太重要了,具体语法我就不多说了,文末的链接附上了阮一峰大神的《ES6入门指南》关于ES6 Module的地址。

  所以到了ES6的时候,你要学习的就是ES6 Module,NodeJs也在逐步实现对ES6 Module的支持。最终,秦始皇会一统天下,这是必然的结果。

  这篇文章到这里就结束了,说实话,模块化的问题和历史由来已久,从萌芽到统一,至少十几年的过程,而市面上也已有大量的文章介绍彼此的区别和各自的特点,我写来写去,也不过是复制一遍,毫无意义。

  但是我又想学一下模块化,以及模块化的历史,额……,请原谅我的无知,所以才有了这篇文章,但是写着写着,发现我能表达出来的东西并不多,因为都是故事,都是历史,并且对于未来的开发好像也没什么实际的意义和价值。

  所以,在如此纠结的心态下有了这篇文章,原谅我无知又想逼逼的心情吧。

  最后的最后,如果你想学习模块化,在现阶段,只需要去深入学习ES6 Module,和学习一下NodeJs的CommonJs,以及了解一下各模块化的区别即可,因为现在是即将统一,还未完全统一的时候。

 

参考资料:

  https://wiki.commonjs.org/wiki/CommonJS

  https://github.com/seajs/seajs/issues/242

  https://es6.ruanyifeng.com/#docs/module

发表评论

相关文章