モジュール化 はプロジェクトにおいて非常に重要です。複雑なプロジェクトでは、毎回モジュールを書き直す必要がある場合、間違いなく時間と労力がかかります。ただし、他の人を引用してモジュールを記述するには、統一された「開始姿勢」が必要です。ここでは、いくつかの JS モジュールの仕様を説明します。
モジュール化はプロジェクトにおいて非常に重要です。複雑なプロジェクトでは、毎回モジュールを書き直す必要がある場合、間違いなく時間と労力がかかります。ただし、他の人を引用してモジュールを記述するには、統一された「開始姿勢」が必要です。ここでは、いくつかの JS モジュールの仕様を説明します。
1: モジュール化プロセス 1: スクリプトタグ
これは、最も独創的な JavaScript ファイルの読み込み方法です。各ファイルをモジュールと見なす場合、そのインターフェイスは通常、グローバル スコープで公開されます。つまり、定義されます。ウィンドウ オブジェクト では、異なるモジュールのインターフェース呼び出しが同じスコープ内にあります。一部の複雑なフレームワークは、これらのモジュールのインターフェースを編成するために 名前空間 の概念を使用します。
欠点:
1. グローバルスコープを汚染する
2. 開発者は、モジュールとコードライブラリ間の依存関係を主観的に解決する必要があります
3. ファイルは、スクリプトタグが記述された順序でのみロードできます
4、大規模なプロジェクトでは、さまざまなリソースの管理が難しく、長期にわたって蓄積された問題がコードベースの混乱につながります
2: モジュール化プロセス 2: CommonJS 仕様
の中心となるアイデア仕様では、require メソッドを通じてモジュールを同期できるようにします。依存したい他のモジュールをロードし、exports または module.exports を通じて公開する必要があるインターフェイスをエクスポートします。 rrerreee-advantages:simple and eas aside sirect modulsは簡単ですブラウザ環境の場合、同期とは読み込みをブロックすることを意味し、ブラウザのリソースは非同期的に読み込まれます
2. ブロックせずに複数のモジュールを並行して読み込むことはできません
module.exports とexportsの違いは、指定されるモジュールです。 imports
2 の参照。 module.exports の初期値は空のオブジェクト {} なので、exports の初期値も {}3 になります。エクスポートの例: require("module");
require("../file.js");
exports.doStuff = function(){};
module.exports = someValue;
// app.js var circle = require('./circle'); console.log(circle.area(4)); // circle.js exports.area = function(r){ return r * r * Math.PI; }
エラー状況:
// app.js var area = require('./area'); console.log(area(4)); // area.js module.exports = function(r){ return r * r * Math.PI; }
は実際にエクスポートを上書きします。つまり、エクスポートは新しいメモリを指します (内容は円の面積を計算する
関数) )、これは、exports と module.exports が同じメモリを指さなくなったことを意味します。これは、現時点では、exports と module.exports に接続がないことを意味します。つまり、module.exports が指すメモリは何も作成されていません。つまり、area.js は空のオブジェクトをエクスポートするため、app.js で area(4) を呼び出すと、「TypeError: object is not a function」エラーが報告されます。
概要:
モジュールでオブジェクトをエクスポートしたい場合は、exports と module.exports の両方を使用できます (ただし、エクスポートを新しいオブジェクトとして再カバーすることはできません)。
オブジェクト インターフェイスの場合、module.exports はオーバーライドされる必要があり、オーバーライドのみ可能です。
三:モジュール化プロセス3:AMD仕様ブラウザ側モジュールは同期的にロードできないため、後続のモジュールのロードと実行に影響を与えるため、AMD(Asyn
chronous Module Definition)仕様が誕生しました。 次の 2 つの API が AMD 標準で定義されています1. require([module], callback);
2.define(id, [depends], callback);require インターフェイスは一連のメソッドをロードするために使用されます。モジュール、定義 インターフェイスは、モジュールを定義して公開するために使用されます。 例:
// app.js var area = require('./area'); console.log(area(4)); // area.js exports = function(r){ return r * r * Math.PI; }
1. ブラウザ環境でのモジュールの非同期ロードに適しています
欠点:
4: モジュール化プロセス IV: CMD 仕様 CMD(Common Module Definition)规范和AMD很相似,尽量保持简单,并与CommonJS和Node.js的 Modules 规范保持了很大的兼容性。在CMD规范中,一个模块就是一个文件。 示例: 优点: 1、依赖就近,延迟执行 2、可以很容易在 Node.js 中运行 缺点: 1、依赖 SPM 打包,模块的加载逻辑偏重 AMD和CMD的区别 AMD和CMD起来很相似,但是还是有一些细微的差别,让我们来看一下他们的区别在哪里: 1、对于依赖的模块,AMD是提前执行,CMD是延迟执行。 2、AMD推崇依赖前置;CMD推崇依赖就近,只有在用到某个模块的时候再去require。看代码: 3、AMD 的 API 默认是一个当多个用,CMD 的 API 严格区分,推崇职责单一。 五:模块化进程五:ES6模块化 EcmaScript6标准增加了JavaScript语言层面的模块体系定义。ES6 模块的设计思想,是尽量的静态化,使得编译时就能确定模块的依赖关系,以及输入和输出的变量。CommonJS和AMD模块,都只能在运行时确定这些东西。 在 ES6 中,我们使用export关键字来导出模块,使用import关键字引用模块。需要说明的是,ES6的这套标准和目前的标准没有直接关系,目前也很少有JS引擎能直接支持。因此Babel的做法实际上是将不被支持的import翻译成目前已被支持的require。 尽管目前使用import和require的区别不大(本质上是一回事),但依然强烈推荐使用import关键字,因为一旦JS引擎能够解析ES6的import关键字,整个实现方式就会和目前发生比较大的变化。如果目前就开始使用import关键字,将来代码的改动会非常小。 示例: 优点: 1、容易进行静态分析 2、面向未来的 EcmaScript 标准 缺点: 1、原生浏览器端还没有实现该标准 2、全新的命令字,新版的 Node.js才支持define(function(require, exports, module){
var $ = require('jquery');
var Spinning = require('./spinning');
exports.doSomething = ...
module.exports = ...
})
// AMD
define(['./a', './b'], function(a, b){ // 依赖必须一开始就写好
a.doSomething()
// 此处略去 100 行
b.doSomething()
...
});
// CMD
define(function(require, exports, module){
var a = require('./a')
a.doSomething()
// 此处略去 100 行
var b = require('./b')
// 依赖可以就近书写
b.doSomething()
// ...
});
import "jquery";
export functiondoStuff(){}
module "localModule" {}
以上がJavaScript のモジュール化についての深い理解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。