検索
ホームページウェブフロントエンドjsチュートリアルJavaScriptのRequireでjsを呼び出す場合の解説

この記事では主に、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([&#39;jquery&#39;], 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: {
  &#39;jquery-1.4.1&#39;: { // <= 这个是相对于 main.js 的路径www.45it.com
   exports: &#39;jQuery&#39; // <= 这个值需要稍加注意,稍后会提及
  },
  &#39;libs/jquery-throttle-debounce.min&#39;: { // <= jQuery 插件
   deps: [&#39;jquery-1.4.1&#39;] //无需 exports,因为我们只是在增强 jQuery 功能
  }
 },
});
require([&#39;jquery-1.4.1&#39;, &#39;libs/jquery-throttle-debounce.min&#39;], function($){
 console.log($.debounce);
});

写完 shim,发现 jquery-1.4.1、libs/jquery-throttle-debounce.min 这样的名称有点长。这里我们又有两种选择,一是直接打开修改 js 文件名,或者使用 require.js 提供的配置项 paths 给模块 ID 指定对应的真实文件路径:


require.config({
 paths: {
  &#39;jquery&#39;: &#39;jquery-1.4.1&#39;, // <= 模块 jquery 指向 js/jquery-1.4.1.js 文件
  &#39;debounce&#39;: &#39;libs/jquery-throttle-debounce.min&#39;
 },
 shim: {
  &#39;jquery&#39;: {
   exports: &#39;$&#39;
  },
  &#39;debounce&#39;: {
   deps: [&#39;jquery&#39;]
  }
 }
});
require([&#39;jquery&#39;, &#39;debounce&#39;], function($){
 console.log($.debounce);
});

这样,引用起来就方便多了。

另外,需要注意 shim 中的 exports 项,它的概念更接近 imports,即把全局变量导入。我们如果把 exports 值改成非全局变量名,就会导致传入回调的对象变成 undefined,举个例子:


require.config({
 paths: {
  &#39;jquery&#39;: &#39;jquery-1.4.1&#39;,
 },
 shim: {
  &#39;jquery&#39;: {
   exports: &#39;hellojQuery&#39; // 这里我把 exports 值设置为 jQuery/$ 以外的值
  }
 }
});
require([&#39;jquery&#39;], 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([&#39;jquery&#39;], function(){
 console.log(jQuery);
 console.log($);
});

相关推荐:

a标签不能调用js方法的问题

iframe子父页面调用js函数示例

php如何调用js方法

以上がJavaScriptのRequireでjsを呼び出す場合の解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
JavaScriptとWeb:コア機能とユースケースJavaScriptとWeb:コア機能とユースケースApr 18, 2025 am 12:19 AM

Web開発におけるJavaScriptの主な用途には、クライアントの相互作用、フォーム検証、非同期通信が含まれます。 1)DOM操作による動的なコンテンツの更新とユーザーインタラクション。 2)ユーザーエクスペリエンスを改善するためにデータを提出する前に、クライアントの検証が実行されます。 3)サーバーとのリフレッシュレス通信は、AJAXテクノロジーを通じて達成されます。

JavaScriptエンジンの理解:実装の詳細JavaScriptエンジンの理解:実装の詳細Apr 17, 2025 am 12:05 AM

JavaScriptエンジンが内部的にどのように機能するかを理解することは、開発者にとってより効率的なコードの作成とパフォーマンスのボトルネックと最適化戦略の理解に役立つためです。 1)エンジンのワークフローには、3つの段階が含まれます。解析、コンパイル、実行。 2)実行プロセス中、エンジンはインラインキャッシュや非表示クラスなどの動的最適化を実行します。 3)ベストプラクティスには、グローバル変数の避け、ループの最適化、constとletsの使用、閉鎖の過度の使用の回避が含まれます。

Python vs. JavaScript:学習曲線と使いやすさPython vs. JavaScript:学習曲線と使いやすさApr 16, 2025 am 12:12 AM

Pythonは、スムーズな学習曲線と簡潔な構文を備えた初心者により適しています。 JavaScriptは、急な学習曲線と柔軟な構文を備えたフロントエンド開発に適しています。 1。Python構文は直感的で、データサイエンスやバックエンド開発に適しています。 2。JavaScriptは柔軟で、フロントエンドおよびサーバー側のプログラミングで広く使用されています。

Python vs. JavaScript:コミュニティ、ライブラリ、リソースPython vs. JavaScript:コミュニティ、ライブラリ、リソースApr 15, 2025 am 12:16 AM

PythonとJavaScriptには、コミュニティ、ライブラリ、リソースの観点から、独自の利点と短所があります。 1)Pythonコミュニティはフレンドリーで初心者に適していますが、フロントエンドの開発リソースはJavaScriptほど豊富ではありません。 2)Pythonはデータサイエンスおよび機械学習ライブラリで強力ですが、JavaScriptはフロントエンド開発ライブラリとフレームワークで優れています。 3)どちらも豊富な学習リソースを持っていますが、Pythonは公式文書から始めるのに適していますが、JavaScriptはMDNWebDocsにより優れています。選択は、プロジェクトのニーズと個人的な関心に基づいている必要があります。

C/CからJavaScriptへ:すべてがどのように機能するかC/CからJavaScriptへ:すべてがどのように機能するかApr 14, 2025 am 12:05 AM

C/CからJavaScriptへのシフトには、動的なタイピング、ゴミ収集、非同期プログラミングへの適応が必要です。 1)C/Cは、手動メモリ管理を必要とする静的に型付けられた言語であり、JavaScriptは動的に型付けされ、ごみ収集が自動的に処理されます。 2)C/Cはマシンコードにコンパイルする必要がありますが、JavaScriptは解釈言語です。 3)JavaScriptは、閉鎖、プロトタイプチェーン、約束などの概念を導入します。これにより、柔軟性と非同期プログラミング機能が向上します。

JavaScriptエンジン:実装の比較JavaScriptエンジン:実装の比較Apr 13, 2025 am 12:05 AM

さまざまなJavaScriptエンジンは、各エンジンの実装原則と最適化戦略が異なるため、JavaScriptコードを解析および実行するときに異なる効果をもたらします。 1。語彙分析:ソースコードを語彙ユニットに変換します。 2。文法分析:抽象的な構文ツリーを生成します。 3。最適化とコンパイル:JITコンパイラを介してマシンコードを生成します。 4。実行:マシンコードを実行します。 V8エンジンはインスタントコンピレーションと非表示クラスを通じて最適化され、Spidermonkeyはタイプ推論システムを使用して、同じコードで異なるパフォーマンスパフォーマンスをもたらします。

ブラウザを超えて:現実世界のJavaScriptブラウザを超えて:現実世界のJavaScriptApr 12, 2025 am 12:06 AM

現実世界におけるJavaScriptのアプリケーションには、サーバー側のプログラミング、モバイルアプリケーション開発、モノのインターネット制御が含まれます。 2。モバイルアプリケーションの開発は、ReactNativeを通じて実行され、クロスプラットフォームの展開をサポートします。 3.ハードウェアの相互作用に適したJohnny-Fiveライブラリを介したIoTデバイス制御に使用されます。

next.jsを使用してマルチテナントSaaSアプリケーションを構築する(バックエンド統合)next.jsを使用してマルチテナントSaaSアプリケーションを構築する(バックエンド統合)Apr 11, 2025 am 08:23 AM

私はあなたの日常的な技術ツールを使用して機能的なマルチテナントSaaSアプリケーション(EDTECHアプリ)を作成しましたが、あなたは同じことをすることができます。 まず、マルチテナントSaaSアプリケーションとは何ですか? マルチテナントSaaSアプリケーションを使用すると、Singの複数の顧客にサービスを提供できます

See all articles

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

MinGW - Minimalist GNU for Windows

MinGW - Minimalist GNU for Windows

このプロジェクトは osdn.net/projects/mingw に移行中です。引き続きそこでフォローしていただけます。 MinGW: GNU Compiler Collection (GCC) のネイティブ Windows ポートであり、ネイティブ Windows アプリケーションを構築するための自由に配布可能なインポート ライブラリとヘッダー ファイルであり、C99 機能をサポートする MSVC ランタイムの拡張機能が含まれています。すべての MinGW ソフトウェアは 64 ビット Windows プラットフォームで実行できます。

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

WebStorm Mac版

WebStorm Mac版

便利なJavaScript開発ツール

Dreamweaver Mac版

Dreamweaver Mac版

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)