Ausführliche Erläuterung der Probleme mit Front-End-Template-Engines

Die Front-End-Template-Engine muss während der Entwicklung transparent sein

Transparenz bedeutet, dass ich nach dem Einrichten der Entwicklungsumgebung Code schreiben und aktualisieren kann Browser Sie können die neuesten Effekte sehen, ohne zusätzliche Befehle auszuführen oder auf einen Prozess zu warten.

Daher sind alle Template-Engines, die auf dem Kompilierungsprozess basieren, nicht für den Front-End-Einsatz geeignet. Die Kompilierung kann nur eine Funktion der Template-Engine sein, keine Voraussetzung für die Verwendung

Genauer gesagt , Verwendung von FileWatch usw. Methoden zum Erkennen von Dateiänderungen und zum automatischen Kompilieren liegen nicht im Rahmen meiner Überlegungen, da dies zu zusätzlichen Wartezeiten führt.

Daraus kann geschlossen werden, dass die Front-End-Vorlagen-Engine sollte die Fähigkeit haben, im reinen Frontend verwendet zu werden. Die Fähigkeit, in der Umgebung zu verwenden, wird analysiert.

Die Front-End-Vorlagen-Engine muss über gute Laufzeit-Debugging-Funktionen verfügen

Aufgrund der Unsicherheit des Benutzerverhaltens, der Unsicherheit der Ausführungsumgebung und der Unsicherheit verschiedener Durch die Auswirkungen von Skripten von Drittanbietern usw. ist es für das Front-End schwierig, eine vollständige Fehlerbehandlung und -verfolgung zu erreichen, was auch dazu führt, dass das Front-End Probleme direkt online beheben muss

Und wenn das Das Problem tritt auf der Ebene der Template-Engine auf. Es werden Vorlagen benötigt. Die Engine bietet gute Debugging-Funktionen.

Im Allgemeinen sind die Debugging-Funktionen kompilierter Funktionen schwächer als die der ursprünglich manuell geschriebenen Template-Fragmente, da dies im Grunde genommen automatisch generierte Funktionen sind nicht lesbar und haben Haltepunkte.

Daher sollte eine Template-Engine für den Front-End-Einsatz an dieser Stelle über den Modus verfügen, von „Ausführen der kompilierten Funktion zum Erhalten von HTML“ zurück zu „Parsen der ursprünglichen Vorlage“ zu wechseln und dann unter bestimmten Umständen die Funktion zum Erhalten von HTML ausführen. Das heißt, es sollte das Umschalten zwischen den beiden Modi unterstützen

oder noch besser, eine Funktion, die von einer leistungsstarken Front-End-Template-Engine kompiliert und generiert werden kann direkt auf das ursprüngliche Vorlagenfragment mithilfe von Source Map oder anderen benutzerdefinierten Mitteln zurückgebildet, aber es gibt derzeit keine Vorlagen-Engines, die diese Funktion implementieren

Front-End-Vorlagen-Engines müssen für das Zusammenführen von Dateien geeignet sein

Bevor HTTP/2 populär wurde, war das Zusammenführen von Dateien noch eine Front-End-Leistung. Ein wichtiges Mittel zur Optimierung, Vorlagen müssen als Teil der Datei immer noch zusammengeführt werden

In der Vorlage Engine, die eine Kompilierungsfunktion bereitstellt, können wir die Kompilierung verwenden, um die Vorlage in JavaScript-Quellcode umzuwandeln, und dann in JavaScript im Wesentlichen eine Dateizusammenführung durchführen

Aber wenn wir die ursprünglichen Vorlagenfragmente aus Gründen wie den erwähnten Debugging-Funktionen behalten möchten oben, dann muss die Template-Engine selbst das Zusammenführen von Template-Fragmenten in einer Datei unterstützen

Die meisten Engines, die nur das Parsen einer Eingabezeichenfolge als Vorlage unterstützen, verfügen nicht über diese Funktion. Sie sind von Natur aus nicht in der Lage, eine ganze Zeichenfolge aufzuteilen mehrere Vorlagenfragmente und kann daher die Dateizusammenführung auf der Ebene der Vorlagenfragmente nicht unterstützen. Die beste Möglichkeit besteht darin, die Vorlagensyntax auf „Fragmenten“ zu basieren

Die Front-End-Template-Engine muss für die Verhinderung von XSS verantwortlich sein

Aus Sicherheitsgründen stellt das Front-End strenge Anforderungen an die XSS-Kontrolle

Eine angemessenere Eine Möglichkeit, XSS im Front-End zu verhindern, besteht darin, die Whitelist-Richtlinie „Standard-Escape“ zu verwenden

Auf dieser Grundlage

muss

eine vernünftige Template-Engine Standard-Escape unterstützen, also alle Daten Die Ausgabe wird standardmäßig von der Escape-Logik verarbeitet und Schlüsselsymbole werden in entsprechende HTML-Entitätssymbole umgewandelt. Um den Eindringpfad von XSS aus dem Stammverzeichnis zu entfernen, müssen natürlich nicht alle Inhalte maskiert werden Im System müssen Benutzer zwangsläufig Rich-Text eingeben. Daher muss eine bestimmte Syntax unterstützt werden, um eine Rich-Text-Ausgabe zu generieren. Beachten Sie jedoch immer den Sonderfall der nicht maskierten Ausgabe 🎜>Die Front-End-Template-Engine muss die Wiederverwendung von Fragmenten unterstützen

Dies ist keine Anforderung der Front-End-Template-Engine. Tatsächlich sollte dies jede Template-Engine unterstützen die Wiederverwendung von Fragmenten. Backends wie Velocity, Smarty usw. haben alle diese Funktion

Die sogenannte Fragment-Wiederverwendung sollte folgende Ebenen haben:

A Das Fragment kann an einer anderen Stelle eingeführt werden, was dem Effekt der Verwendung einer Variablen überall entspricht.

1. Ein Fragment ist Wenn es eingeführt wird, können ihm verschiedene Daten übergeben werden, was dem entspricht Wirkung einer überall verwendeten Funktion

2. Ein Fragment kann extern ersetzt werden, aber wenn das Fragment nicht extern bereitgestellt wird, wird ein Standardinhalt beibehalten, ähnlich dem Strategiemuster in Designmustern

3. Es gibt viele Template-Engines, die Punkt 1 und 2 erfüllen, aber es gibt nicht viele Front-End-Template-Engines, die Punkt 3 erfüllen, und die Back-End-Module Razor, Smarty usw. alle haben diese Funktion

Die Front-End-Template-Engine muss die Verarbeitung bei der Datenausgabe unterstützen

Die sogenannte Datenausgabeverarbeitung bedeutet, dass Daten verarbeitet werden müssen, wenn Daten ausgegeben werden Ausgabe Führen Sie zusätzliche Konvertierungen durch, die gebräuchlichsten wie String-Trim-Operationen, technischere wie Markdown-Konvertierung usw.

Es stimmt, dass die Datenkonvertierung vollständig durch JavaScript-Logik verarbeitet werden kann, bevor die Daten an übergeben werden Dies führt jedoch zu einer Menge hässlichem und redundantem Code und wirkt sich auch negativ auf die Wiederverwendbarkeit der Logik selbst aus

Normalerweise verwenden Template-Engines Filter, um eine zusätzliche Datenverarbeitung durchzuführen, ähnlich der Logik von Pipelines in Bash. Die Implementierung und Registrierung von Filtern wird beispielsweise unterschiedliche Designs haben, während andere Template-Engines den Filter selbst direkt registrieren. Für uns ist es schwierig zu sagen, wer gut ist und wer ist schlecht

Nachdem die Template-Engine jedoch die Datenausgabeverarbeitung unterstützt, führt dies zu einer neuen Verstrickung im Codierungsprozess, nämlich welche Datenverarbeitung durch den Filter der Template-Engine implementiert werden soll und welche Daten sollten von der Template-Engine implementiert werden, bevor sie an die Template-Engine übergeben werden. Implementieren Sie Ihre eigene Logik. Dieses Thema ist eine lange Diskussion, wenn es für das aktuelle Thema nicht relevant ist.

Die Front-End-Vorlagen-Engine muss dynamische Daten unterstützen.

In Tatsächlich sind viele Daten nicht statisch. Beispielsweise bietet Angular ähnliche Dinge, indem es die get-Methode von Model umschreibt Obwohl die ES5-Getter-Unterstützung direkt auf Sprachebene bereitgestellt wird, verwenden wir diese Sprachfunktion in den meisten Front-End-Entwicklungsszenarien immer noch nicht. Stattdessen entscheiden wir uns dafür, dynamische Daten in Get-Methoden einer Art Objekt zu kapseln

Die Template-Engine sollte dies auch bei der Konvertierung von Daten in HTML-Fragmente berücksichtigen und diese dynamisch berechneten Daten gut unterstützen.

Um es klarer auszudrücken: Die Template-Engine sollte nicht nur Pure Object (Plain) akzeptieren Objekt) als Eingabe, sollte aber offener für die Annahme dynamischer Daten mit der Get-Methode sein

Eine vernünftigere Logik ist, dass, wenn ein Objekt über eine Get-Methode verfügt (die Template-Engine bestimmt diese Schnittstelle), die Daten über abgerufen werden In anderen Fällen wird das Eingabeobjekt als einfaches Objekt betrachtet und die Standardlogik zur Attributerfassung verwendet

Die Front-End-Vorlagen-Engine muss eng in den asynchronen Prozess integriert sein

Ein sehr häufiges Beispiel ist, dass wir ein AMD-Modul haben, das global verwendete Konstanten speichert und die Template-Engine diese Konstanten verwenden muss. Natürlich können wir JavaScript dieses Modul asynchron abrufen lassen, bevor wir die Template-Engine verwenden, und dann die Konstanten als Daten an die Template-Engine übergeben, aber das ist eine Möglichkeit, das Geschäft und die Ansicht zu koppeln Ich glaube nicht, dass das ein schönes Design ist, also hoffen wir, dass die Ausgabe der

-Vorlage selbst zu einer asynchronen Methode wird, anstatt wie jetzt eine Zeichenfolge direkt zurückzugeben
Bei der Analyse der Abhängigkeit der Vorlage von asynchronen Vorgängen wird die Spleißlogik der gesamten Zeichenfolge in mehrere asynchrone Operationen unterteilt
Asynchron erfordert Warten, und das Warten ist unbekannt. Müssen Sie aus Sicht der Leistung eine Ausgabe im Stream-Stil in Betracht ziehen, um einen Absatz zu vervollständigen und einen Absatz bereitzustellen? Logik oder eine benutzerdefinierte asynchrone Logik basierend auf Promise unterstützen, um ein Gleichgewicht zwischen Komplexität und Praktikabilität zu finden
Bisher habe ich die Methode und Schnittstelle zum Kombinieren von Vorlagen mit asynchronen, und es gibt keine Möglichkeit, dieses Thema weiter zu untersuchen

• Front-End-Template-Engine sollte verschiedene Entwicklungsmodelle unterstützen

Seit der Entwicklung des Front-Ends gibt es viele verschiedene Entwicklungsmodelle, wie zum Beispiel:

Die gebräuchlichste HTML-Seite, die Ereignisse wie DOMContentLoaded verwendet, um Logik hinzuzufügen, und teilweise Aktualisierung der Seite unter bestimmten Interaktionen

Verwendung des traditionellen MVC-Modells für die Einzelseitenentwicklung
Verwendung der MVVM-Methode zur Entwicklung mit Daten als Kern und Daten- und Ansichtsrichtungsbindung
Entwicklung basierend auf unveränderlichen Daten für Datenvergleich, Diff-Konvertierung und DOM-Aktualisierung (einschließlich der virtuellen Einführung von DOM)
Es ist eine sehr große Herausforderung für eine Vorlage Die Engine unterstützt so viele verschiedene Modi, insbesondere die Unterstützung für die Zwei-Wege-Bindung. Bisher verfügen fast alle Entwicklungsframeworks, die die bidirektionale Bindung unterstützen, über eine dedizierte Vorlagen-Engine. Dies liegt daran, dass die bidirektionale Bindung zwei Hauptanforderungen an Vorlagen stellt:

kann Durch Extrahieren der Metainformationen „Von welchen Daten diese Vorlage abhängt“ aus der Vorlage

können Sie erkennen, welcher Teil der Vorlage eine Datenänderungs-Engine ist, ohne das gesamte

• Allgemeine Template-Engines bieten diese beiden Funktionen selten, daher gibt es keine Möglichkeit, verschiedene Front-End-Entwicklungsmodelle vollständig zu unterstützen.
Aus der Implementierung der Template-Engine selbst gibt es eine Methode Es macht den AST direkt verfügbar -ähnliche Struktur nach dem Parsen der Vorlage, damit andere Frameworks sie angemessen verarbeiten können, und gleichzeitig eine teilweise Aktualisierungsfunktion für die Vorlage bereitstellt (sie kann auch zusammen mit dem oben erwähnten Vorlagenfragment betrachtet werden), aber die Leistung der meisten Vorlagen-Engines ist Ihrer Meinung nach Darüber hinaus wird keine grammatikalische Struktur ähnlich wie bei AST analysiert

• Die Front-End-Vorlagen-Engine muss eine Isolierung zwischen den Instanzen aufweisen

In großen Front-End-Projekten Insbesondere in einem Einzelseitenprojekt ist eine völlig unbekannte Anzahl von Vorlagenfragmenten gleichzeitig vorhanden. Wenn diese Fragmente Namen haben (aus Gründen der Wiederverwendung), kann es leicht zu Namenskonflikten kommen

Für Logik auf derselben Ebene (z. B. arbeitet jeder am Business-Layer-Code oder jeder arbeitet am Control-Layer-Code) können Namenskonflikte durch einige Entwicklungskonventionen gelöst werden. Aufgrund der Kapselungsanforderungen sollte die Außenseite jedoch die Namen einiger Fragmente nicht kennen, die nur intern verwendet werden. Wenn die Namen zu diesem Zeitpunkt leider mit anderen Schichten in Konflikt stehen, kann die Situation sogar noch problematischer werden Es ist nicht leicht nachzuverfolgen und führt oft zu einer großen Energie- und Zeitverschwendung

Daher sollte eine gute Template-Engine mehrere Instanzen haben und verschiedene Instanzen sollten voneinander isoliert sein, um solche Unvorhersehbarkeiten zu vermeiden

Wenn Sie sich weiter mit diesem Thema befassen, werden Sie feststellen, dass eine einfache Isolierung nicht ausreicht. Zusätzlich zur Notwendigkeit der Konfliktfreiheit zwischen verschiedenen Ebenen besteht auch die Notwendigkeit einer Wiederverwendung von Fragmenten Einige feste Fragmente können von Vorlageninstanzen gemeinsam genutzt werden, sodass die Beziehung zwischen den einzelnen Instanzen der Vorlagen-Engine eine Kombination aus Abhängigkeiten ist, jedoch mit grundlegender Kapselung und Isolation. Das ist alles.

Das obige ist der detaillierte Inhalt vonAusführliche Erläuterung der Probleme mit Front-End-Template-Engines. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!