😰 🥙 🍰 Moderne Frontend-Architekturen (Teil 2) 🕡 🚰 👸🏿

Der zweite Teil des Artikels " Zeitgenössische Front-End-Architekturen ", in dem die Architektur des Front-End im Hinblick auf die Verteilung von Datenströmen erörtert wird. Beginnen Sie hier

Implementierung

Von DOM erzeugte Algorithmen (DOM-infundierte Algorithmen)

Die Technik, die von der jQuery- Bibliothek eingeführt und beherrscht wurde , war wirklich der Beginn des Schreibens umfangreicher Clientanwendungen, obwohl jQuery tatsächlich keine Architekturprobleme löste. Es wurde entwickelt, um die Bearbeitung des DOM-Baums bei zu vielen Inkonsistenzen im Browserverhalten zu vereinfachen. Dies stellte eine browserunabhängige API bereit.

Ich glaube nicht, dass dies beabsichtigt war, aber jQuery hat die DOM-API so stark vereinfacht, dass es schwierig war, sie von den üblichen Programmiersprachen-APIs zu unterscheiden. Dies wiederum ermöglichte es Entwicklern, die DOM-API-Ebene ( Ansicht ) buchstäblich mit der Geschäftslogik ( Modell ) zu mischen .

Wir befinden uns erneut im Kontext derselben serverseitigen MVC. Dies ist nur eine Fortsetzung. Es gibt keine wirkliche Umkehrung der Kontrolle. Die allgemeine Kontrolle über Ansichten / Seiten wird weiterhin durch den serverseitigen Code bestimmt.

Im obigen Codeausschnitt sind Modell, Präsentation und Präsentator / Controller in gewisser Weise zu einer monolithischen Codestruktur zusammengefasst. Dies ist der Fall, wenn das Modell nur aus einer Eigenschaft besteht. Stellen Sie sich vor, Sie möchten eine Webanwendung ohne einen Server-Suchzyklus (wie SPA) erstellen. Es wäre unmöglich, all dies auf irgendeine bequeme Weise zu handhaben. Der Code für die Interaktion mit dem DOM wird vom Rest der Anwendungslogik durchdrungen und ist daher als DOM-infundierter Algorithmus bekannt (ich bin mir nicht sicher, ob es offiziell einen solchen Begriff gibt).

Backbone.js - MV *

Wie wir in jQuery gesehen haben, fehlt bei der Entwicklung von Anwendungen eindeutig die Möglichkeit, unseren Code zu strukturieren und zu organisieren. Hier erschien Backbone.js als nächste evolutionäre Lösung. Es war eine der ersten Bibliotheken, die die Vorteile des clientseitigen MVC-Stils nutzte.

Wenn wir uns das Backbone-Datenflussdiagramm ansehen, sehen wir das Modell und die Ansicht deutlich, aber es gibt kein Objekt, das dem Controller entspricht. Vorlagen entwickeln sich weiter, und clientseitige MVC ist einfach eine Weiterentwicklung früherer MVC-Architekturen. Während dieser Entwicklung stimmte ein Großteil der JavaScript-Community der Definition des Modells und der Ansicht zu, es bestand jedoch kein Konsens über den Controller. In Anbetracht der Client-Umgebung ist die Idee des Controllers nicht sehr geeignet. Der Controller bleibt zur Interpretation offen.

Für Backbone gibt es keinen Controller. Was ist das? Ist es MVC, MVP oder MVVM? In Anlehnung an die Definition von Server-MVC hat der Controller zwei Verantwortlichkeiten: Er reagiert auf Benutzeraktionen in Form eingehender HTTP-Anforderungen und steuert das Modell zum Erstellen der Ansicht (HTML-Seite). Im Fall von Backbone werden diese Verantwortlichkeiten zwischen View und Router geteilt . Der unabhängige Begriff Controller oder Presenter fehlt jedoch.

, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

So entsteht MV * oder Model-View-Whatever ("was auch immer"). Für eine ausführliche Diskussion wird dringend empfohlen, den Blog von Addi Osmani zu lesen.

Im Vergleich zu früheren jQuery hat Backbone dazu beigetragen, strukturierteren Code zu erstellen.

Zu Beginn dieses Artikels habe ich Backbone als die nächste evolutionäre Lösung bezeichnet. Der Grund ist, dass er einfach die serverseitige MVC erweitert hat, um sie zu ergänzen. Wenn unser Server beispielsweise RESTful ist und impliziert, dass der Front-End-Code nur ein Mittel zur Darstellung des Modells auf der Serverseite ist, ist Backbone für die Synchronisierung mit der API vorkonfiguriert:

Außerdem sind in Backbone viele andere kleine Konventionen integriert, die sich wie eine Erweiterung anfühlen. Zusammenfassend sage ich, dass Backbone zu dieser Zeit vielleicht nicht die einzige Lösung war, aber es war wirklich bahnbrechende Arbeit in Bezug auf Codestruktur und Organisation. Wie jQuery wurde es von vielen Produkten verwendet.

Knockout.js - Datenbindung für das Frontend

Knockout.js ist unser aktuelles Beispiel für die Verwendung grundlegender Vorlagen. Ziel ist die Implementierung von MVVM - Model-View-ViewModel für JavaScript. Und so ist es. Während sich Backbone mit dem Problem der Organisation und der Codestruktur befasste, ist Knockout eine effiziente Implementierung der Ansichtsebene mithilfe deklarativer Datenbindungen . Die Vorteile deklarativer Bindungen sind dieselben wie bei allen deklarativen Programmierkonstrukten:

Einfach zu lesen: deklarativer Code hilft beim Programmieren
Verkürzen der Standardvorlage: Mit Bindungen können wir das DOM jedes Mal automatisch aktualisieren, wenn sich das ViewModel ändert, und das ViewModel jedes Mal aktualisieren, wenn sich die Ansicht durch Benutzereingaben ändert.
Beobachtbar: Knockout bietet eine höhere Abstraktionsebene für Ereignisse. Dadurch kann Knockout Abhängigkeiten zwischen ViewModel-Eigenschaften automatisch verfolgen. Bei Bedarf können wir Observable-Eigenschaften abonnieren.

Knockout bietet zwar genau definierte Konstrukte für View und ViewModel, sagt jedoch nichts darüber aus, wie das Anwendungsmodell aussehen soll. Dies macht Knockout extrem fokussiert und vielseitig, da es als Bibliothek anstelle eines Frameworks verwendet werden kann. Aus eigener Erfahrung habe ich gesehen, dass damit SPA-Minianwendungen erstellt wurden, bei denen eine Webanwendung aus mehreren Seiten besteht und jede Seite eine kleine Knockout-Anwendung ist. Diese Antwort auf StackOverflow definiert den Umfang von MVVM in Knockout klar.

Es wird oft angenommen, dass sich Knockout beim Modell auf der Serverseite befindet. ViewModel fordert einfach ein serverseitiges Modell mit Ajax oder einem gleichwertigen Modell an.

Knockout ersetzt jQuery- und Vorlagenlösungen wie Lenker für DOM-Updates, verwendet jedoch weiterhin jQuery für Animationen, Ajax und andere Dienstprogramme. In Kombination mit Backbone kann es als vollständige Implementierung der MVVM-Vorlage dienen. Theoretisch könnte dies passieren, aber bevor dies passieren konnte, wurden diese Konzepte bereits in den Werkzeugen der nächsten Generation entwickelt.

Hier beginnt die revolutionäre Bewegung von Angular 1, Aurelia, Ember.js usw.

Aufgrund seiner engen Verbindung mit der .NET-Welt ist Knockout in der ASP.NET MVC-Anwendung weit verbreitet. Wie Backbone war es eine weitere evolutionäre Lösung für ein etwas anderes Problem. Auch hier hat sich die Annahme, dass clientseitiger Code lediglich eine Erweiterung des serverseitigen MVC-Musters ist, nicht geändert. Die Serverseite war immer noch die dominierende Architektur.

Sowohl Knockout als auch Backbone sind JavaScript-Bibliotheken. Auf die eine oder andere Weise wurde Backbone als Framework angesehen. Warum? Es gibt keine eindeutige Antwort, aber es war wahrscheinlich in der Perspektive. Backbone wurde aufgrund seiner Betonung der Codestruktur immer mit einer höheren Abstraktion behandelt. Darüber hinaus sollte Backbone niemals die allgegenwärtige jQuery ersetzen (selbst im Jahr 2019 verwenden 70% der Top-10.000.000 Websites jQuery), während sich Knockout mit dem jQuery-Kern überlappte, d. H. DOM-Manipulationen, die Knockout natürlich komplizierten. Daher war die Anpassung von Knockout im Vergleich zu Backbone begrenzt. Es war jedoch immer noch eine der ersten Implementierungen deklarativer Datenbindungen für die Front-End-Community und verdient besondere Erwähnung.

Winkel 1 - gib mir die Kontrolle

Was jQuery mit dem DOM gemacht hat, hat Angular 1 mit dem Front-End-Ökosystem als Ganzes gemacht. Dies veränderte für immer die Idee, umfangreiche Clientanwendungen zu erstellen. Er präsentierte viele Konzepte als Grundlage - ein modulares System, Abhängigkeitsinjektion, Steuerungsinversion, einfachere Datenbindung usw.

Es war und ist eine schwierige Aufgabe, die richtigen JavaScript-Bibliotheken auszuwählen und den perfekten Technologie-Stack für das Frontend zu erstellen. Winkel 1 bot einfach eine einfachere, aber zusammenhängendere Alternative. Das Gleiche gilt für Ember.js und andere ähnliche Systeme, aber die Anwendbarkeit von Angular 1 war auf einer anderen qualitativen Ebene als die seiner damaligen Alternativen.

Angular 1 ist eine revolutionäre Lösung in dem Sinne, dass es eindeutig eine Abkehr von der Idee einer einfachen serverseitigen MVC-Erweiterung mit clientseitigem Code darstellt, der über mehrere Seiten verteilt ist. Angular 1 hat SPA zu einer erstklassigen, fast de facto Lösung für die Schaffung einer Benutzererfahrung der nächsten Generation gemacht.

Framework oder Bibliothek?

Frühere Lösungen waren mehr Bibliotheken als ein Framework. Winkel 1 ist ohne Zweifel eine genau definierte Struktur. Ein notwendiger Unterscheidungsfaktor zwischen der Plattform und der Bibliothek ist IOC - Inversion of Control. Um Angular 1 als Framework zu qualifizieren, können wir Folgendes beachten:

Gut definierte MVVMs: Angular 1 verfügt über eindeutige Model-, View- und ViewModel-Objekte.
(DI): Angular 1 DI, Model. Angular 1 (Service). , .
(data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
Modulares System: Angular 1 führt ein modulares System ein, das für das Framework spezifisch ist. Module sind die Basis für die Organisation von Code für fast jede Sprache. JavaScript hatte bis 2015 kein modulares System (Browser unterstützten es erst 2018). Angular ist seiner Zeit in Bezug auf die Organisation weit voraus.

Gleichzeitig wurde Angular 1 auch für die damit verbundene Komplexität kritisiert. Der wichtigste Kritikpunkt ist, dass es sich um serverseitige Designs handelt. Dies ist nicht typisch für Frontend-Entwickler. Einige Dinge waren ehrlich gesagt schlecht:

Namespace-Kollision: Obwohl DI großartig war, wurde es mithilfe des Service Locator-Musters implementiert, das den globalen Namespace verwendete. Dies machte das Präfix der Dienste fast obligatorisch.
. , , , . React . -, .
. , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

Es gab viele andere kleinere Probleme. Angular 2 oder einfach Angular war insofern ein vollständiger Durchbruch, als es wie ein völlig neues Framework aussah. Ich finde nichts gemeinsam zwischen ihnen, außer dem Namen und einigen Konzepten.

Im Laufe der Jahre gab es kleine Versionen von Angular 1, in denen viele der kleinen Komplexitäten seiner Verwendung behoben wurden. Das wichtigste davon war die Hinzufügung des Komponentenmodells , in dem die meisten Front-End-Entwicklungstrends konvergierten.

Angular 1 lebte lange und lebt weiterhin in der Front-End-Community. Mit all seinen Vor- und Nachteilen half es der Community, die Bedeutung der Softwarearchitektur zu verstehen, und lieferte die Grundlage für das Schreiben skalierbarer Anwendungen. Seine Nachteile und Mängel wurden zur Grundlage für die Lösung von Problemen für zukünftige Architekturen.