Home > Article > Web Front-end > Example of Require calling js in JavaScript
This article mainly brings you an example sharing of Require calling js in JavaScript. The editor thinks it’s pretty good, so I’ll share it with you now and give it as a reference. Let’s follow the editor to take a look, I hope it can help everyone.
When I first started writing JavaScript functions, it usually looked like this:
function fun1() { // some code here } function fun2() { // some other code here } ...
The functions are all written in the global environment. When the project is small, there are usually no conflicts.
But after there were too many codes, I gradually found that the function names (English vocabulary) were a bit insufficient. So the concept of namespace was introduced and modularized code began.
Function under the namespace
In the namespace, my code is written like this:
var com = com || {}; com.zfanw = com.zfanw || {}; com.zfanw.module1 = (function() { // some code here return { func1: func1, ... }; }()); com.zfanw.module2 = (function() { // some other code here return { func1: func1, ... }; }()); ...
In line with the object-oriented principle, when executing functions, I usually It should be written like this:
com.zfanw.module1.func1.apply({},['arg1',arg2]); ...
Of course, in order to save typing characters, I will also import 1 public API interface in the closure: www.jb51.net
(function($, mod1) { // some code here mod1.func1.apply({},['arg1',arg2]); }(jQuery, com.zfanw.module1)); ...
At this point, The possibility of code conflicts is already very small, but the problems of code dependency, multi-script file management, and blocking are gradually surfacing - the namespace method is starting to become urgent.
So Require.js2 appears.
Require.js
First understand the concept of module in require.js 3:
A module is different from a traditional script file in that it defines a well-scoped object that avoids polluting the global namespace. It can explicitly list its dependencies and get a handle on those dependencies without needing to refer to global objects, but instead receive the dependencies as arguments to the function that defines the module.
Simply put, there are two points. First, the module scope is self-contained and does not pollute the global space; second, the module specifies dependencies, and dependencies are imported through parameter passing without the need to reference global objects – dependencies also do not pollute. global space.
Define the module
Different from the old namespace method above, require.js uses the global method define to define the module, in the following form:
define(id?, dependencies?, factory); // ? 表示可选项
I Let’s divide the modules into two types.
Dependency-free module
If a module does not depend on other modules, it is very simple to define. For example, the module hello is placed in the hello.js file:
define(function() { // some code here return { // some public api }; });
Modules with dependencies
Modules with dependencies are a little more complicated. When defining, we need to list the dependencies of the module:
define(['jquery'], function($) { // 比如这个模块,代码的执行依赖 jQuery,require.js 会先加载 jquery 模块代码,并加以执行,然后将依赖模块 以 $ 的参数形式传入回调函数中,回调函数将执行结果注册为模块 // maybe some code here return { // some public api }; });
Here, dependencies are in progress The 'jquery' is the path to the module relative to baseUrl, equivalent to the module ID.
Now, go back and look at the code that imports the public API in the closure written above, and compare it with the define function:
(function($, mod1) { // some code here mod1.func1.apply({},['arg1',arg2]); }(jQuery, com.zfanw.module1));
In this code, I I also imported jQuery. In the closure, I also accessed jQuery through the $ external parameter. It can be said that its way of "defining dependencies" is very similar to the define method. The difference is that the jquery imported by define is not a global variable, so it will not pollute the global environment.
About module name
define function has three parameters. The first id is the module name. The format of this name is relative to the path of baseUrl excluding the file format. For example, baseUrl is the js directory, a The module is placed in js/libs/hi.js, then if the name is defined like this:
define('libs/hi', ['jquery'], function($){......});
The advantage of this definition form is that modules cannot conflict because files with the same name are not allowed in the same directory. But therefore require.js recommends that we not set the module name, because after setting the module name of 'libs/hi', the module must be placed in the hi.js file in the js/libs directory. If you want to move the location, the module name Follow the changes. As for the module name generated during later optimization using r.js, that is another matter.
Using modules
After defining various modules with "dependencies" and "no dependencies", how should we use them? Require.js provides a function, require (equivalent to requirejs).
require function loads dependencies and executes callbacks. Unlike define, it does not register the callback result 4 as a module:
require(['jquery'], function($) { // 这个函数加载 jquery 依赖,然后执行回调代码 console.log($); });
Give a simple example. I have a folder with the following file structure:
index.html js/ main.js require.js jquery.js
Here jquery.js has been registered as an AMD module, then require.js is referenced in the HTML file like this:
<script src="js/require.js" data-main="js/main"></script>
require.js will check data -main attribute value, here is js/main, according to the settings, it will load the main.js file in the js directory.
In the main.js file, I only do one thing, use the jQuery method to get the width of the current window:
require(['jquery'], function($) { var w = $(window).width(); console.log(w); });
It’s that simple to execute the code.
Non-AMD standard modules
But things are far from as good as we imagined. AMD is just a community specification, not a standard, and before it appeared, there were already various Popular libraries exist, not to mention our own early code, so we're bound to run into a bunch of non-AMD spec modules. In order to allow require.js to load them and automatically identify and load dependencies, we have two options. First, give them all a function called define; second, use the configuration option shim provided by Require.js to save the country. .
比如我手上一个项目,因为某种原因,还在用 jQuery 1.4.1 版本,而 jQuery 是从1.7版本开始才注册为 AMD 模块的,我要在 require.js 中使用,就需要先做 shim:
require.config({ shim: { 'jquery-1.4.1': { // <= 这个是相对于 main.js 的路径www.45it.com exports: 'jQuery' // <= 这个值需要稍加注意,稍后会提及 }, 'libs/jquery-throttle-debounce.min': { // <= jQuery 插件 deps: ['jquery-1.4.1'] //无需 exports,因为我们只是在增强 jQuery 功能 } }, }); require(['jquery-1.4.1', 'libs/jquery-throttle-debounce.min'], function($){ console.log($.debounce); });
写完 shim,发现 jquery-1.4.1、libs/jquery-throttle-debounce.min 这样的名称有点长。这里我们又有两种选择,一是直接打开修改 js 文件名,或者使用 require.js 提供的配置项 paths 给模块 ID 指定对应的真实文件路径:
require.config({ paths: { 'jquery': 'jquery-1.4.1', // <= 模块 jquery 指向 js/jquery-1.4.1.js 文件 'debounce': 'libs/jquery-throttle-debounce.min' }, shim: { 'jquery': { exports: '$' }, 'debounce': { deps: ['jquery'] } } }); require(['jquery', 'debounce'], function($){ console.log($.debounce); });
这样,引用起来就方便多了。
另外,需要注意 shim 中的 exports 项,它的概念更接近 imports,即把全局变量导入。我们如果把 exports 值改成非全局变量名,就会导致传入回调的对象变成 undefined,举个例子:
require.config({ paths: { 'jquery': 'jquery-1.4.1', }, shim: { 'jquery': { exports: 'hellojQuery' // 这里我把 exports 值设置为 jQuery/$ 以外的值 } } }); require(['jquery'], function($){ console.log($);// 这里,会显示 undefined });
其他模块在做 shim 时同理,比如 underscore 需要 exports 成 _。
Require.js 的好处
说了这么多,Require.js 到底有什么好处?
并行加载
我们知道,<script></script> 标签会阻塞页面,加载 a.js 时,后面的所有文件都得等它加载完成并执行结束后才能开始加载、执行。而 require.js 的模块可以并行下载,没有依赖关系的模块还可以并行执行,大大加快页面访问速度。
不愁依赖
在我们定义模块的时候,我们就已经决定好模块的依赖 – c 依赖 b,b 又依赖 a。当我想用 c 模块的功能时,我只要在 require函数的依赖里指定 c:
require(['c'], function(c) {...});
至于 c 依赖的模块,c 依赖的模块的依赖模块… 等等,require.js 会帮我们打理。
而传统的 script 办法,我们必须明确指定所有依赖顺序:
<script src="js/a.js"></script> <script src="js/b.js"></script> <script src="js/c.js"></script>
换句话说,传统的 script 方法里,我们极可能要靠记忆或者检查模块内容这种方式来确定依赖 – 效率太低,还费脑。
减少全局冲突
通过 define 的方式,我们大量减少了全局变量,这样代码冲突的概率就极小极小 – JavaScript 界有句话说,全局变量是魔鬼,想想,我们能减少魔鬼的数量,我想是件好事。
关于全局变量
有一点需要说明的是,require.js 环境中并不是只有 define 和 require 几个全局变量。许多库都会向全局环境中暴露变量,以 jQuery 为例,1.7版本后,它虽然注册自己为 AMD 模块,但同时也向全局环境中暴露了 jQuery 与 $。所以以下代码中,虽然我们没有向回调函数传入一份引用,jQuery/$ 同样是存在的:
require(['jquery'], function(){ console.log(jQuery); console.log($); });
相关推荐:
The above is the detailed content of Example of Require calling js in JavaScript. For more information, please follow other related articles on the PHP Chinese website!