Exemples de compréhension modulaire en Javascript

Époque originale : la balise script introduit le fichier javascript

-------- html -------
<p id="result"></p>
<script type="text/javascript" src="add.js"></script>
<script type="text/javascript" src="sum.js"></script>
<script type="text/javascript" src="main.js"></script>
-------add.js------
function add(a, b){ return a + b ;}
------ sum.js -----
function sum(n){
   return n + add(1, 2);
}
----- main.js ----
document.getElementById(&#39;result&#39;).innerHTML = sum(3);

Cette méthode manque d'analyse des dépendances, pollue l'espace des variables globales et doit garantir que le fichier est introduit L'ordre et la gestion prêtent à confusion

Époque d'origine : Objets modules et modèles IIFE

En utilisant des objets module et immédiatement appelés expressions de fonction(IIFE), nous pouvons réduire la pollution à l'échelle mondiale. Dans cette approche, nous exposons uniquement un objet à la portée globale. Cet objet contient toutes les méthodes et valeurs dont nous avons besoin dans notre application.

例如只向全局作用域公开了 App 对象
-------- html -------
<p id="result"></p>
<script type="text/javascript" src="app.js"></script>
<script type="text/javascript" src="add.js"></script>
<script type="text/javascript" src="sum.js"></script>
<script type="text/javascript" src="main.js"></script>
------- app.js -------
var App = {};
------- add.js -------
(function(){
    App.add = function(a, b){
       return a + b;
   }
})();
------- sum.js -------
(function(){
    App.sum= function(n){
       return App.add(1, 2) + n;
   }
})();
------- main.js -------
(function(app){
   document.getElementById(&#39;result&#39;).innerHTML = app.sum(3);
})(App);

Vous pouvez voir qu'à l'exception de app.js, tous les autres fichiers sont encapsulés au format IIFE

Il y a toujours un problème de manque de résolution des dépendances, et il y a toujours 1 variable globale , au lieu de se débarrasser de toutes les variables globales

Ère de transition : CommonJS

CommonJS n'est pas une bibliothèque JavaScript. Il s'agit d'un organisme de normalisation. C'est comme l'ECMA ou le W3C. ECMA définit la spécification du langage JavaScript. Le W3C définit des API Web JavaScript telles que les événements DOM ou DOM. L'objectif de CommonJS est de définir un ensemble commun d'API pour les serveurs Web, les postes de travail et les applications en ligne de commande.

CommonJS définit également une API de module. Puisqu'il n'y a pas de pages HTML ni de balises </script><script> dans une application serveur, il est logique de fournir une API claire pour les modules. Les modules doivent être exposés (**export**) pour être utilisés par d'autres modules et accessibles (**import**). La syntaxe de son module d'export est la suivante :

---------------- add.js  --------------------
module.exports = function add(a, b){
  return a+b;
}
---------------- sum.js  --------------------
var add = require('./add');
module.exports  = function sum(n){
     return add(1, 2) + n;
}
---------------- main.js  --------------------
var sum = require('./sum');
document.getElementById('result').innerHTML = sum(3);

Bien que CommonJs résolve le problème de dépendance, le problème avec CommonJs est qu'il est synchrone, lorsque var sum = require('./sum');

 sum = require('./sum');时，系统将暂停，直到模块准备(ready)完成，这意味着当所有的模块都加载时，这一行代码将阻塞浏览器进程，
因此，这可能不是为浏览器端应用程序定义模块的最佳方式

Ère du module asynchrone : AMD

define([‘add’, ‘sum’], function(add, sum){
  document.getElementById.innerHTML = sum(3);
});

la fonction (ou mot-clé) listera les dépendances et define fonction de rappel en paramètres. Les paramètres de la fonction callback sont dans le même ordre que les dépendances dans le tableau. Cela équivaut à importer un module. Et la fonction de rappel renvoie une valeur, qui est la valeur que vous avez exportée.

CommonJS et AMD résolvent les deux problèmes restants dans le modèle de module :

Résolution des dépendances et Pollution de portée globale . Il suffit de gérer les dépendances de chaque module ou de chaque fichier, et les armes n'ont plus de pollution à l'échelle mondiale.

Bonne implémentation d'AMD : RequireJS Injection de dépendances

RequireJS est un chargeur de module JavaScript. Il peut charger des modules de manière asynchrone selon les besoins. Bien que RequireJS contienne require dans son nom, son objectif n'est pas de prendre en charge la syntaxe require de CommonJS. En utilisant RequireJS, vous pouvez écrire des modules de style AMD.

-------------------- html ----------------------
<p id="result"></p>
<!-- 入口文件 -->
<script data-main="main" src="require.js"></script>
-------------------- main.js ----------------------
define([&#39;sum&#39;], function(sum){
  document.getElementById(&#39;result&#39;).innerHTML = sum(3);
})
-------------------- sum.js ----------------------
define([&#39;add&#39;], function(add)){
   var sum = function(n){
       return add(1,2) + n;
   }
   return sum;
})
-------------------- add.js ----------------------
// add.js
define([], function(){
   var add = function(a, b){
      return a + b;
   };
   return add;
});

Le navigateur charge

, qui à son tour charge index.html. Les fichiers restants et leurs dépendances sont chargés par index.html. require.jsrequire.jsRequireJS et AMD résolvent tous les problèmes que nous avions auparavant. Cependant, cela pose également quelques problèmes moins graves :

1. La syntaxe d'AMD est trop redondante. Parce que tout est encapsulé dans une

fonction

define 2. La liste des dépendances dans le tableau doit correspondre à la liste des paramètres de la fonction. S'il y a beaucoup de dépendances, il est difficile de maintenir l'ordre des dépendances

3. Sous les navigateurs actuels (HTTP 1.1), le chargement de nombreux petits fichiers réduira les performances

Packageur de modules : Browserify

Vous pouvez utiliser les modules CommonJS dans le navigateur, parcourir l'arborescence des dépendances du code via

Browserify et ajouter les dépendances dans le tree Tous les modules sont regroupés dans un seul fichier. Différent de RequireJS, Browserify est un outil en ligne de commande qui doit s'appuyer sur l'environnement NPM

npm install -g browserify

---------------- html.js  --------------------



---------------- add.js  --------------------
module.exports = function add(a, b){
  return a+b;
}
---------------- sum.js  --------------------
var add = require('./add');
module.exports  = function sum(n){
     return add(1, 2) + n;
}
---------------- main.js  --------------------
var sum = require('./sum');
document.getElementById('result').innerHTML = sum(3);

命令: browserify main.js -o bundle.js

Périodes confuses : UMD.
UMD est un ensemble d'instructions if/else utilisé pour identifier le style de module pris en charge par l'environnement actuel

S'il s'agit d'un module global JavaScript objet, CommonJS ou AMD et UMD sont trop encombrants, ajoutent beaucoup de charge de travail supplémentaire et sont difficiles à maintenir.

// UMD 风格编写的 sum 模块
//sum.umd.js
(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD
        define(['add'], factory);
    } else if (typeof exports === 'object') {
        // Node, CommonJS-like
        module.exports = factory(require('add'));
    } else {
        // Browser globals (root is window)
        root.sum = factory(root.add);
    }
}(this, function (add) {
    //  private methods
    //  exposed public methods
    return function(n) {
      return add(1,2) + n;
    }
}));

L'ère brillante : syntaxe du module ES6ES6 utilise les mots-clés

et

pour importer et exporter des modulesimport export

La syntaxe du module ES6 est concise. Bien que tous les navigateurs ne la supportent pas actuellement, vous pouvez utiliser certains outils (babel) pour la convertir

---------------- main.js ---------------
import sum from './sum';
document.getElementById('result').innerHTML = sum(3);
---------------- sum.js ---------------
import add from './add';
export default function sum(n){
   return  add(1, 2) + n;
};
---------------- add.js ---------------
export default function add(a, b){
   return a + b;
};

À l'ère de l'ingénierie : Webpack

虽然gulp、grunt都号称是工程化开发工具，，但个人感觉他们处理的东西还是比较基础，对于模块依赖打包来说，支持不是非常好，反正我是不喜欢gulp.

Webpack 是一个 模块打包器，就像 Browserify 一样，它会遍历依赖树，然后将其打包到一到多个文件。

它与Browserify 不同之处就是 可以处理 CommonJS 、 AMD 和 ES6 模块，并且 Webpack 还有更多实用的东西，比如 代码分离、加载器、插件

简洁的时代：Rollup

rollup 只会将需要的函数包含到打包文件中，从而显著减少打包文件大小

--------------- add.js -----------------
let add = (a,b) => a + b;
let sub = (a,b) => a - b;
export { add, sub };
--------------- sum.js -----------------
import { add } from './add';
export default (n) => {return add(1, 2) + n};
--------------- main.js ----------------
import sum from './sum';
document.getElementById('result').innerHTML = sum(3);

命令: rollup main.js -o bundle.js
--------------- boundle.js ----------------
// bundle.js
let add = (a,b) => a + b;
var sum = (n) => {return add(1, 2) + n};
document.getElementById("answer").innerHTML = sum(3);

发现 add.js的 sub() 函数并没有包含在这个打包文件中，因为没有引用它。

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!