この記事では主に、JavaScript での Require 呼び出し js の共有例を紹介します。編集者はこれが非常に良いものだと思ったので、皆さんの参考として今から共有します。編集者をフォローして見てみましょう。皆さんのお役に立てれば幸いです。
私が初めて JavaScript 関数を書き始めたとき、通常は次のようになりました:
function fun1() {
// some code here
}
function fun2() {
// some other code here
}
...関数はすべてグローバル環境で記述されます。プロジェクトが小さい場合、通常は競合は発生しません。
しかし、コードが多すぎると、関数名（英語の語彙）だけでは不十分であることが徐々にわかりました。そこで、名前空間の概念が導入され、コードのモジュール化が始まりました。
名前空間の下の関数
名前空間の下で、私のコードは次のように書かれます:
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,
...
};
}());
...オブジェクト指向の原則に従って、関数を実行するには、通常次のように書きます:
com.zfanw.module1.func1.apply({},['arg1',arg2]);
...もちろん、文字入力を節約するために、クロージャに 1 つのパブリック API インターフェイスもインポートします: www.jb51.net
(function($, mod1) {
// some code here
mod1.func1.apply({},['arg1',arg2]);
}(jQuery, com.zfanw.module1)）;
...この時点では、コード競合の可能性は非常に小さいですが、しかし、コードは依存しています。マルチスクリプト ファイルの管理やブロックなどの問題が徐々に表面化し、名前空間のアプローチは失敗し始めました。
それで Require.js2 が表示されます。
Require.js
まず、require.js 3 のモジュールの概念を理解してください。
モジュールは、グローバル名前空間の汚染を回避する適切な範囲のオブジェクトを定義するという点で、従来のスクリプト ファイルとは異なります。依存関係を明示的にリストし、グローバル オブジェクトを参照することなくそれらの依存関係のハンドルを取得しますが、その代わりにモジュールを定義する関数の引数として依存関係を受け取ります。
簡単に言うと、2 つのポイントがあります。1 つは、モジュールのスコープです。自己統合され、グローバル空間を汚染しません。 2. モジュールは依存関係を指定し、依存関係はグローバル オブジェクトを参照することなくパラメータの受け渡しによってインポートされます。依存関係もグローバル空間を汚染しません。 。
モジュールを定義する
上記の長い名前空間メソッドとは異なり、require.js はグローバル メソッドdefineを使用して、次の形式でモジュールを定義します。
define(id?, dependencies?, factory); // ? 表示可选项
モジュールを2つのタイプに分けます。
依存関係のないモジュール
モジュールが他のモジュールに依存しない場合、定義は非常に簡単です。たとえば、モジュール hello は hello.js ファイルに配置されます:
define(function() {
// some code here
return {
// some public api
};
});。 依存モジュール
依存関係のあるモジュールは、定義するときに、モジュールの依存関係をリストする必要があります:
define(['jquery'], function($) { // 比如这个模块，代码的执行依赖 jQuery，require.js 会先加载 jquery 模块代码，并加以执行，然后将依赖模块 以 $ 的参数形式传入回调函数中，回调函数将执行结果注册为模块
// maybe some code here
return {
// some public api
};
});ここで、依存関係の「jquery」はモジュールのパスです。モジュール ID に相当する、baseUrl を基準とした相対値。
ここで、上で書いたクロージャ内のパブリック API をインポートするコードを見て、define 関数と比較してください:
(function($, mod1) {
// some code here
mod1.func1.apply({},['arg1',arg2]);
}(jQuery, com.zfanw.module1)）;このコードでは、クロージャ内に jQuery もインポートしました。 $external パラメータを通じて jQuery にもアクセスします。 「依存関係を定義する」方法は、define メソッドに非常に似ていると言えます。違いは、define によってインポートされた jquery がグローバル変数ではないため、グローバル環境を汚染しないことです。
モジュール名について
define関数には3つのパラメータがあります。この名前の形式は、ファイル形式を除いたbaseUrlのパスに相対します。モジュールが js/libs /hi.js に配置され、名前が次のように定義されている場合:
define('libs/hi', ['jquery'], function($){......});この定義の利点は、同じ名前のファイルがディレクトリ内で許可されていないため、モジュールが競合しないことです。同じディレクトリ。ただし、require.js では、モジュール名を設定しないことをお勧めします。「libs/hi」というモジュール名を設定した後、移動する場合は、モジュールを js/libs ディレクトリ内の hi.js ファイルに配置する必要があるためです。場所、モジュール名 変更に従ってください。 r.js を使用した後の最適化中に生成されるモジュール名については、別の問題になります。
モジュールの使用
「依存関係あり」または「依存関係なし」でさまざまなモジュールを定義した後、それらをどのように使用すればよいでしょうか? Require.js は、require という関数を提供します (requirejs と同等)。
require 関数は、依存関係をロードし、コールバックを実行します。define とは異なり、コールバックの結果 4 をモジュールとして登録しません。
require(['jquery'], function($) { // 这个函数加载 jquery 依赖，然后执行回调代码
console.log($);
});簡単な例を示します。次のファイル構造のフォルダーがあります:
index.html js/ main.js require.js jquery.js
ここでは、jquery.js が AMD モジュールとして登録されており、require.js は次のように HTML ファイルで参照されます:
<script src="js/require.js" data-main="js/main"></script>
require.js data-main 属性値を確認します。ここでは js/main です。設定に従って、js ディレクトリに main.js ファイルがロードされます。
main.js ファイルで行うことは 1 つだけです。jQuery メソッドを使用して現在のウィンドウの幅を取得します。
require(['jquery'], function($) {
var w = $(window).width();
console.log(w);
});コードを実行するのはとても簡単です。
AMD 以外の標準モジュール
但事情远没有我们想像中那么美好，AMD 只是一种社区规范，并非标准，而且在它出现以前，已经有各种各样的流行库存在，更不用说我们自己早期写的代码，所以我们一定会碰上一堆非 AMD 规范的模块。为了让 require.js 能够加载它们，并且自动识别、载入依赖，我们有两种选择，一、给它们全穿上一个叫 define 的函数；二、使用 Require.js 提供的配置选项 shim，曲线救国。
比如我手上一个项目，因为某种原因，还在用 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($);
});相关推荐：
以上がJavaScriptのRequireでjsを呼び出す場合の解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
