大佬教程收集整理的这篇文章主要介绍了一篇文章掌握RequireJS常用知识，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
本文采取循序渐进的方式，从理论到实践，从@R_262_10613@ireJS官方API文档中，总结出在使用@R_262_10613@ireJS过程中最常用的一些用法，并对文档中不够清晰具体的内容，加以例证和分析，分享给大家供大家参考，具体内容如下
这些代码的特点是：
当然这些代码本身在实现功能上并没有错误，但是从代码的可重用性，健壮性以及可维护性来说，这种编程方式是有问题的，尤其是在页面逻辑较为复杂的应用中，这些问题会暴露地特别明显：
所以当这些问题出现的时候，js大牛们就开始寻找去解决这些问题的究极办法，于是模块化开发就出现了。正如模块化这个概念的表面意思一样，它要求在编写代码的时候，按层次，按功能，将独立的逻辑，封装成可重用的模块，对外提供直接明了的调用接口，内部实现细节完全私有，并且模块之间的内部实现在执行期间互不干扰，最终的结果就是可以解决前面举例提到的问题。一个简单遵循模块化开发要求编写的例子：
if (!stuName || !courName) return;
current = data[stuName] = data[stuName] || [];
if (current.filter(_filter).length === 0) {
current.push(courName);
}
},list: function (stu) {
var stuName = stu && stu.getName(),current = data[stuName];
current && console.log(current.join(';'));
}
}
};
//main.js
var stu = new student('lyzg'),c = new controller();
c.add(stu,new course('javascript'));
c.add(stu,new course('html'));
c.add(stu,new course('css'));
c.list(stu);
以上代码定义了三个模块分别表示学生，课程和控制器，然后在main.js中调用了controller提供的add和list接口，为lyzg这个学生添加了三门课程，然后在控制台显示了出来。运行结果如下：
通过上例，可以看出模块化的代码结构和逻辑十分清晰，代码看起来十分优雅，另外由于逻辑都通过模块拆分，所以达到了解耦的目的，代码的功能也会比较健壮。不过上例使用的这种模块化开发方式也并不是没有问题，这个问题就是它还是把模块引用如student这些直接添加到了全局空间下，虽然通过模块减少了很多全局空间的变量和函数，但是模块引用本身还是要依赖全局空间，才能被调用，当模块较多，或者有引入第三方模块库时，仍然可能造成命名冲突的问题，所以这种全局空间下的模块化开发的方式并不是最完美的方式。目前常见的模块化开发方式，全局空间方式是最基本的一种，另外常见的还有遵循AMD规范的开发方式，遵循CMD规范的开发方式，和ECMAScript 6的开发方式。需要说明的是，CMD和ES6跟本文的核心没有关系，所以不会在此介绍，后面的内容主要介绍AMD以及实现了AMD规范的RequireJS。
所有遵循AMD规范的模块化工具，都必须按照它的要求去实现，比如RequireJS这个库，就是完全遵循AMD规范实现的，所以在利用RequireJS加载或者调用模块时，如果你事先知道AMD规范的话，你就知道该怎么用RequireJS了。规范的好处在于，不同的实现却有相同的调用方式，很容易切换不同的工具使用，至于具体用哪一个实现，这就跟各个工具的各自的优点跟项目的特点有关系，这些都是在项目开始选型的时候需要确定的。目前RequireJS不是唯一实现了AMD规范的库，像Dojo这种更全面的js库也都有AMD的实现。
最后对AMD全称做一个解释，译为：异步模块定义。异步强调的是，在加载模块以及模块所依赖的其它模块时，都采用异步加载的方式，避免模块加载阻塞了网页的渲染进度。相比传统的异步加载，AMD工具的异步加载更加简便，而且还能实现按需加载，具体解释在下一部分说明。
第1种异步加载的方式是直接利用脚本生成script标签的方式：
这段代码，放置在script标记内部，然后该script标记添加到body元素的底部即可。
第2种方式是借助script的属性：defer和async，defer这个属性在IE浏览器和早起的火狐浏览器中支持，async在支持html5的浏览器上都支持，只要有这两个属性，script就会以异步的方式来加载，所以script在html中的位置就不重要了：
这种方式下，所有异步js在执行的时候还是按顺序执行的，不然就会存在依赖问题，比如如果上例中的main.js依赖foo.js和bar.js，但是main.js先执行的话就会出错了。虽然从来理论上这种方式也算不错了，但是不够好，因为它用起来很繁琐，而且还有个问题就是页面需要添加多个script标记以及没有办法完全做到按需加载。
JS的按需加载分两个层次，第一个层次是只加载这个页面可能被用到的JS，第二个层次是在只在用到某个JS的时候才去加载。传统地方式很容易做到第一个层次，但是不容易做到第二个层次，虽然我们可以通过合并和压缩工具，将某个页面所有的JS都添加到一个文件中去，最大程度减少资源请求量，但是这个JS请求到客户端以后，其中有很多内容可能都用不上，要是有个工具能够做到在需要的时候才去加载相关js就完美解决问题了，比如RequireJS。
4.01 如何使用@R_262_10613@ireJS 使用方式很简单，只要一个script标记就可以在网页中加载@R_262_10613@ireJS：
由于这里用到了defer和async这两个异步加载的属性，所以@R_262_10613@ire.js是异步加载的，你把这个script标记放置在任何地方都没有问题。
4.02 如何利用@R_262_10613@ireJS加载并执行当前网页的逻辑JS
4.01解决的仅仅是@R_262_10613@ireJS的使用问题，但它仅仅是一个JS库，是一个被当前页面的逻辑所利用的工具，真正实现网页功能逻辑的是我们要利用@R_262_10613@ireJS编写的主JS，这个主JS（假设这些代码都放置在main.js文件中）又该如何利用RJ来加载执行呢？方式如下：
对比4.01，你会发现script标记多了一个data-main，RJ用这个配置当前页面的主JS，你要把逻辑都写在这个main.js里面。当RJ自身加载执行后，就会再次异步加载main.js。这个main.js是当前网页所有逻辑的入口，理想情况下，整个网页只需要这一个script标记，利用RJ加载依赖的其它文件，如jquery等。
4.03 main.js怎么写 假设项目的目录结构为：
html中按4.02的方式配置RJ。main.js的代码如下：
在这段JS中，我们利用RJ提供的@R_262_10613@ire方法，加载了三个模块，然后在这个三个模块都加载成功之后执行页面逻辑。@R_262_10613@ire方法有2个参数，第一个参数是数组类型的，实际使用时，数组的每个元素都是一个模块的module ID，第二个参数是一个回调函数，这个函数在第一个参数定义的所有模块都加载成功后回调，形参的个数和顺序分别与第一个参数定义的模块对应，比如第一个模块时lib/foo，那么这个回调函数的第一个参数就是foo这个模块的引用，在回调函数中我们使用这些形参来调用各个模块的方法，由于回调是在各模块加载之后才调用的，所以这些模块引用肯定都是有效的。
从以上这个简短的代码，你应该已经知道该如何使用RJ了。
4.04 RJ的baseUrl和module ID 在介绍RJ如何去解析依赖的那些模块JS的路径时，必须先弄清楚baseUrl和module ID这两个概念。
html中的base元素可以定义当前页面内部任何http请求的url前缀部分，RJ的baseUrl跟这个base元素起的作用是类似的，由于RJ总是动态地请求依赖的JS文件，所以必然涉及到一个JS文件的路径解析问题，RJ默认采用一种baseUrl + modulEID的解析方式，这个解析方式后续会举例说明。这个baseUrl非常重要，RJ对它的处理遵循如下规则：
上述三种方式，优先级由低到高排列。
data-main的使用方式，你已经知道了，config该如何配置，如下所示：
这个配置必须放置在main.js的最前面。data-main与config配置同时存在的时候，以config为准，由于RJ的其它配置也是在这个位置配置的，所以4.03中的main.js可以改成如下结构，以便将来的扩展：
@R_262_10613@ire(['lib/foo',app) {
// use foo bar app do sth
});
关于module ID，就是在@R_262_10613@ire方法以及后续的define方法里，用在依赖数组这个参数里，用来标识一个模块的字符串。上面代码中的['lib/foo','app/app']就是一个依赖数组，其中的每个元素都是一个module ID。值得注意的是，module ID并不一定是该module 相关JS路径的一部分，有的module ID很短，但可能路径很长，这跟RJ的解析规则有关。下一节详细介绍。
4.05 RJ的文件解析规则 RJ默认按baseUrl + module ID的规则，解析文件，并且它默认要加载的文件都是js，所以你的module ID里面可以不包含.js的后缀，这就是为啥你看到的module ID都是lib/foo,app/bar这种形式了。有三种module ID，不适用这种规则：
假如main.js如下使用：
@R_262_10613@ire(['/lib/foo','test.js','/js/jquery'],app) {
// use foo bar app do sth
});
这三个module 都不会根据baseUrl + module ID的规则来解析,而是直接用module ID来解析，等效于下面的代码：
各种module ID解析举例：
例1，项目结构如下：
@R_262_10613@ire(['lib/foo',app) {
// use foo bar app do sth
});
baseUrl为：scripts目录
@H_918_0@modulEID为：lib/foo,app/bar,app/app根据baseUrl + modulEID，以及自动补后缀.js，最终这三个module的js文件路径为：
例2，项目结构同例1：
@H_918_0@main.js改为：@R_262_10613@ire(['foo',app) {
// use foo bar app do sth
});
这里出现了一个新的配置paths，它的作用是针对module ID中特定的部分，进行转义，如以上代码中对app这个部分，转义为../app，这表示一个相对路径，相对位置是baseUrl所指定的目录，由项目结构可知，../app其实对应的是scirpt/app目录。正因为有这个转义的存在，所以以上代码中的app/bar才能被正确解析，否则还按baseUrl + modulEID的规则，app/bar不是应该被解析成scripts/lib/app/bar.js吗，但实际并非如此，app/bar被解析成scripts/app/bar.js，其中起关键作用的就是paths的配置。通过这个举例，可以看出R_471_11845@odule ID并不一定是js文件路径中的一部分，paths的配置对于路径过程的js特别有效，因为可以简化它的module ID。
另外第一个模块的ID为foo，同时没有paths的转义，所以根据解析规则，它的文件路径时：scripts/lib/foo.js。
paths的配置中只有当模块位于baseUrl所指定的文件夹的同层目录，或者更上层的目录时，才会用到../这种相对路径。
例3，项目结果同例1，main.js同例2：
这里要说明的问题稍微特殊，不以main.js为例，而以app.js为例，且app依赖bar，当然config还是需要在main.js中定义的，由于这个问题在定义模块的时候更加常见，所以用define来举例，假设app.js模块如下定义：
上面的代码通过define定义了一个模块，这个define函数后面介绍如何定义模块的时候再来介绍，这里简单了解。这里这种用法的第一个参数跟@R_262_10613@ire函数一样，是一个依赖数组，第二个参数是一个回调，也是在所有依赖加载成功之后调用，这个回调的返回值会成为这个模块的引用被其它模块所使用。
这里要说的问题还是跟解析规则相关的，如果完全遵守RJ的解析规则，这里的依赖应该配置成app/bar才是正确的，但由于app.js与bar.js位于同一个目录，所以完全可利用./这个同目录的相对标识符来解析js，这样的话只要app.js已经加载成功了，那么去同目录下找bar.js就肯定能找到了。这种配置在定义模块的时候非常有意义，这样你的模块就不依赖于放置这些模块的文件夹名称了。
4.06 RJ的异步加载 RJ不管是@R_262_10613@ire方法还是define方法的依赖模块都是异步加载的，所以下面的代码不一定能解析到正确的JS文件：