Warum sollten Webseiten modularisiert werden?

In diesem Artikel wird erläutert, warum die Web-Modularisierung nützlich ist, und es werden einige Mechanismen vorgestellt, mit denen sich die Web-Modularisierung jetzt implementieren lässt. Hier ist ein weiterer Artikel, der die Designphilosophie des von RequireJS verwendeten Funktionsumbruchformats erläutert.

Problem §1

Websites werden nach und nach in Web-Apps umgewandelt

Die Komplexität des Codes nimmt allmählich zu

Assemblierung wird schwierig

Entwickler-JS-Dateien /Module, die getrennt werden möchten

Beim Deployment kann der Code in mehrere HTTP-Anfragen optimiert werden

Lösung §2

Frontend-Entwickler benötigen eine solche Lösung:

Einige dieser APIs #include/import/require

Haben die Möglichkeit, verschachtelte Abhängigkeiten zu laden

Einfach für Entwickler zu verwenden und haben Optimierungstools hinter sich. Unterstützung, hilfreich für Bereitstellung

API zum Laden von Skripten § 3

Sortieren Sie zunächst die API zum Laden von Skripten. Hier gibt es einige Optionen:

Dojo: dojo.require("some.module")
LABjs: $LAB.script("some/module.js")
CommonJS: require("some/module")

Alle Karten zum Laden von some/path/some/module.js. Idealerweise würden wir die Syntax von CommonJS wählen, da sie wahrscheinlich häufiger verwendet wird und wir Code wiederverwenden möchten.

Derzeit hoffen wir auch, über eine Syntax zum Laden vorhandener Nur-Text-JavaScript-Dateien zu verfügen, damit Entwickler nicht das gesamte JavaScript neu schreiben müssen, um vom Skriptladen zu profitieren.

Wir brauchen jedoch etwas, das im Browser besser funktioniert. require() von CommonJS ist ein synchroner Aufruf, der erwartet, dass das Modul sofort zurückgegeben wird. Im Browser funktioniert das allerdings nicht so gut.

　Asynchron und Synchron§ 4

　Das folgende Beispiel verdeutlicht das Grundproblem von Browsern. Angenommen, wir haben ein Employee-Objekt und möchten, dass ein Manager-Objekt vom Employee-Objekt abgeleitet wird. Nehmen wir das Beispiel: Wir könnten unser Skript verwenden, um die API zu laden und sie wie folgt zu codieren:

var Employee = require("types/Employee");function Manager () {
    this.reports = [];
}//Error if require call is asyncManager.prototype = new Employee();

Wie in den Kommentaren oben gezeigt, ist require() asynchron , dieser Code wird nicht funktionieren. Das synchrone Laden von Skripten im Browser beeinträchtigt jedoch die Leistung. Was also tun?

Laden von Skripten: XHR§ 5

Die Verwendung von XMLHttpRequest (XHR) zum Laden von Skripten ist sehr attraktiv. Wenn wir XHR verwenden, können wir den obigen Text berühren, was bedeutet, dass wir reguläre Ausdrücke verwenden können, um require()-Aufrufe zu finden, um sicherzustellen, dass wir diese Skripte laden, und dann eval() oder Skriptelemente verwenden können, um den Textinhalt an den Benutzer zu übergeben XHR-Ladeskript.

Die Verwendung von eval() zur Evaluierung von Modulen ist nicht gut:

Entwicklern wurde gesagt, dass die Verwendung von eval() nicht gut ist.

Einige Umgebungen unterstützen eval() nicht.

Schwer zu debuggen. Die Inspektoren von Firebug und WebKit verfügen über eine //@sourceURL=-Konvention zum Benennen des ausgewerteten Textes, diese Funktion wird jedoch nicht von allen Browsern unterstützt.

Verschiedene Browser bewerten den Kontext unterschiedlich. execScript im IE könnte es tun, aber es bedeutet auch mehr bewegliche Teile.

Die Verwendung eines Skript-Tags mit Textinhalt, um ihn als Dateitext festzulegen, ist ebenfalls nicht gut:

Beim Debuggen stimmt die angezeigte Fehlerzeilennummer nicht mit der Nummer der Quelldatei überein.

XHR hat immer noch Probleme bei domänenübergreifenden Anfragen. Einige Browser bieten mittlerweile domänenübergreifende XHR-Unterstützung, aber nicht alle. Und IE hat beschlossen, ein anderes API-Objekt zu erstellen: XDomainRequest, um domänenübergreifende Anforderungen zu implementieren. Es gibt mehr Dinge, die geändert werden müssen, und es ist einfacher, Fehler zu machen. Insbesondere müssen Sie sicherstellen, dass keine nicht standardmäßigen HTTP-Header gesendet werden oder eine weitere „Preflight“-Anfrage erforderlich ist, um sicherzustellen, dass die Cross-Origin-Anfrage zulässig ist.

Dojo nutzt den XHR-basierten Loader über eval(). Obwohl es funktioniert, war es für Entwickler schon immer eine Quelle von Problemen. Dojo verfügt über einen xdomain-Loader, muss jedoch das erforderliche Modul mithilfe eines Funktions-Wrappers ändern, damit das Tag „script src="“ zum Laden des Moduls verwendet werden kann. Es gibt auch viele Grenzfälle und Variationen, die den Programmierern Schwierigkeiten bereiten.

Wir können es besser machen, wenn wir einen neuen Skript-Loader erstellen.

Laden von Skripten: Web-Worker § 6

Web-Worker sind vielleicht eine andere Möglichkeit, Skripte zu laden, aber:

Es ist nicht gut plattformübergreifend

Es handelt sich um eine Messaging-API, und das Skript muss möglicherweise mit dem DOM interagieren. Es verwendet lediglich einen Worker, um den Text des Skripts abzurufen, übergibt den Text dann an das Hauptfenster zurück und verwendet dann eval/script, um das Skript auszuführen . Dieser Ansatz bringt alle oben genannten Probleme von XHR mit sich.

Skript laden: document.write()§ 7

Document.write() kann zum Laden von Skripten aus anderen Domänen verwendet werden und die übliche Art des Skripts im Browser abbilden verwendet, sodass es für einfaches Debuggen verwendet werden kann.

Allerdings können wir im asynchronen vs. synchronen Beispiel das Skript nicht direkt ausführen. Idealerweise kennen wir vor der Ausführung des Skripts über require() die relevanten Abhängigkeiten und stellen sicher, dass diese Abhängigkeiten zuerst geladen werden. Aber wir können nicht darauf zugreifen, bevor das Skript ausgeführt wird.

　　而且，document.write()在页面载入后就不工作了。对于你的网站，一个好的方法是在用户需要进行下一步操作时来载入脚本。

　　最后，通过document.write()载入脚本或阻塞页面的渲染。要让你的网站有最佳表现，这个方法是不可取的。

　　脚本载入：head.appendChild(script)§ 8

　　我们可以在需要时创建脚本并将它们添加到头部：

var head = document.getElementsByTagName('head')[0],
    script = document.createElement('script');
 
script.src = url;
head.appendChild(script);

上面的脚本片段多了一点东西，不过那正是基本的思想。这种方法比document.write要好，因为它不会阻塞页面的渲染并且在页面载入后仍能工作。

　　但是，它仍然有同步VS异步例子的问题：理想情况下，在执行脚本前我们能够通过require()知道相关依赖项，并且确保这些依赖项被首先载入。

　　函数封装 § 9

　　在执行我们的脚本前，我们需要知道相关依赖项并确保已经将其载入。做这件事的最好方法是通过函数封装来构造我们的模块载入API。像这样：

define(    //The name of this module
    "types/Manager",    //The array of dependencies
    ["types/Employee"],    //The function to execute when all dependencies have loaded. The
    //arguments to this function are the array of dependencies mentioned
    //above.
    function (Employee) {
        function Manager () {
            this.reports = [];
        }        //This will now work
        Manager.prototype = new Employee();        
        //return the Manager constructor function so it can be used by
        //other modules.
        return Manager;
    }
);

这是ReguireJS的句法。如果你想载入没有定义成模块的纯文本的JavaScript的话，有一种简单的句法：

require(["some/script.js"], function() {
    //This function is called after some/script.js has loaded.
});

选择这种句法是因为，它足够简洁并且允许载入者使用head.appendChild(script)载入类型。

　　出于在浏览器中良好工作的需要，它有不同于普通的CommonJS句法。有建议说普通的CommonJS句法可以使用head.appendChild(script)的载入类型，如果服务器进程有封装的函数可以将模块转换成传输格式的话。

　　我相信不强制使用一个运行时服务器进程来转换代码是很重要的事：

一是调试变的很怪异，因为服务器在注入封装函数时会导致源文件的行号关闭。

二是需要做更多的工作。前端开发应该尽可能的使用静态文件。

　　关于设计的力量和功能封装格式的使用案例的更多细节，被叫做异步模块定义（Asynchronous Module Definition (AMD)），请前往为什么是AMD?

　　原文地址：http://www.php.cn/website-design-ask-340211.html

以上就是为什么要web网页模块化？的内容，更多相关内容请关注PHP中文网（www.php.cn）！