Compréhension approfondie de la modularisation de JavaScript

La

La modularisation est très importante dans un projet. Un projet complexe doit avoir de nombreux modules fonctionnels similaires. Si vous devez réécrire les modules à chaque fois, cela prendra certainement du temps et du travail. Cependant, la condition préalable pour citer d'autres personnes pour écrire des modules est d'avoir une « posture d'ouverture » unifiée. Si chacun a sa propre façon d'écrire, ce sera certainement chaotique.

La modularisation est très importante dans un projet. Un projet complexe doit avoir de nombreux modules fonctionnels similaires. Si vous devez réécrire les modules à chaque fois, cela prendra certainement du temps et du travail. Cependant, la condition préalable pour citer d'autres personnes pour écrire des modules est d'avoir une « posture d'ouverture » unifiée. Si chacun a sa propre façon d'écrire, ce sera certainement chaotique.

1 : Premier processus de modularisation : balise de script

C'est la méthode de chargement de fichier JavaScript la plus originale si chaque fichier est considéré comme un. module, alors leurs interfaces sont généralement exposées dans la portée globale, c'est-à-dire définies dans la fenêtre objet Les appels d'interface des différents modules sont tous dans la même portée. Certains frameworks complexes utiliseront le concept de <.>namespace est utilisé pour organiser les interfaces de ces modules.

Inconvénients :

Deux : Processus de modularisation deux : spécification CommonJS

require, puis exportez les interfaces qui doivent être exposées via exports ou module.exports.

require("module");
require("../file.js");
exports.doStuff = function(){};
module.exports = someValue;

Avantages :

Inconvénients :

La différence entre module.exports et exports

// 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;
}

// app.js
var area = require('./area');
console.log(area(4));
// area.js
exports = function(r){
 return r * r * Math.PI;
}

fonction qui calcule l'aire d'un cercle), ce qui signifie que exports et module.exports ne pointent plus vers le même morceau de mémoire, ce qui signifie que exports et module.exports n'ont aucune connexion pour le moment. Cela signifie que la mémoire pointée par module.exports n'a pas été modifiée. de toute façon. C'est toujours un objet vide {}, ce qui signifie que Area.js est exporté. Un objet vide, donc lorsque nous appelons Area(4) dans app.js, un TypeError: object n'est pas. une erreur de fonction sera signalée.

Résumé : Lorsque nous voulons que le module exporte un objet, les deux exportations et module.exports peuvent être utilisés (mais les exportations ne peuvent pas être écrasées comme une nouvelle) objet), et lorsque nous voulons exporter une interface non-objet, nous devons et pouvons uniquement remplacer module.exports.

Trois : Processus de modularisation trois : Spécification AMD

chronous Module Definition (Asynchronous Module Definition) était née.

2. 🎜 >
L'interface require est utilisée pour charger une série de modules, et l'interface de définition est utilisée pour définir et exposer un module.

Exemple :

define("module", ["dep1", "dep2"], function(d1, d2){
 return someExportedValue;
});
require(["module", "../file"], function(module, file){ /* ... */ });

Avantages : Adapté au chargement asynchrone de modules dans un environnement de navigateur

2. Plusieurs modules peuvent être chargés en parallèle

Inconvénients : Augmentation des coûts de développement, de lecture et d'écriture de code. C'est plus difficile et la sémantique de la méthode de définition du module n'est pas fluide

2. Elle n'est pas conforme à la façon de penser modulaire générale et constitue une implémentation compromise

CMD(Common Module Definition)规范和AMD很相似，尽量保持简单，并与CommonJS和Node.js的 Modules 规范保持了很大的兼容性。在CMD规范中，一个模块就是一个文件。

示例：

define(function(require, exports, module){
 var $ = require('jquery');
 var Spinning = require('./spinning');
 exports.doSomething = ...
 module.exports = ...
})

优点：

1、依赖就近，延迟执行

2、可以很容易在 Node.js 中运行

缺点：

1、依赖 SPM 打包，模块的加载逻辑偏重

AMD和CMD的区别

AMD和CMD起来很相似，但是还是有一些细微的差别，让我们来看一下他们的区别在哪里：

1、对于依赖的模块，AMD是提前执行，CMD是延迟执行。

2、AMD推崇依赖前置；CMD推崇依赖就近，只有在用到某个模块的时候再去require。看代码：

// 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()
  // ...
});

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关键字，将来代码的改动会非常小。

示例：

import "jquery";
export functiondoStuff(){}
module "localModule" {}

优点：