Xiao A ist ein Front-End-Ingenieur eines bestimmten unternehmerischen Teams, das für das Schreiben von Projekten JavaScript-Programmen verantwortlich ist.
Globaler variabler Konflikt
Nach seiner eigenen Erfahrung extrahierte Xiao eine zuerst einige häufig verwendete Funktionen und schrieb sie in Funktionen und brachte sie in eine öffentliche Datei base.js:
Die Codekopie lautet wie folgt:
var _ = {
$: function (id) {return document.getElementById (id); },
getcookie: function (key) {...},
setCookie: function (Schlüssel, Wert) {...}
};
Xiao A stellt diese Funktionen in das Objekt ein, um zu verhindern, dass zu viele globale Variablen Konflikte verursachen. Er sagte dem Rest des Teams, wenn jemand diese Funktionen nutzen möchte, stellen Sie einfach Base.js.
Xiao C ist der Kollegen von Xiao A. Er sagte Xiao A: Seine Seite habe eine Klassenbibliothek namens Unscore.js vorgestellt, und diese Klassenbibliothek wird auch diese globale Variable besetzen, die mit der "Base.js" in Konflikt steht. Xiao Ein Gedanke an sich selbst, dass Unscore.js eine Bibliothek von Drittanbietern ist, und es ist wahrscheinlich schwierig zu ändern, aber Base.js wurde auf vielen Seiten verteilt und es ist unmöglich, es zu ändern. Am Ende hatte Xiao A keine andere Wahl, als die globale Variable von unterstrich.js zu verändern.
Zu diesem Zeitpunkt stellte Xiao A fest, dass das Einfügen von Funktionen in einen Namespace die Wahrscheinlichkeit globaler variabler Konflikte verringern kann, aber das Problem globaler variabler Konflikte nicht löst.
verlassen
Mit der Entwicklung des Geschäfts hat Xiao A eine Reihe von Funktionsbibliotheken und UI -Komponenten geschrieben, z.
Eines Tages berichteten der neue Kollegen Xiao D und Xiao A, dass er Registerkarten auf der Seite zitiert hatte, aber die Funktion war nicht normal. Xiao A fand das Problem auf einen Blick. Es stellte sich heraus, dass Xiao D nicht wusste, dass Tabs.js sich auf Base.js und Util.js stützte, sodass er nicht auf diese beiden Dateien Verweise hinzufügte. Also nahm er sofort Änderungen vor:
Die Codekopie lautet wie folgt:
<script src = "tabs.js"> </script>
<script src = "base.js"> </script>
<script src = "util.js"> </script>
Die Funktion ist jedoch immer noch abnormal. Zu diesem Zeitpunkt lehrte Xiao eine Lektion: "Jeder sagte, es sei eine Abhängigkeit, daher muss die abhängige Partei vor der abhängigen Partei gestellt werden." Es stellt sich heraus, dass Xiao D Base.js und util.js nach tab.js.
Xiao ein Gedanke an sich selbst, dass er der Autor ist und natürlich die Abhängigkeit von Komponenten kennt, aber es ist schwer für andere zu sagen, insbesondere Neuankömmlinge.
Nach einer Weile fungiert Xiao eine zusätzliche Funktion für die Tagschaltkomponente. Um diese Funktion zu implementieren, muss tab.js auch Funktionen in ui.js. Zu diesem Zeitpunkt entdeckte Xiao ein ernstes Problem. Er musste UI.js Referenzen zu allen Seiten hinzufügen, die tab.js genannt wurden! ! !
Nach einer Weile hat Xiao eine optimierte Registerkarten. Als er die Modifikation vorgenommen hatte, passierte ihm etwas Großes. Das MM im Testteam sagte ihm, dass einige Seiten abnormal seien. Als Xiao es sah, erkannte er plötzlich, dass andere Funktionen einiger Seiten Funktionen in util.js. Er entfernte den Verweis auf diese Datei und verursachte einen Fehler. Um sicherzustellen, dass die Funktion normal ist, stellte er den Code erneut wieder her.
Xiao Ein Gedanke noch einmal, gibt es eine Möglichkeit, die Abhängigkeiten zu ändern, ohne die erste Seite eins nach dem anderen zu ändern, und wirkt sich nicht auf andere Funktionen aus?
Modular
Als Xiao A im Internet einkaufte, entdeckte er versehentlich eine neuartige modulare Codierungsmethode, die alle Probleme lösen kann, die es zuvor aufgetreten ist.
In der modularen Programmierung ist jede Datei ein Modul. Jedes Modul wird durch eine Funktion namens definiert erstellt. Nach dem Umwandlung von Base.js in ein Modul wird der Code beispielsweise wie folgt:
Die Codekopie lautet wie folgt:
Definieren Sie (Funktion (erfordern, exportieren, modul) {
Exporte. $ = function (id) {return document.getElementById (id); };
exports.getCookie = function (Schlüssel) {...};
Exporte.Setcookie = Funktion (Schlüssel, Wert) {...};
});
Alle von Base.js bereitgestellten Schnittstellen werden dem Exportobjekt hinzugefügt. Exporte sind eine lokale Variable, und der Code des gesamten Moduls besetzt die Hälfte der globalen Variablen nicht.
Wie nennen Sie also die von einem bestimmte Modul bereitgestellte Schnittstelle? Nehmen Sie als Beispiel tab.js, es hängt von Base.js und util.js ab:
Die Codekopie lautet wie folgt:
Definieren Sie (Funktion (erfordern, exportieren, modul) {
var _ = required ('base.js'), util = required ('util.js');
var div_tabs = _. $ ('tabs');
// .... andere Codes
});
Ein Modul kann die Schnittstellen anderer Module durch die lokale Funktion erhalten. Zu diesem Zeitpunkt sind die Variablen _ und util beide lokale Variablen und der variable Name wird vom Entwickler vollständig gesteuert. Wenn Sie _ nicht mögen, können Sie auch Basis verwenden:
Die Codekopie lautet wie folgt:
Definieren Sie (Funktion (erfordern, exportieren, modul) {
var base = require ('base.js'), util = required ('util.js');
var div_tabs = base. $ ('tabs');
// .... andere Codes
});
Sobald Sie Util.js entfernen und ui.js hinzufügen möchten, ändern Sie einfach die Registerkarten.js:
Die Codekopie lautet wie folgt:
Definieren Sie (Funktion (erfordern, exportieren, modul) {
var base = require ('base.js'), ui = fordert ('ui.js');
var div_tabs = base. $ ('tabs');
// .... andere Codes
});
Lader
Aufgrund des mangelnden nativen Browserunterstützung müssen wir uns auf etwas, das als Lader bezeichnet wird, auf modulare Weise codieren.
Derzeit gibt es viele Implementierungen von Ladern, wie z. B. Request.js und SeaJs. Die Jraiser -Klassenbibliothek hat auch einen eigenen Lader.