Pourquoi la modularité est-elle nécessaire ? Introduction aux solutions modulaires courantes en js

Le contenu de cet article explique pourquoi la modularisation est nécessaire ? Une introduction aux solutions modulaires couramment utilisées en js a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'elle vous sera utile.

Pourquoi la modularisation est nécessaire

Avant l'émergence d'ES6, le langage JS lui-même ne fournissait pas de capacités de modularisation, ce qui posait quelques problèmes de développement, dont le plus important Deux problèmes devraient être la pollution mondiale et le chaos dans la gestion de la dépendance.

// file a.js
var name = 'aaa';
var sayName = function() {
    console.log(name);
};

<!-- file index.html -->
<script src=&#39;xxx/xxx/a.js&#39;></script>

<script>
    sayName(); // 'aaa'
    
    // code...
    
    var name = 'bbb';
    
    sayName(); // 'bbb'
</script>

Dans le code ci-dessus, nous avons appelé deux fois la fonction sayName fournie par a.js et avons généré des résultats différents. Évidemment, c'est parce que les deux fichiers ont attribué des valeurs au nom de la variable. , ils ont un impact les uns sur les autres. Bien sûr, on peut faire attention à ne pas définir des noms de variables existantes lors de l'écriture du code, mais lorsqu'une page référence une dizaine de fichiers de plusieurs centaines de lignes, il n'est évidemment pas réaliste de mémoriser toutes les variables qui ont été définies.

// file a.js
var name = getName();
var sayName = function() {
    console.log(name)
};

// file b.js
var getName = function() {
    return 'timo';
};

<script src=&#39;xxx/xxx/b.js&#39;></script>
<script src=&#39;xxx/xxx/a.js&#39;></script>

<script>
    sayName(); // 'timo'
</script>

<script src=&#39;xxx/xxx/a.js&#39;></script>
<script src=&#39;xxx/xxx/b.js&#39;></script>

// Uncaught ReferenceError: getName is not defined

Le code ci-dessus montre que lorsque plusieurs fichiers ont des dépendances, nous devons garantir l'ordre dans lequel ils sont introduits, afin de garantir que lors de l'exécution d'un certain fichier, ses dépendances ont été Avec un chargement précoce, vous pouvez imaginer que plus le projet est grand, plus nous devons gérer de dépendances, ce qui est fastidieux et sujet aux erreurs.

Afin de résoudre ces problèmes, de nombreuses spécifications ont émergé dans la communauté pour fournir des capacités modulaires pour le langage JS. Avec l'aide de ces spécifications, notre développement peut être rendu plus pratique et plus sûr.

Solutions modulaires communes

CommonJS

CommonJS est l'une des solutions modulaires proposées par la communauté, et Node.js suit ce plan établi.

Écriture de base

// file a.js
var obj = {
    sayHi: function() {
        console.log('I am timo');
    };
};

module.exports obj;

// file b.js
var Obj = require('xxx/xxx/a.js');

Obj.sayHi(); // 'I am timo'

Dans le code ci-dessus, le fichier a.js est le fournisseur du module, et le fichier b.js est l'appelant du module.

Spécification

1. Chaque fichier est un module

2. fourni au sein d'un modulemoduleObjet, représentant le module actuel ;

3. Le module utilise des exports pour exposer ses propres fonctions/objets/variables, etc. ; 🎜> Le module importe d'autres modules via la méthode

   require()

4. Les spécifications de CommonJS sont simplement les 4 éléments ci-dessus. Vous pouvez le comprendre en vous référant à. les exemples de la méthode d'écriture de base. , dans la mise en œuvre réelle, bien que Node.js suive la spécification CommonJS, il y apporte encore quelques ajustements.

AMD

AMD est l'une des spécifications modulaires, et RequireJS suit cet ensemble de spécifications.

Utilisation de base

Dans le code ci-dessus, le fichier a.js exporte le module

Spécification

 // file a.js
 define('module', ['m', './xxx/n.js'], function() {
    // code...
 })

Dans AMD, le module est exposé Utilisez la fonction de définition

Comme indiqué dans le code ci-dessus, la fonction de définition a trois paramètres

define(moduleName, [], callback);

moduleName peut être omis et représente le nom. du module. Généralement, cela a peu d'effet.

• ['name1', 'name2'], le deuxième paramètre est un tableau, indiquant d'autres modules dont dépend le module actuel. S'il n'y a pas de modules dépendants, ce paramètre peut être omis

• rappel, le troisième paramètre est un paramètre obligatoire, c'est une fonction de rappel, et l'intérieur est le code pertinent du courant module

• Autres

ADM se caractérise par un chargement frontal des dépendances. C'est la plus grande différence entre la spécification ADM et la spécification CMD qui sera introduite ensuite. chargement signifie : avant d'exécuter le rappel du module actuellement chargé, tous les packages dépendants seront chargés en premier, c'est-à-dire le package de dépendance spécifié dans le deuxième paramètre de la fonction de définition.

CDM

Méthode d'écriture de base

Le code ci-dessus est la méthode d'écriture de base du module d'exportation de spécification CMD

Spécification

 define(function(require, exports, module) {   
    var a = require('./a')  
    a.doSomething();
    // code... 
    var b = require('./b') 
    // code...
})

De la méthode d'écriture On peut voir que la méthode d'écriture de CMD est très similaire à celle d'AMD. La principale différence est la différence dans le temps de chargement des dépendances. Comme mentionné ci-dessus, AMD dépend du front-end, tandis que le temps de chargement des dépendances est différent. La spécification CMD préconise le principe de proximité. En termes simples, elle ne se charge pas avant l'exécution du module. Lorsque le module est en cours d'exécution, lorsqu'une dépendance est nécessaire, chargez-la à nouveau.

UMD

Lorsque CommonJS, AMD et CMD sont en parallèle, il faut une solution compatible avec eux, pour que lors du développement, nous n'ayons plus besoin de considérer les spécifications suivies par modules dépendants, et l'émergence de l'UMD est de résoudre ce problème.

Méthode d'écriture de base

Le code ci-dessus est la méthode d'écriture de base d'UMD. Comme le montre le code, il peut prendre en charge à la fois la spécification CommonJS et la spécification AMD.

Module ES6

(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        //AMD
        define(['jquery'], factory);
    } else if (typeof exports === 'object') {
        //Node, CommonJS之类的
        module.exports = factory(require('jquery'));
    } else {
        //浏览器全局变量(root 即 window)
        root.returnExports = factory(root.jQuery);
    }
}(this, function ($) {
    //方法
    function myFunc(){};
    //暴露公共方法
    return myFunc;
}));

Ce qui précède présente respectivement CommonJS, AMD, CMD et UMD. Ils sont tous des contributions de la communauté à la modularisation de JS. La raison fondamentale de l'émergence de cette spécification est la. Langage JS. Il n'a pas de capacités de modularité. Actuellement, dans la dernière spécification du langage JS ES6, des capacités de modularité ont été ajoutées à la propre solution de modularisation de JS. JS peut remplacer complètement les différentes spécifications actuellement proposées par la communauté et peut être couramment utilisée sur le navigateur. côté et côté nœud.

La capacité de modularisation dans ES6 se compose de deux commandes :

export

et

import

La commande

export est utilisée pour spécifier l'interface externe du. module La commande import est utilisée pour importer des fonctions fournies par d'autres modules. Commande d'exportationDans ES6, un fichier est un module. Les variables/fonctions à l'intérieur du module sont inaccessibles de l'extérieur si vous souhaitez exposer les fonctions/variables internes, etc. le monde extérieur, ils peuvent être utilisés par d'autres modules. Pour l'utiliser, vous devez l'exporter via la commande export

.

// file a.js
export let a = 1;
export let b = 2;
export let c = 3;

// file b.js
let a = 1;
let b = 2;
let c = 3;

export {a, b, c}

// file c.js
export let add = (a, b) => {
    return a + b;
};

上面三个文件的代码，都是通过export命令导出模块内容的示例，其中a.js文件和b.js文件都是导出模块中的变量，作用完全一致但写法不同，一般我们更推荐b.js文件中的写法，原因是这种写法能够在文件最底部清楚地知道当前模块都导出了哪些变量。

import命令

模块通过export命令导出变量/函数等，是为了让其他模块能够导入去使用，在ES6中，文件导入其他模块是通过import命令进行的

// file d.js
import {a, b, c} from './a.js';

上面的代码中，我们引入了a.js文件中的变量a、b、c，import在引入其他模块内的函数/变量时，必须与原模块所暴露出来的函数名/变量名一一对应。
同时，import命令引入的值是只读的，如果尝试对其进行修改，则会报错

import {a} d from './a.js';
a = 2; // Syntax Error : 'a' is read-only;

export default命令

从上面import的介绍可以看到，当需要引入其他模块时，需要知道此模块暴露出的变量名/函数名才可以，这显然有些麻烦，因此ES6还提供了一个import default命令

// file a.js

let add = (a, b) => {
    return a+b
};
export default add;

// file b.js
import Add from './a.js';

Add(1, 2); // 3

上面的代码中，a.js通过export default命令导出了add函数，在b.js文件中引入时，可以随意指定其名称

export default命令是默认导出的意思，既然是默认导出，显然只能有一个，因此每个模块只能执行一次export default命令，其本质是导出了一个名为default的变量或函数。

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!