Vorwort
Bei der Trennung von Front- und Rücken endet das erste Problem, auf das ich achten, dass es sich um das Rendern handelt, dh auf der Sichtweise.
Im traditionellen Entwicklungsmodell werden Browser und Server von zwei Teams vorne und hinten entwickelt, aber die Vorlage befindet sich im vagen Bereich zwischen den beiden. Daher gibt es immer immer komplexere Logiken in der Vorlage, die letztendlich schwer zu pflegen sind.
Und wir haben NodeJs als mittlere Schicht der Vorder- und Rückseite ausgewählt. Versuchen Sie, NodeJs zu verwenden, um die Arbeit auf der Sichtebene zu beseitigen.
Dies macht die Arbeitsteilung zwischen Vorder- und Rückseite klarer, macht das Projekt besser gepflegt und erreicht eine bessere Benutzererfahrung.
Dieser Artikel
Die Rendering-Arbeit ist ein sehr großer Teil der täglichen Arbeit von Front-End-Entwicklern, und es ist auch der einfachste Teil, mit Back-End-Entwicklung verwechselt zu werden.
Rückblickend auf die letzten Jahre der Entwicklung der Front-End-Technologie hat die Arbeit auf der Sichtweise viele Änderungen erfahren, wie z. B.:
Formular Senden Sie vollständige Seite aktualisieren => Ajax Lokale Aktualisierung
Serverseitige Fortsetzung + MVC => clientseitiges Rendering + MVC
Traditionelle Seitenänderung Jump => Einzelseitenanwendung
Es kann beobachtet werden, dass in den letzten Jahren jeder dazu tendiert, dieses Ding vom Serverende zum Browser -Ende zu bewegen.
Die Serverseite konzentriert sich auf den Dienst und bietet Datenschnittstellen.
Vorteile des Browser -Renderings
Wir alle kennen die Vorteile der Browser-Seite-Rendering wie
1. Entfernen Sie die Kopplung und Verwirrung zwischen Geschäftslogik und Präsentationslogik in der Java -Vorlage -Engine.
2. Für Multi-terminale Anwendungen ist es einfacher zu interfegen. Kombinieren Sie verschiedene Vorlagen auf der Browserseite, um verschiedene Anwendungen zu präsentieren.
3. Die Seitenwiedergabe ist nicht nur HTML, sondern das Rendering am vorderen Ende kann leicht Funktionen in komponentierter Form (HTML + JS + CSS) liefern, sodass Front-End-Komponenten nicht auf die vom Server generierte HTML-Struktur angewiesen sind.
V.
5. Bequeme Gelenkanpassung.
Die durch Browser -Rendering verursachten Nachteile
Aber während wir die Vorteile genießen, stehen wir auch den Nachteilen des Browser-Side-Renderings gegenüber:
1. Die Vorlage ist in verschiedenen Bibliotheken getrennt. Einige Vorlagen werden auf der Serverseite (Java) platziert, während andere auf der Browser -Seite (JS) platziert werden. Die Sprachen vorne und Back-End-Vorlagen sind nicht verbunden.
2. Sie müssen warten, bis alle Vorlagen und Komponenten auf den Browser geladen werden, bevor das Rendering beginnen kann, und Sie können ihn nicht sofort lesen.
3.. Es wird ein weißer Bildschirm zum ersten Mal auf das Rendern warten, was für die Benutzererfahrung nicht förderlich ist
4. Bei der Entwicklung einer einseitigen Anwendung stimmt die Front-End-Route nicht mit der serverseitigen Route überein, die sehr problematisch zu handhaben ist.
5. Alle wichtigen Inhalte sind am vorderen Ende zusammengestellt, was SEO nicht förderlich ist
Denken Sie über die Definition von Vorder- und Rücksenden nach
Wenn wir die Rendering -Arbeiten von der Serverseite (Java) zur Browser -Seite (JS) nehmen, ist es unser Ziel nur, die Verantwortlichkeiten vor dem Vorder- und Rückend klar zu teilen, und es ist nicht erforderlich, den Browser zu rendern.
Nur weil im traditionellen Entwicklungsmodell der Server veröffentlicht wird und der Browser erreicht ist, sodass der Arbeitsinhalt auf dem Front-End nur auf die Browser-Seite beschränkt sein kann.
Daher haben viele Leute festgestellt, dass die Backend = Server Frontend = Browserseite genau wie das Bild unten.
Im Midway Midway -Projekt, das derzeit von Taobao UED stattfindet, versuchen wir, eine Mittelschicht in der Mitte des Java -Browsers zu erstellen, die die Vorder- und Rück- und hintere Abteilungslinie erneut für Arbeitsaufgaben und nicht für Hardware -Umgebungen (Server & Browser) differenzieren.
Daher haben wir die Möglichkeit, Vorlagen und Routen auszutauschen, was auch der idealste Zustand in Front-End- und Back-End-Arbeitsaufteilung ist.
Taobao auf halbem Weg
Im Midway -Projekt haben wir die Linie bewegt, die die Vorder- und Rückseite vom Browser auf die Serverseite abgrenzt.
Mit einer NodeJS-Schicht, die leicht vom Front-End und dem Browser gemeinsam gesteuert wird, kann die Front-End-Trennung deutlicher abgeschlossen werden.
Es ist auch möglich, die Front-End-Entwicklung die am besten geeignete Lösung für verschiedene Situationen zu bestimmen. Anstatt dass alles auf der Browserseite gehandhabt wird.
Verantwortlichkeiten dividieren
Midway ist kein Projekt, das das Front-End versucht, den Back-End-Job zu erfassen. Ziel ist es, den vagen Bereich der Vorlage klar zu schneiden und eine klarere Aufteilung der Verantwortlichkeiten zu erhalten.
Backend (Java), der sich darauf konzentriert
1. Serviceschicht
2. Datenformat und Datenstabilität
3. Geschäftslogik
Front-End, konzentrieren Sie sich auf
1.Ui Schicht
2. Kontrolllogik, Logik rendern
3. Interaktion, Benutzererfahrung
Und halten Sie sich nicht mehr an die Unterschiede zwischen Server oder Browserseite.
Vorlagefreigabe
Im traditionellen Entwicklungsmodell werden Browser und Server von zwei Teams vorne und hinten entwickelt, aber die Vorlage befindet sich im vagen Bereich zwischen den beiden. Daher gibt es immer immer komplexere Logiken in der Vorlage, die letztendlich schwer zu pflegen sind.
Mit NodeJS können sich Backend -Studenten auf die Entwicklung von Geschäftslogik und Daten in der Java -Schicht konzentrieren. Front-End-Schüler konzentrieren sich auf die Entwicklung der Kontrolllogik und des Renders. Und Sie können diese Vorlagen selbst auswählen, um auf der Serverseite (NodeJS) oder der Browser -Seite zu rendern.
Verwenden Sie dieselbe Template Language Xtemplate und dieselbe Rendering Engine JavaScript
Rendern Sie dasselbe Ergebnis in unterschiedlichen Rendering-Umgebungen (serverseitig, PC-Browser, mobiler Browser, Webansicht usw.).
Routing Sharing
Auch wegen der NodeJS -Ebene können Sie das Routing sorgfältiger steuern.
Wenn Sie das Browser-Side-Routing im Front-End durchführen müssen, können Sie das serverseitige Routing gleichzeitig konfigurieren, damit sie die Seiten auf der Browser-Seite oder auf den Seiten auf der serverseitigen Änderung ändern und einen konsistenten Rendering-Effekt erzielen können.
Gleichzeitig wurde auch das SEO -Problem behandelt.
Die Praxis der Temperaturfreigabe
Normalerweise ist der Prozess nichts anderes als, wenn wir eine Vorlage im Browser rendern
Geben Sie die Template -Engine in den Browser ein (XTMpleat, Saftbär, usw.)
Laden Sie Schablonenarchive auf der Browserseite, die Methode kann sein
Drucken Sie auf der Seite mit <script type = "js/tpl"> ... </script>
Verwenden Sie das Modul -Ladewerkzeug, um Vorlagenarchive zu laden (Kissy, RefordeJs usw.)
andere
Erhalten Sie Daten und verwenden Sie die Template -Engine, um HTML zu generieren
Fügen Sie HTML in den angegebenen Ort ein.
Der obige Vorgang ist zu erkennen, dass, wenn Sie die gemeinsame Nutzung von Vorlagen mit dem Ende der Vorlagen erreichen möchten, der Fokus tatsächlich auf einer konsistenten Modulauswahl liegt.
Es gibt viele beliebte Modulstandards auf dem Markt, wie KMD, AMD und CommonJs. Solange das Archiv des NodeJS -Template -Archivs in die NodeJS -Spezifikationen über konsistente Modulspezifikationen ausgegeben werden kann, kann eine grundlegende Templatfreigabe erfolgen.
In der nachfolgenden Artikelreihe werden die Proxy und das Teilen des Modells weiter erörtert.
Falldiskussion
Aufgrund der Zwischenschicht von Midway Island gibt es bessere Antworten auf einige frühere Fragen, wie z.
Fall 1 komplexe interaktive Anwendungen (z. B. Einkaufswagen, Bestellseite)
Status: Alle HTML werden am vorderen Ende gerendert und der Server bietet nur Schnittstellen.
Problem: Beim Eingeben der Seite gibt es einen kurzen weißen Bildschirm.
Antwort:
Geben Sie die Seite zum ersten Mal ein, rendern Sie die vollständige Seite auf der NodeJS -Seite und laden Sie verwandte Vorlagen im Hintergrund herunter.
Nachfolgende Wechselwirkungen, vollständige teilweise Aktualisierung auf der Browserseite
Die Verwendung derselben Vorlage erzeugt das gleiche Ergebnis
Fall 2 Einzelseiten -Anwendung
Status: Verwenden Sie das Client -MVC -Framework, um die Seiten im Browser zu ändern.
Problem: Rendering und Seitenersatz werden beide auf der Browserseite abgeschlossen. Wenn Sie die URL direkt in den F5 eingeben oder aktualisieren, kann der gleiche Inhalt nicht direkt angezeigt werden.
Antwort:
Teilen Sie dieselben Routeneinstellungen auf der Seite Browser und NodeJS
Wenn Sie Seiten auf der Browser -Seite ändern, ändern Sie die Route und rendern Sie den Seiteninhalt auf der Browser -Seite.
Verwenden Sie bei direkter Eingabe derselben URL das Rendieren des Seitenrahmens + Seiteninhalts auf der NodeJS -Seite
Unabhängig davon, ob Sie die Seiten im Browser ändern oder direkt dieselbe URL eingeben, ist der von Ihnen angezeigte Inhalt dieselbe.
Neben zunehmender Erfahrung und Reduzierung der logischen Komplexität. Es löste auch das SEO -Problem
Fall drei reine Browserseite
Status: Die Seite enthält nur Informationen, weniger oder keine Interaktion
Problem: HTML wird auf der Serverseite generiert, CSS und JS werden an einem anderen Ort platziert und haben Abhängigkeiten zwischeneinander.
Antwort:
Durch NodeJS, einheitliches Management von HTML + CSS + JS
Wenn Sie in Zukunft in komplexe Anwendungen oder einseitige Anwendungen ausdehnen müssen, können Sie sie auch problemlos übertragen.
Fall 4-Cross-Terminalseite
Status: Die gleiche Anwendung muss unterschiedliche Schnittstellen und Interaktionen an verschiedenen Endpunkten darstellen
Problem: Das HTML -Management ist nicht einfach, und auf der Serverseite werden häufig unterschiedliche HTML generiert, und auf der Browser -Seite wird eine andere Verarbeitung durchgeführt.
Antwort:
Cross-terminale Seiten machen Probleme und werden vom Front-End behandelt.
Durch die NodeJS -Ebene und den Backend -Service können die besten Lösungen für diese Art von komplexen Anwendungen ausgelegt werden.
Zusammenfassen
Die Entstehung von Technologien wie Ajax, clientseitigem MVC, Spa und Zwei-Wege-Datenbindung in der Vergangenheit waren alle Versuche, die zu diesem Zeitpunkt in der Front-End-Entwicklung aufgetretenen Engpässe zu lösen.
Das Auftreten der NodeJS-Zwischenschicht ist auch ein Versuch, eine Einschränkung zu lösen, dass das Front-End derzeit auf den Browser beschränkt ist.
Dieser Artikel konzentriert sich auf das Teilen von Front-End- und Back-End-Vorlagen und hofft, Aufmerksamkeit zu erregen. Lassen Sie uns mit Ihnen besprechen, wie Sie unseren Workflow verbessern und mit dem Back-End zusammenarbeiten können, um im Front-End unter der Mittelschichtarchitektur der NodeJS einen besseren Job zu machen.