Heim  >  Artikel  >  Web-Frontend  >  Warum ist Modularität erforderlich? Einführung in gängige modulare Lösungen in js

Warum ist Modularität erforderlich? Einführung in gängige modulare Lösungen in js

不言
不言nach vorne
2018-10-26 15:20:292598Durchsuche

Der Inhalt dieses Artikels befasst sich mit der Frage, warum Modularisierung erforderlich ist. Eine Einführung in häufig verwendete modulare Lösungen in js hat einen gewissen Referenzwert. Freunde in Not können darauf verweisen.

Warum Modularisierung erforderlich ist

Vor dem Aufkommen von ES6 bot die JS-Sprache selbst keine Modularisierungsfähigkeiten, was einige Probleme für die Entwicklung verursachte, von denen das wichtigste ist Zwei Probleme dürften die globale Umweltverschmutzung und das Chaos im Abhängigkeitsmanagement sein.

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

Im obigen Code haben wir die von a.js bereitgestellte Funktion sayName zweimal aufgerufen und unterschiedliche Ergebnisse ausgegeben. Dies liegt offensichtlich daran, dass beide Dateien dem Variablennamen Werte zuweisen, sodass sie beide verursachen andere hatten einen Einfluss. Natürlich können wir beim Schreiben von Code darauf achten, keine vorhandenen Variablennamen zu definieren, aber wenn eine Seite auf ein Dutzend Dateien mit mehreren hundert Zeilen verweist, ist es offensichtlich nicht realistisch, sich alle definierten Variablen zu merken.

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

Der obige Code zeigt, dass wir bei der Einführung mehrerer Dateien die Reihenfolge sicherstellen müssen, um sicherzustellen, dass beim Ausführen einer bestimmten Datei ihre Abhängigkeiten im Voraus geladen wurden Es ist denkbar, dass wir angesichts größerer Dateien und Projekte mit mehr Abhängigkeiten umgehen müssen, was umständlich und fehleranfällig ist.

Um diese Probleme zu lösen, sind in der Community viele Spezifikationen entstanden, um modulare Funktionen für die JS-Sprache bereitzustellen. Mithilfe dieser Spezifikationen kann unsere Entwicklung komfortabler und sicherer gemacht werden.

Gemeinsame modulare Lösungen

CommonJS

CommonJS ist eine der von der Community vorgeschlagenen modularen Lösungen, und Node.js folgt diesem festgelegten Plan.

Grundlegendes Schreiben

// 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'

Im obigen Code ist die Datei a.js der Anbieter des Moduls und die Datei b.js der Aufrufer des Moduls.

Spezifikation

  1. Jede Datei ist ein Modul;

  2. bereitgestellt innerhalb eines ModulsModul Objekt, Darstellung des aktuellen Moduls;

  3. Das Modul verwendet Exporte, um seine eigenen Funktionen/Objekte/Variablen usw. verfügbar zu machen; 🎜> Das Modul importiert andere Module über die Methode

  4. Die Spezifikationen von CommonJS sind einfach die oben genannten 4 Elemente Die Beispiele in der grundlegenden Schreibmethode: Obwohl Node.js in der tatsächlichen Implementierung der CommonJS-Spezifikation folgt, nimmt es dennoch einige Anpassungen daran vor. AMD

  5. AMD ist eine der modularen Spezifikationen, und RequireJS folgt diesem Satz von Spezifikationen.

Grundlegende Verwendung

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

Im obigen Code exportiert die Datei a.js das Modul

Spezifikation

In AMD verwendet das verfügbar gemachte Modul define Funktion

define(moduleName, [], callback);

Wie im obigen Code verfügt die Funktion define über drei Parameter

moduleName. Dieser Parameter kann weggelassen werden und stellt im Allgemeinen den Namen des Moduls dar von geringem Nutzen

    ['name1', 'name2'], der zweite Parameter ist ein Array, das andere Module angibt, von denen das aktuelle Modul abhängt. Wenn es keine abhängigen Module gibt, ist dies der Fall Der Parameter kann weggelassen werden
  • Rückruf, der dritte Parameter ist ein erforderlicher Parameter, es handelt sich um eine Rückruffunktion und im Inneren befindet sich der relevante Code des aktuellen Moduls
  • Andere
  • ADM-Funktionen Es ist der größte Unterschied zwischen der ADM-Spezifikation und der CMD-Spezifikation, die als nächstes eingeführt wird: vor dem Ausführen des Rückrufs Beim aktuell geladenen Modul werden zuerst alle abhängigen Pakete geladen. Dies ist der dritte Schritt der Definitionsfunktion. Die in den beiden Parametern angegebenen abhängigen Pakete.

  • CDM

Grundlegende Schreibmethode

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

Der obige Code ist die grundlegende Schreibmethode des CMD-Spezifikationsexportmoduls;

Spezifikation

Aus der Schreibmethode geht hervor, dass die Schreibmethode von CMD der von AMD sehr ähnlich ist. Der Hauptunterschied ist der Unterschied im Abhängigkeitsladezeitpunkt. Wie oben erwähnt, ist AMD vom Front-End abhängig Die Spezifikation befürwortet einfach das Proximity-Prinzip: Abhängigkeiten werden nicht geladen, bevor das Modul ausgeführt wird. Wenn eine bestimmte Abhängigkeit erforderlich ist, wird sie erneut geladen.

UMD

Wenn CommonJS, AMD und CMD parallel laufen, wird eine Lösung benötigt, die mit ihnen kompatibel ist, sodass wir bei der Entwicklung nicht mehr auf die von uns befolgten Spezifikationen achten müssen abhängige Module, und die Entstehung von UMD soll dieses Problem lösen.

Grundlegende Schreibmethode

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

Der obige Code ist die grundlegende Schreibmethode von UMD. Wie aus dem Code ersichtlich ist, kann er sowohl die CommonJS-Spezifikation als auch die AMD-Spezifikation unterstützen.

ES6-Modul

Das Obige stellt jeweils CommonJS, AMD, CMD und UMD vor. Sie sind alle Beiträge der Community zur Modularisierung von JS. Der grundlegende Grund für die Entstehung dieser Spezifikation ist JS-Sprache verfügt derzeit über keine Modularitätsfunktionen. Die JS-eigene Modularisierungslösung kann derzeit durch Modularitätsfunktionen ersetzt werden, die häufig im Browser verwendet werden Seite und Knotenseite.

Die Modularisierungsfunktion in ES6 besteht aus zwei Befehlen:

export

und

import

Der Befehl

export

wird verwendet, um die externe Schnittstelle des zu spezifizieren Modul. Der Befehl import wird zum Importieren von Funktionen verwendet, die von anderen Modulen bereitgestellt werden. ExportbefehlIn ES6 ist eine Datei ein Modul. Die Variablen/Funktionen innerhalb des Moduls sind von außen nicht zugänglich In der Außenwelt können sie von anderen Modulen verwendet werden, indem Sie sie über den Befehl export exportieren

// 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的变量或函数。

Das obige ist der detaillierte Inhalt vonWarum ist Modularität erforderlich? Einführung in gängige modulare Lösungen in js. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:segmentfault.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen