Detaillierte Erläuterung des Überwachungsmechanismus in node.js_node.js

Fast alle Build-Systeme verwenden den Überwachungsmechanismus, um das Problem der wiederholten Generierung von Post-Build-Dateien während des Entwicklungsprozesses zu lösen. Unter dem Überwachungsmechanismus müssen wir jedoch lange Zeit Änderungen am Code ertragen Der Code, wir müssen Tee trinken, bevor wir uns erfrischen. Schauen Sie sich die Wirkung an. Hier versuchen wir herauszufinden, warum Uhren keine Wunderwaffe sind, und versuchen, eine bessere Lösung für dieses Problem zu finden.

Fakten, auf denen die Uhr basiert

Wenn eine Datei geändert wird, können wir die Dateiänderungen kennen, die die Änderung verursachen kann, und diese Dateien dann neu erstellen.

Normalerweise ist diese Entsprechung für das Szenario, in dem Datei A in Datei B konstruiert wird, äußerst sicher. Doch in realen Szenarien ist der Bauprozess oft nicht so einfach. Zum Beispiel:

Datei A + Datei B (referenziert durch Datei A) -> Datei C
Wenn in diesem Szenario Datei B geändert wird, kann es schwierig sein, die Dateien zu finden, die für die Erstellungsaufgabe erneut ausgeführt werden müssen, da möglicherweise viele Dateien vorhanden sind, die auf Datei B verweisen.

Es sei denn, wir erstellen einen Abhängigkeitsbaum und aktualisieren den Abhängigkeitsbaum jedes Mal, wenn die Datei aktualisiert wird, und lösen die Dateierstellung basierend auf dem neuen Abhängigkeitsbaum aus. Allerdings muss jedes Plug-in diesen Mechanismus selbst implementieren, was äußerst fehleranfällig ist. Tatsächlich führt der Uhrmechanismus also einfach die gesamte Aufgabe erneut aus. Wenn das Projekt also immer größer wird, wird der Überwachungsmechanismus immer langsamer (da immer mehr Dateien den gesamten Prozess erneut ausführen müssen, auch wenn die für den gesamten Prozess erforderliche Zeit durch Caching reduziert wird).

Lösung

src ist direkt verfügbar

AlloyTeam und @ldjking machen src, um es einfach auszudrücken, direkt ausführbar, platzieren die Konstruktionsaufgabe auf der Browserseite oder erstellen sie überhaupt nicht rechtzeitig, was den Zeitaufwand während der Entwicklung reduziert Verfahren. Die Offline-Konstruktion ist nur für Probleme der Leistungsoptimierung verantwortlich, nicht für die Entwicklungseffizienz.
Typische Vertreter sind LESS, React usw. Es gibt aber auch einige Probleme:

Es ist schwierig, eine elegante Konstruktionsmethode auf der Browserseite zu implementieren, und es ist schwierig, leistungsstarke Funktionen bereitzustellen, um die Entwicklungskosten weiter zu senken. Die meisten davon können nur auf ähnliche Weise wie -Skript.
Die Ausführungsreihenfolge im Entwicklungsmodus stimmt nicht unbedingt mit dem tatsächlichen Szenario überein, was zu unsichtbaren Fehlern führen kann. Wenn beispielsweise ein HTML-Inline implementiert wird, ist Inline im Entwicklungsmodus asynchron, während Inline im Release-Modus synchron ist, was zu unerklärlichen Ergebnissen führt Käfer.
Die Kompilierungsleistung von Browsern ist beispielsweise besorgniserregend. Die Kompilierungsgeschwindigkeit der js-Version von sass ist nahezu unerträglich.
Es ist notwendig, zwei Sätze von Online- und Offline-Konstruktionssystemen vorzuhalten, was die Kosten für die Werkzeugentwicklung erhöht.
Dynamischer Build des lokalen Servers

Eine Tatsache ist: Mit der Unterstützung angemessener Spezifikationen können wir die vom Browser angeforderte Datei auf die Eingabedatei im Dateikonstruktionsprozess zurückführen. Auf diese Weise können wir einen Build-Prozess dynamisch auslösen.

Indem Sie einen Server lokal einrichten, lassen Sie den Server die Anfrage erfassen und dynamisch auf dem Server aufbauen. Solange wir auf die Eintragsdatei zurückgreifen, können wir die Eintragsdatei in die Pipeline werfen, die aus dem Gulp-Plug-In besteht, und die Ausgabe ist die vom Browser benötigte Datei.

Auf diese Weise können wir alle oben genannten Probleme lösen.