JavaScript-Refactoring: Modulpartitionierung und Namespaces

Normalerweise verfügen die Entwickler in unserem Team über beträchtliche technische Kenntnisse und umfangreiche Erfahrung in der Java-Sprache und verfügen über viele ausgereifte und vernünftige Protokolle, verschiedene Arten von Code-Hazard-Inspektionstools und sogar Pläne im Rahmen der Teamüberprüfung und unangekündigten Inspektion. Der Front-End-Code ist jedoch nicht wie ein Kind, das niemanden interessiert. Er wird nicht nur leicht unterschätzt und verachtet, er führt auch zu schlechter Qualität und schlechter Wartbarkeit Mangel an hervorragenden Front-End-Entwicklern in Bezug auf Fähigkeiten.
JavaScript ist ein wichtiger Teil des Front-End-Codes. Mit zunehmender Version wird das Produkt immer größer und die Rekonstruktion der JavaScript-Ebene muss im Laufe des Prozesses schrittweise gestärkt werden.

Wenn die Codemenge ein bestimmtes Niveau erreicht, ist es am besten, JavaScript zusammen mit Seitenmodulkomponenten (z. B. benutzerdefinierten FreeMarker-Tags) zu modularisieren.
Der größte Vorteil der Modularität ist die Unabhängigkeit und Wartbarkeit. Es besteht keine Notwendigkeit, Problemstellen in massiven JS zu lokalisieren. Es ist einfacher, leichter zu verstehen und zu akzeptieren und einfacher anzupassen.
Es ist am besten, die Abhängigkeiten zwischen Modulen einfach zu halten. Wenn es beispielsweise eine common.js gibt, wird diese zum häufigsten Funktionscode und enthält keine einheitliche Verwaltung globaler Variablen unabhängig veröffentlicht werden, und andere Komponenten-JS können sich problemlos darauf verlassen. Beispielsweise müssen wir häufig eine Trimmmethode für einen String implementieren, aber js selbst verfügt nicht über diese. Dann können wir den String-Prototyp in common.js erweitern, um ihn zu implementieren, was für externe Benutzer transparent ist.

Die Verwendung von Namespaces ist eine gute Möglichkeit, zu verhindern, dass js sich gegenseitig stören. Wenn js objektorientiert ist, muss es den Prinzipien der Kapselung, Vererbung und Polymorphie folgen.
In Bezug auf die Verwendung des Java-Imports hoffe ich, dass dieser Namespace einen solchen Effekt erzielen kann:
Ich habe ein Modul, das eine Methode webOnlinePlay enthält importiert, wenn ich hoffe, dass die Ausführung von js falsch ist:
Java-Code
webOnlinePlay(); //Fehler! Methode konnte nicht gefunden werden

Aber wenn ich dieses Modul einführe:
Java Code
import("play");

webOnlinePlay(); //Richtig, Sie können die Methode finden

Tatsächlich ist es sehr einfach, einen solchen Effekt zu erzielen, weil eine Methode webOnlinePlay() standardmäßig aufgerufen wird) ist im Wesentlichen: window.webOnlinePlay(), richtig?
Beim Import("play") ist der interne Implementierungsmechanismus also wie folgt:
Java-Code
var module = new playModule();

Für jede Methode in diesem Modul All werden zur direkten Verwendung in das Fensterobjekt importiert:
Java-Code
window[methodName] = module[methodName]; Tatsächlich gibt es hier kein Geheimnis, sondern diese Art von On-Demand Aber die Idee bringt eine Idee zur Front-End-Rekonstruktion mit sich, eine Idee einer verbesserten Wartbarkeit durch Kapselung, nicht wahr?

Wenn Sie schlau sind, können Sie auch eine Frage stellen:
Wenn ich das Play-Modul nicht importiere und diese Seite es nicht benötigt, kann ich dann nicht einmal die play.js laden?
Achten Sie natürlich auf die folgende Zerlegung – den Teil über das dynamische Laden von js.