很好的前端模块化科普文

这是一篇关于js模块化历程的长长的流水账,记录js模块化思想的诞生与变迁,展望ES6模块化标准的未来。经历过这段历史的人或许会感到沧桑,没经历过的人也应该知道这段历史。

无模块时代

在ajax还未提出之前,js还只是一种“玩具语言”,由Brendan Eich花了不到十天时间发明,用来在网页上进行表单校验、实现简单的动画效果等等,你可以回想一下那个网页上到处有公告块飘来飘去的时代。

这个时候并没有前端工程师,服务端工程师只需在页面上随便写写js就能搞定需求。那个时候的前端代码大概像这样:

JavaScript
1 2 3 4 5 6 7 8 9 10 11 12 if ( xx ) {      //....... } else {      //xxxxxxxxxxx } for ( var i = 0 ; i < 10 ; i ++ ) {      //........ } element . onclick = function ( ) {      //....... }

代码简单的堆在一起,只要能从上往下依次执行就可以了。

模块萌芽时代 2006年,ajax的概念被提出,前端拥有了主动向服务端发送请求并操作返回数据的能力,随着Google将此概念的发扬光大,传统的网页慢慢的向“富客户端”发展。前端的业务逻辑越来越多,代码也越来越多,于是一些问题就暴漏了出来: 1. 全局变量的灾难 小明定义了 i=1 小刚在后续的代码里:i=0 小明在接下来的代码里:if(i==1){…} //悲剧 2. 函数命名冲突 项目中通常会把一些通用的函数封装成一个文件,常见的名字有utils.js、common.js… 小明定义了一个函数:function formatData(){   } 小刚想实现类似功能,于是这么写:function formatData2(){   } 小光又有一个类似功能,于是:function formatData3(){   } …… 避免命名冲突就只能这样靠丑陋的方式人肉进行。 3. 依赖关系不好管理 b.js依赖a.js,标签的书写顺序必须是
1 2 type = "text/javascript" src = "a.js" > type = "text/javascript" src = "b.js" >

顺序不能错,也不能漏写某个。在多人开发的时候很难协调。

萌芽时代的解决方案: 1. 用自执行函数来包装代码 JavaScript
1 2 3 4 5 6 7 8 9 10 11 modA = function ( ) {      var a , b ; //变量a、b外部不可见      return {            add : function ( c ) {                a + b + c ;            } ,            format : function ( ) {                //......            }      } } ( )

这样function内部的变量就对全局隐藏了,达到是封装的目的。但是这样还是有缺陷的,modA这个变量还是暴漏到全局了,随着模块的增多,全局变量还是会越来越多。

2. java风格的命名空间 为了避免全局变量造成的冲突,人们想到或许可以用多级命名空间来进行管理,于是,代码就变成了这个风格: JavaScript
1 2 3 app . util . modA = xxx ; app . tools . modA = xxx ; app . tools . modA . format = xxx ;

Yahoo的YUI早期就是这么做的,调用的时候不得不这么写:
JavaScript
1 app . tools . modA . format ( ) ;

这样调用函数,写写都会觉得恶心,所以这种方式并没有被很多人采用,YUI后来也不用这种方式了。

3. jQuery风格的匿名自执行函数 JavaScript
1 2 3 4 5 ( function ( window ) {      //代码      window . jQuery = window . $ = jQuery ; //通过给window添加属性而暴漏到全局 } ) ( window ) ;

jQuery的封装风格曾经被很多框架模仿,通过匿名函数包装代码,所依赖的外部变量传给这个函数,在函数内部可以使用这些依赖,然后在函数的最后把模块自身暴漏给window。

如果需要添加扩展,则可以作为jQuery的插件,把它挂载到$上。 这种风格虽然灵活了些,但并未解决根本问题:所需依赖还是得外部提前提供、还是增加了全局变量。

 

模块化面临什么问题 从以上的尝试中,可以归纳出js模块化需要解决那些问题: 1. 如何安全的包装一个模块的代码?(不污染模块外的任何代码) 2. 如何唯一标识一个模块? 3. 如何优雅的把模块的API暴漏出去?(不能增加全局变量) 4. 如何方便的使用所依赖的模块? 围绕着这些问题,js模块化开始了一段艰苦而曲折的征途。 源自nodejs的规范CommonJs 2009年,nodejs横空出世,开创了一个新纪元,人们可以用js来编写服务端的代码了。如果说浏览器端的js即便没有模块化也可以忍的话,那服务端是万万不能的。 大牛云集的CommonJs社区发力,制定了Modules/1.0( http://wiki.commonjs.org/wiki/Modules/1.0)规范,首次定义了一个模块应该长啥样。具体来说,Modules/1.0规范包含以下内容:
1. 模块的标识应遵循的规则(书写规范) 2. 定义全局函数require,通过传入模块标识来引入其他模块,执行的结果即为别的模块暴漏出来的API 3. 如果被require函数引入的模块中也包含依赖,那么依次加载这些依赖 4. 如果引入模块失败,那么require函数应该报一个异常 5. 模块通过变量exports来向往暴漏API,exports只能是一个对象,暴漏的API须作为此对象的属性。
此规范一出,立刻产生了良好的效果,由于其简单而直接,在nodejs中,这种模块化方案立刻被推广开了。 遵循commonjs规范的代码看起来是这样的:(来自官方的例子) JavaScript
1 2 3 4 5 6 7 8 //math.js exports . add = function ( ) {      var sum = 0 , i = 0 , args = arguments , l = args . length ;      while ( i < l ) {          sum += args [ i ++ ] ;      }      return sum ; } ;

JavaScript
1 2 3 4 5 //increment.js var add = require ( 'math' ) . add ; exports . increment = function ( val ) {      return add ( val , 1 ) ; } ;

JavaScript
1 2 3 4 //program.js var inc = require ( 'increment' ) . increment ; var a = 1 ; inc ( a ) ; // 2

服务端向前端进军 Modules/1.0规范源于服务端,无法直接用于浏览器端,原因表现为: 1. 外层没有function包裹,变量全暴漏在全局。如上面例子中increment.js中的add。 2. 资源的加载方式与服务端完全不同。服务端require一个模块,直接就从硬盘或者内存中读取了,消耗的时间可以忽略。而浏览器则不同,需要从服务端来下载这个文件,然后运行里面的代码才能得到API,需要花费一个http请求,也就是说,require后面的一行代码,需要资源请求完成才能执行。由于浏览器端是以插入

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部