Introduction aux spécifications des modules CommonJS, AMD et CMD de JavaScript

Le contenu de cet article est une introduction aux spécifications des modules CommonJS, AMD et CMD de JavaScript. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Cet article est issu de l'article « Programmation modulaire JS : comprendre en profondeur CommonJS et AMD/CMD ! » La majeure partie du résumé de l'article est extraite des mots originaux de l'article. J'ai juste pris des notes pour faciliter l'étude, je les ajouterai à temps lorsque j'aurai de nouvelles expériences à l'avenir. En cas d'infraction, le contact sera supprimé. Rendez hommage aux seniors !

Avant de commencer, répondez-moi : Pourquoi les modules sont-ils importants ?

Réponse : Grâce aux modules, nous pouvons utiliser le code d'autres personnes plus facilement et charger les modules que nous voulons pour les fonctions que nous voulons. Cependant, il y a un prérequis à cela, c'est-à-dire que tout le monde doit écrire le module de la même manière, sinon vous avez votre façon d'écrire, et j'ai ma façon d'écrire, ne serait-ce pas le bordel !

Les trois modules suivants ont donc été standardisés, et cet article a également été publié. Laissez-moi vous expliquer à l'avance, L'implémentation de la spécification CommonJS est node.js, l'implémentation de la spécification AMD (Asynchronous Module Definition) est require.js et curl.js, et l'implémentation de la spécification CMD est Sea. js.

Spécifications des modules en JS (CommonJS, AMD, CMD), si vous avez entendu parler de la modularisation js, alors vous devriez avoir entendu parler de CommonJS ou AMD ou même de CMD. mais je l'ai vraiment écouté avant. Jetons un coup d'œil maintenant pour voir quelles sont ces spécifications et ce qu'elles font. Cet article reprend les sources de ces trois spécifications et les principes de leurs produits correspondants.

1. Spécification CommonJS

1. Au début, tout le monde pensait que JS était inutile et inutile. L'API officiellement définie ne peut créer que des applications basées sur un navigateur. étroit (j'ai utilisé un mot haut de gamme, charlatan), et CommonJS n'en peut plus. L'API CommonJS définit de nombreuses API utilisées par les applications ordinaires (principalement des applications non-navigateurs), comblant ainsi cette lacune. Son objectif ultime est de fournir une bibliothèque standard similaire à Python, Ruby et Java. Dans ce cas, les développeurs peuvent utiliser l'API CommonJS pour écrire des applications, puis ces applications peuvent s'exécuter dans différents interpréteurs JavaScript et différents environnements hôtes.

Dans les systèmes compatibles avec CommonJS, vous pouvez utiliser JavaScript pour développer les programmes suivants :

(1) Applications JavaScript côté serveur
(2). ( 3). Applications d'interface graphique
(4). Applications hybrides (telles que Titanium ou Adobe AIR)

En 2009, le programmeur américain Ryan Dahl a créé le projet node.js, qui sera JavaScript. Le langage est utilisé pour la programmation côté serveur. Cela marque la naissance officielle de la « programmation modulaire Javascript ». Car pour être honnête, dans un environnement de navigateur, ne pas avoir de modules n'est pas un gros problème. Après tout, la complexité des programmes web est limitée Mais côté serveur, il doit y avoir des modules pour interagir avec le système d'exploitation et ; d'autres applications, sinon il n'y a aucun moyen de programmer du tout. NodeJS est l'implémentation de la spécification CommonJS, et webpack est également écrit sous la forme de CommonJS.

Le système de modules de node.js est implémenté en référence à la spécification CommonJS. Dans CommonJS, il existe une méthode globale require() pour charger les modules. En supposant qu'il existe un module mathématique math.js, il peut être chargé comme suit.

var math = require('math');

Ensuite, vous pouvez appeler la méthode fournie par le module :

var math = require('math');

  math.add(2,3); // 5

Les modules définis par CommonJS sont divisés en : {référence du module (require)} {définition du module (exports)} {identification du module (module)>

require() est utilisé pour introduire des modules externes ; L'objet exports est utilisé pour exporter des méthodes ou des variables du module actuel, le seul port d'exportation l'objet module représente le module lui-même ;

Bien que Node suive les spécifications de CommonJS, il a fait quelques compromis et ajouté de nouvelles choses.

Cependant, après avoir parlé de CommonJS et également de Node, je pense que nous devons d'abord comprendre NPM. En tant que gestionnaire de packages de Node, NPM n'est pas destiné à aider Node à résoudre le problème d'installation des packages dépendants. Il doit également suivre la spécification CommonJS. Il suit la spécification (ou la théorie) du package. CommonJS WIKI parle de son histoire et présente également des modules, des packages, etc.

Parlons du principe et de la mise en œuvre simple de commonJS :

1. Principe

La raison fondamentale pour laquelle les navigateurs ne sont pas compatibles avec CommonJS est le manque de quatre variables d'environnement Node.js.

module
exports
require
global

Tant que ces quatre variables sont fournies, le navigateur peut charger le module CommonJS.

Voici un exemple simple.

var module = {
  exports: {}
};

(function(module, exports) {
  exports.multiply = function (n) { return n * 1000 };
}(module, module.exports))

var f = module.exports.multiply;
f(5) // 5000

Le code ci-dessus fournit deux variables externes, module et exports, à une fonction d'exécution immédiate, et le module est placé dans cette fonction d'exécution immédiate. La valeur de sortie du module est placée dans module.exports, réalisant ainsi le chargement du module.

2. Spécification AMD

Après la sortie de nodeJS basé sur la spécification commonJS, le concept de modules côté serveur a été formé. Naturellement, tout le monde veut des modules côté client. Et il est préférable que les deux soient compatibles, afin qu'un module puisse fonctionner à la fois sur le serveur et sur le navigateur sans modification. Cependant, en raison d'une limitation majeure, la spécification CommonJS n'est pas adaptée aux environnements de navigateur. Toujours le code ci-dessus, s'il est exécuté dans le navigateur, il y aura un gros problème, pouvez-vous le voir ?

var math = require('math');
math.add(2, 3);

第二行math.add(2, 3)，在第一行require('math')之后运行，因此必须等math.js加载完成。也就是说，如果加载时间很长，整个应用就会停在那里等。您会注意到 require 是同步的。

这对服务器端不是一个问题，因为所有的模块都存放在本地硬盘，可以同步加载完成，等待时间就是硬盘的读取时间。但是，对于浏览器，这却是一个大问题，因为模块都放在服务器端，等待时间取决于网速的快慢，可能要等很长时间，浏览器处于"假死"状态。

因此，浏览器端的模块，不能采用"同步加载"（synchronous），只能采用"异步加载"（asynchronous）。这就是AMD规范诞生的背景。

CommonJS是主要为了JS在后端的表现制定的，他是不适合前端的，AMD(异步模块定义)出现了，它就主要为前端JS的表现制定规范。

AMD是"Asynchronous Module Definition"的缩写，意思就是"异步模块定义"。它采用异步方式加载模块，模块的加载不影响它后面语句的运行。所有依赖这个模块的语句，都定义在一个回调函数中，等到加载完成之后，这个回调函数才会运行。

AMD也采用require()语句加载模块，但是不同于CommonJS，它要求两个参数：

require([module], callback);

第一个参数[module]，是一个数组，里面的成员就是要加载的模块；第二个参数callback，则是加载成功之后的回调函数。如果将前面的代码改写成AMD形式，就是下面这样：

require(['math'], function (math) {
    math.add(2, 3);
});

math.add()与math模块加载不是同步的，浏览器不会发生假死。所以很显然，AMD比较适合浏览器环境。目前，主要有两个Javascript库实现了AMD规范：require.js和curl.js。

Require.js主要提供define和require两个方法来进行模块化编程，前者用来定义模块，后者用来调用模块。RequireJS就是实现了AMD规范的呢。

三、CMD规范

大名远扬的玉伯写了seajs，就是遵循他提出的CMD规范，与AMD蛮相近的，不过用起来感觉更加方便些，最重要的是中文版，应有尽有：seajs官方doc

define(function(require,exports,module){...});

前面说AMD，说RequireJS实现了AMD，CMD看起来与AMD好像呀，那RequireJS与SeaJS像不像呢？虽然CMD与AMD蛮像的，但区别还是挺明显的，官方非官方都有阐述和理解，我觉得吧，说的都挺好

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!