Introduction détaillée à la programmation modulaire JavaScript (exemples de code)

Cet article vous apporte une introduction détaillée à la programmation modulaire JavaScript (exemples de code). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Qu'est-ce que la modularité ?

Un module est un ensemble de méthodes pour implémenter des fonctions spécifiques, et la modularisation consiste à créer sa propre portée pour le code du module, en exposant uniquement les méthodes et variables publiques à l'extérieur, et ces méthodes sont hautement indissociables les uns des autres.

Pourquoi l'écriture de JS nécessite-t-elle une programmation modulaire ?
Lorsque l'écriture du front-end consistait simplement à traiter certaines soumissions de formulaires et interactions de clics sur la page Web, le concept de modularité JS n'avait pas été renforcé. La logique du front-end est devenue complexe, les interactions sont devenues plus nombreuses et. la quantité de données est devenue de plus en plus grande. À cette époque, la demande du front-end pour la programmation modulaire JS est devenue plus forte.

Dans de nombreux scénarios, nous devons considérer la modularité :

1. De nombreuses personnes dans l'équipe collaborent et doivent référencer le code d'autres personnes
2. Lors de la passation du projet, nous lisons et reconstruisons le code des autres
3. Lors de la révision du code, vérifiez si votre code est standardisé et s'il y a des problèmes
4. Après avoir écrit le code, vérifiez si le code que vous avez écrit est beau : )
5. Différent L'environnement et les variables d'environnement sont différents

Sur la base des scénarios ci-dessus, la modularisation JS actuelle a donc principalement ces objectifs :

1. Réutilisabilité du code
2. Couplage lâche du code fonctionnel
3. Résoudre les conflits de noms
4. Maintenabilité du code
5. Lisibilité du code

Première conclusion : JS modules La programmation est passée par plusieurs étapes :

1. Encapsulation du code sous forme d'espace de noms
2. Espace de noms créé via la fonction d'exécution immédiate (IIFE)
3. Runtime côté serveur Nodejs Spécification CommonJS
4. Spécification AMD/CMD qui s'exécutera de manière modulaire côté navigateur
5. Compatible avec CMD et la spécification UMD d'AMD
6. Module ES pris en charge via les normes de langage

Donnez d'abord la conclusion :

1 Espace de noms

Nous savons qu'avant ES6, JS n'avait pas de portée In block, l'isolation des variables et méthodes privées repose principalement sur la portée de la fonction, et l'isolation des variables et méthodes publiques repose principalement sur les références d'attributs d'objet.

Fonction d'encapsulation

Lorsque JS n'avait pas de spécifications modulaires, certaines fonctions communes et sous-jacentes étaient abstraites et séparées en fonctions pour obtenir la modularité :
Par exemple, écrire un fichier de fonction de l'outil utils.js

//  utils.js
function add(x, y) {
    if(typeof x !== "number" || typeof y !== "number") return;
    return x + y;
}

function square(x) {
    if(typeof x !== "number") return;
    return x * x;
}

<script></script>
<script>
    add(2, 3);
    square(4);
</script>

En divisant le fichier de fonction js, la fonction publique à ce moment est en fait montée sous la fenêtre de l'objet global lorsque d'autres le souhaitent également lors de la définition d'une fonction appelée ajouter. , ou lorsque plusieurs fichiers js sont fusionnés et compressés, il y aura un problème de conflit de nom.

Monté sous des variables globales :

Plus tard, nous avons pensé à monter des fonctions sous des littéraux d'objet globaux, en utilisant le concept de packages JAVA, dans l'espoir de faciliter la gravité du conflit de dénomination.

var mathUtils1 = {
    add: function(x, y) {
        return x + y;
    },
}

var mathUtils2 = {
    add: function(x, y, z) {
        return x + y + z;
    },
}

mathUtils.add();

mathUtils.square();

Cette méthode crée toujours des variables globales, mais si le chemin du package est long, la méthode de référence peut finir par référencer le code sous la forme de module1.subModule.subSubModule.add.

IIFE
Considérant que le module a des variables privées, nous utilisons IIFE (expression d'exécution immédiate) pour créer une fermeture pour encapsuler les variables privées :

var module = (function(){
    var count = 0;
    return {
        inc: function(){
            count += 1;
        },
        dec: function(){
            count += -1;
        }
    }
})()

module.inc();
module.dec();

De cette façon, les variables privées ne sont pas accessibles au monde extérieur. Et si le module doit introduire d'autres dépendances ?

var utils = (function ($) {
    var $body = $("body"); 
    var _private = 0;
    var foo = function() {
        ...
    }
    var bar = function () {
        ...
    }
    
    return {
        foo: foo,
        bar: bar
    }
})(jQuery);

La manière ci-dessus d'encapsuler les modules s'appelle : mode module À l'ère de jQuery, le mode module était largement utilisé :

<script></script>
<script></script>
<script></script>
<script></script>
<script></script>

les plug-ins jQuery doivent être après le. Fichier JQuery.js. L'ordre de chargement des fichiers est strictement restreint. Plus il y a de dépendances, plus les dépendances seront confuses et plus il sera facile de commettre des erreurs.

2. CommonJS

L'émergence de Nodejs permet à JavaScript de s'exécuter dans un environnement côté serveur. À l'heure actuelle, il est urgent d'établir une norme pour implémenter un système de modules unifié, qui est plus tard CommonJS.

// math.js
exports.add = function(x, y) {
    return x + y;
}

// base.js
var math = require("./math.js");
math.add(2, 3);  // 5

// 引用核心模块
var http = require('http');
http.createServer(...).listen(3000);

CommonJS stipule qu'à l'intérieur de chaque module, module représente le module actuel. Ce module est un objet avec des attributs tels que l'identifiant, le nom du fichier, chargé, le parent, les enfants, les exportations, etc. L'attribut module.exports. représente l'exposition externe du module actuel. L'interface de sortie et les autres fichiers chargeant le module lisent en fait la variable module.exports.

// utils.js
// 直接赋值给 module.exports 变量
module.exports = function () {
    console.log("I'm utils.js module");
}

// base.js
var util = require("./utils.js")
util();  // I'm utils.js module

或者挂载到 module.exports 对象下
module.exports.say = function () {
    console.log("I'm utils.js module");
}

// base.js
var util = require("./utils.js")
util.say();

Pour plus de commodité, Node fournit une variable gratuite d'exportation pour chaque module, pointant vers module.exports. Cela équivaut à avoir une ligne comme celle-ci en tête de chaque module.

var exports = module.exports;

Les exportations et module.exports partagent la même adresse de référence. L'attribution directe d'une valeur aux exportations fera que les deux ne pointeront plus vers la même adresse mémoire, mais cela ne prendra pas effet sur module.exports. à la fin.

// module.exports 可以直接赋值
module.exports = 'Hello world';  

// exports 不能直接赋值
exports = 'Hello world';

Résumé de CommonJS :
Le module de chargement de spécification CommonJS est synchrone et est utilisé côté serveur puisque CommonJS chargera le module intégré dans la mémoire au démarrage, il placera également les modules chargés en mémoire. Par conséquent, il n'y aura pas de gros problème avec l'utilisation du chargement synchrone dans l'environnement Node.

De plus, le module CommonJS charge une copie de la valeur de sortie. En d'autres termes, si la valeur de sortie du module externe change, la valeur d'importation du module actuel ne changera pas.

三、AMD

CommonJS 规范的出现，使得 JS 模块化在 NodeJS 环境中得到了施展机会。但 CommonJS 如果应用在浏览器端，同步加载的机制会使得 JS 阻塞 UI 线程，造成页面卡顿。

利用模块加载后执行回调的机制，有了后面的 RequireJS 模块加载器， 由于加载机制不同，我们称这种模块规范为 AMD(Asynchromous Module Definition 异步模块定义)规范, 异步模块定义诞生于使用 XHR + eval 的开发经验，是 RequireJS 模块加载器对模块定义的规范化产出。

AMD 的模块写法：

// 模块名 utils
// 依赖 jQuery, underscore
// 模块导出 foo, bar 属性
<script></script>

// main.js
require.config({
  baseUrl: "script",
  paths: {
    "jquery": "jquery.min",
    "underscore": "underscore.min",
  }
});

// 定义 utils 模块，使用 jQuery 模块
define("utils", ["jQuery", "underscore"], function($, _) {
    var body = $("body");
    var deepClone = _.deepClone({...});
    return {
        foo: "hello",
        bar: "world"
    }
})

AMD 的特点在于：

1. 延迟加载
2. 依赖前置

AMD 支持兼容 CommonJS 写法：

define(function (require, exports, module){
  var someModule = require("someModule");
  var anotherModule = require("anotherModule");

  someModule.sayHi();
  anotherModule.sayBye();

  exports.asplode = function (){
    someModule.eat();
    anotherModule.play();
  };
});

四、CMD

SeaJS 是国内 JS 大神玉伯开发的模块加载器，基于 SeaJS 的模块机制，所有 JavaScript 模块都遵循 CMD（Common Module Definition） 模块定义规范.

CMD 模块的写法：

<script></script>
<script>
// seajs 的简单配置
seajs.config({
  base: "./script/",
  alias: {
    "jquery": "script/jquery/3.3.1/jquery.js"
  }
})

// 加载入口模块
seajs.use("./main")
</script>

// 定义模块
// utils.js
define(function(require, exports, module) {
  exports.each = function (arr) {
    // 实现代码 
  };

  exports.log = function (str) {
    // 实现代码
  };
});

// 输出模块
define(function(require, exports, module) {
  var util = require('./util.js');
  
  var a = require('./a'); //在需要时申明，依赖就近
  a.doSomething();
  
  exports.init = function() {
    // 实现代码
    util.log();
  };
});

CMD 和 AMD 规范的区别：  
AMD推崇依赖前置，CMD推崇依赖就近：  
AMD 的依赖需要提前定义，加载完后就会执行。
CMD 依赖可以就近书写，只有在用到某个模块的时候再去执行相应模块。
举个例子：

// main.js
define(function(require, exports, module) {
  console.log("I'm main");
  var mod1 = require("./mod1");
  mod1.say();
  var mod2 = require("./mod2");
  mod2.say();

  return {
    hello: function() {
      console.log("hello main");
    }
  };
});

// mod1.js
define(function() {
  console.log("I'm mod1");
  return {
    say: function() {
      console.log("say: I'm mod1");
    }
  };
});

// mod2.js
define(function() {
  console.log("I'm mod2");
  return {
    say: function() {
      console.log("say: I'm mod2");
    }
  };
});

以上代码分别用 Require.js 和 Sea.js 执行，打印结果如下：  
Require.js:  
先执行所有依赖中的代码

I'm mod1
I'm mod2
I'm main
say: I'm mod1
say: I'm mod2

Sea.js:  
用到依赖时，再执行依赖中的代码

I'm main

I'm mod1
say: I'm mod1
I'm mod2
say: I'm mod2

五、UMD

umd（Universal Module Definition） 是 AMD 和 CommonJS 的兼容性处理,提出了跨平台的解决方案。

(function (root, factory) {
    if (typeof exports === 'object') {
        // commonJS
        module.exports = factory();
    } else if (typeof define === 'function' && define.amd) {
        // AMD
        define(factory);
    } else {
        // 挂载到全局
        root.eventUtil = factory();
    }
})(this, function () {
    function myFunc(){};

    return {
        foo: myFunc
    };
});

应用 UMD 规范的 JS 文件其实就是一个立即执行函数，通过检验 JS 环境是否支持 CommonJS 或 AMD 再进行模块化定义。

六、ES6 Module

CommonJS 和 AMD 规范都只能在运行时确定依赖。而 ES6 在语言层面提出了模块化方案, ES6 module 模块编译时就能确定模块的依赖关系，以及输入和输出的变量。ES6 模块化这种加载称为“编译时加载”或者静态加载。

写法：

// math.js
// 命名导出
export function add(a, b){
    return a + b;
}
export function sub(a, b){
    return a - b;
}
// 命名导入
import { add, sub } from "./math.js";
add(2, 3);
sub(7, 2);

// 默认导出
export default function foo() {
  console.log('foo');
}
// 默认导入
import someModule from "./utils.js";

ES6 模块的运行机制与 CommonJS 不一样。JS 引擎对脚本静态分析的时候，遇到模块加载命令import，就会生成一个只读引用。等到脚本真正执行时，再根据这个只读引用，到被加载的那个模块里面去取值。原始值变了，import加载的值也会跟着变。因此，ES6 模块是动态引用，并且不会缓存值，模块里面的变量绑定其所在的模块。

另，在 webpack 对 ES Module 打包， ES Module 会编译成 require/exports 来执行的。

总结

JS 的模块化规范经过了模块模式、CommonJS、AMD/CMD、ES6 的演进，利用现在常用的 gulp、webpack 打包工具，非常方便我们编写模块化代码。掌握这几种模块化规范的区别和联系有助于提高代码的模块化质量，比如，CommonJS 输出的是值拷贝，ES6 Module 在静态代码解析时输出只读接口，AMD 是异步加载，推崇依赖前置，CMD 是依赖就近，延迟执行，在使用到模块时才去加载相应的依赖。

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!