Verstehen Sie die modulare Entwicklung von Javascript_Javascript-Kenntnissen

Little A ist Front-End-Ingenieur eines Startup-Teams und verantwortlich für das Schreiben des Javascript-Programms des Projekts.

Globaler Variablenkonflikt

Basierend auf seinen eigenen Erfahrungen extrahierte Xiao A zunächst einige häufig verwendete Funktionen, schrieb sie als Funktionen und legte sie in einer öffentlichen Datei base.js ab:

Code kopieren Der Code lautet wie folgt:

var _ = {
$: function(id) { return document.getElementById(id); },
GetCookie: function(key) { ... },
setCookie: function(key, value) { ... }
};

Little A fügt diese Funktionen in das _-Objekt ein, um Konflikte zu verhindern, die durch zu viele globale Variablen verursacht werden. Er teilte anderen Teammitgliedern mit, dass jeder, der diese Funktionen nutzen möchte, einfach base.js importieren solle.

Little C ist ein Kollege von Little A. Er berichtete Little A: Auf seiner Seite wurde eine Klassenbibliothek namens underscore.js eingeführt, und diese Klassenbibliothek wird auch die globale Variable _ belegen, sodass sie _ in der Basis folgt. js-Konflikte. Little A dachte bei sich, dass underscore.js eine Bibliothek eines Drittanbieters ist und wahrscheinlich schwer zu ändern ist, aber base.js wurde auf vielen Seiten bereitgestellt und es ist unmöglich, es zu ändern. Am Ende hatte Little A keine andere Wahl, als die von underscore.js belegten globalen Variablen zu ändern.

Zu diesem Zeitpunkt entdeckte Little A, dass die Platzierung aller Funktionen in einem Namensraum die Wahrscheinlichkeit globaler Variablenkonflikte verringern kann, das Problem globaler Variablenkonflikte jedoch nicht löst.

Abhängigkeit

Mit der Geschäftsentwicklung hat Xiao A eine Reihe von Funktionsbibliotheken und UI-Komponenten geschrieben, beispielsweise die Tab-Switching-Komponente tabs.js. Diese Komponente muss Funktionen in base.js und util.js aufrufen.

Eines Tages berichteten die neuen Kollegen Xiao D und Xiao A, dass sie auf der Seite auf tabs.js verwiesen hatten, die Funktion jedoch nicht normal war. Little A entdeckte das Problem auf den ersten Blick. Es stellte sich heraus, dass Little D nicht wusste, dass tabs.js von base.js und util.js abhängt, und er fügte keine Verweise auf diese beiden Dateien hinzu. Also nahm er sofort Änderungen vor:

Code kopieren Der Code lautet wie folgt:

Zu diesem Zeitpunkt war die Funktion jedoch immer noch abnormal. Little A lehrte Little D: „Es heißt, abhängig zu sein, daher muss die abhängige Partei vor der vertrauenden Partei stehen.“ Es stellt sich heraus, dass Xiao D base.js und util.js nach tabs.js eingefügt hat.

Little A dachte bei sich, dass er als Autor natürlich die Abhängigkeiten von Komponenten kennt, es aber für andere, insbesondere für Neulinge, schwer zu sagen ist.

Nach einiger Zeit fügte Xiao A der Tab-Switching-Komponente eine Funktion hinzu. Um diese Funktion zu realisieren, muss tabs.js die Funktion auch in ui.js aufrufen. Zu diesem Zeitpunkt entdeckte Little A ein ernstes Problem. Er musste auf allen Seiten, die tabs.js aufriefen, Verweise auf ui.js hinzufügen! ! !

Nach einiger Zeit optimierte Xiao A tabs.js. Diese Komponente hängt nicht mehr von util.js ab, daher entfernte er die Verweise auf util.js auf allen Seiten, die tabs.js verwenden. Seine Änderung verursachte ein großes Problem. Das Testteam MM teilte ihm mit, dass einige Seiten abnormal seien. Little A warf einen Blick darauf und stellte plötzlich fest, dass andere Funktionen einiger Seiten Funktionen in util.js verwendeten. Er entfernte den Verweis auf diese Datei und es trat ein Fehler auf. Um die normale Funktionalität sicherzustellen, stellte er den Code wieder her.

Noch einmal ein kleiner Gedanke: Gibt es eine Möglichkeit, Abhängigkeiten zu ändern, ohne die Seiten einzeln zu ändern, ohne andere Funktionen zu beeinträchtigen?

Modular

Als Little A im Internet surfte, entdeckte er zufällig eine neuartige modulare Codierungsmethode, die alle Probleme lösen konnte, auf die er zuvor gestoßen war.

Bei der modularen Programmierung ist jede Datei ein Modul. Jedes Modul wird durch eine Funktion namens „define“ erstellt. Nach der Umwandlung von base.js in ein Modul sieht der Code beispielsweise wie folgt aus:

Code kopieren Der Code lautet wie folgt:

define(function(require, exports, module) {
exports.$ = function(id) { return document.getElementById(id); };
exports.getCookie = function(key) { ... };
exports.setCookie = function(key, value) { ... };
});

Die von base.js bereitgestellten Schnittstellen werden dem Exportobjekt hinzugefügt. Exporte sind lokale Variablen, und der Code des gesamten Moduls belegt nicht die Hälfte der globalen Variablen.

Wie rufe ich die von einem bestimmten Modul bereitgestellte Schnittstelle auf? Nehmen Sie tabs.js als Beispiel, es hängt von base.js und util.js ab:

Code kopieren Der Code lautet wie folgt:

define(function(require, exports, module) {
var _ = require('base.js'), util = require('util.js');
var div_tabs = _.$('tabs');
// .... Andere Codes
});

Ein Modul kann die Schnittstellen anderer Module über die lokale Funktion require erhalten. Zu diesem Zeitpunkt sind die Variablen _ und util beide lokale Variablen und die Variablennamen werden vollständig vom Entwickler gesteuert. Wenn Ihnen _ nicht gefällt, können Sie auch base:
verwenden

Code kopieren Der Code lautet wie folgt:

define(function(require, exports, module) {
var base = require('base.js'), util = require('util.js');
var div_tabs = base.$('tabs');
// .... Andere Codes
});

Wenn Sie util.js entfernen und ui.js hinzufügen möchten, ändern Sie einfach tabs.js:

Code kopieren Der Code lautet wie folgt:

define(function(require, exports, module) {
var base = require('base.js'), ui = require('ui.js');
var div_tabs = base.$('tabs');
// .... Andere Codes
});

Lader

Wenn wir modular programmieren wollen, müssen wir aufgrund der fehlenden nativen Browserunterstützung einen sogenannten Loader verwenden.

Derzeit gibt es viele Implementierungen von Loadern, wie zum Beispiel require.js und seajs. Die JRaiser-Klassenbibliothek verfügt außerdem über einen eigenen Loader.