Neues Jahr, neue Schienen

Der Beginn eines neuen Jahres wird oft als Zeit für eine Neuerfindung des self. Man schließt eine Mitgliedschaft im Fitnessstudio ab, ernährt sich gesünder, lernt eine neue Sprache und so weiter. Ich war noch nie ein Fan von Vorsätzen nach dem Motto "Neues Jahr, neues Du", aber nach den ersten Eindrücken bin ich sicherlich ein Fan von "Neues Jahr, neues Rails".

Okay, der Teil mit dem "neuen Jahr" ist nicht ganz korrekt; Rails 7.0 wurde Ende des letzten Jahres, am 15. Dezember, veröffentlicht. Wir hatten bereits eine 7.0.1 Patch-Update, um Ruby 3.1 zu unterstützen. Der Teil mit dem "neuen Rails" ist allerdings zutreffend. Ein großes Versions-Update bringt immer ein Gefühl von Neuheit mit sich, aber Rails 7.0 geht darüber hinaus. Es fühlt sich an wie eine kühne und aufregende Abkehr von früheren Versionen.

In den Anfangsjahren von Rails wurde die Verwendung von Konventionen anstelle von Konfigurationen und die Vorgabe von Werkzeugen und Komponenten als etwas umstritten angesehen. Diese Grundprinzipien des Rails-Ansatzes, die schließlich Teil der Die Rails-Doktrinbildeten, waren es auch, die viele Entwickler zu diesem Framework hinzogen. Natürlich musste man sich mit den Standardeinstellungen vertraut machen und die Konventionen lernen, aber sobald man das getan hatte, war es einfach ein Vergnügen, mit Rails zu arbeiten. Dieser Gesamtansatz unterstützte die erste Säule der Rails-Doktrin: Optimiere für die Zufriedenheit der Programmierer.

Eine der Stärken von Rails als Framework ist seine Fähigkeit, sich mit der sich ständig verändernden technischen Landschaft weiterzuentwickeln. In den letzten Jahren hat sich ein Großteil dieser Veränderungen im Frontend vollzogen, wo der Wunsch nach reaktiven Schnittstellen zum Aufkommen von Single Page Applications (SPAs) und der damit verbundenen Verlagerung der Anwendungslogik weg vom Server und hin zum Client führte. Eine der Auswirkungen dieser Verlagerung war die Erhöhung der Komplexität des Front-End-Entwicklungsprozesses in Bezug auf die Verwaltung von Abhängigkeiten, die Transpilierung, die Bündelung von Assets und so weiter. Seit Rails 5.2 ist die Antwort auf diese Komplexität des Frontends der Webpacker.

Entfacht Webpacker Freude?

Obwohl Webpacker einen Teil der Komplexität der Verwaltung von Frontend-Abhängigkeiten und -Konfigurationen abstrahierte, erschien es immer als eine Art Workaround, wenn auch als eine notwendige Lösung. Es war eher eine Möglichkeit, eine Rails-Anwendung in das bestehende Frontend-Ökosystem einzubinden, als eine integrierte Frontend-Lösung. Großartig, wenn alles funktioniert, aber Sie könnten immer noch mit einigen komplexen Node-Paket-Abhängigkeitsprobleme oder Debugging verschiedene Kompilierungsfehler zu behandeln - wahrscheinlich nicht die Art von Dingen, die die meisten Rails-Entwickler wollen zu viel Zeit damit verbringen.

Es sieht so aus, als hätte das Rails-Team den Marie Kondo-Ansatz für den Webpacker gewählt, denn in Rails 7 ist er verschwunden. Die Gedanken hinter diesem Schritt basiert auf den jüngsten Fortschritten in der breiteren Web- und Internetumgebung, nämlich der nun universellen Browserunterstützung für ES6 in Kombination mit der weit verbreiteten Annahme von HTTP/2. Ersteres macht die Transpilierung von ES6-Code auf ES5 überflüssig, und die Multiplexing-Fähigkeiten von HTTP/2 verringern die Latenz, die durch das Anfordern mehrerer kleiner Dateien anstelle eines großen gebündelten "Pakets" entsteht.

Vielleicht denken Sie jetzt: "Aber ich brauche noch alle meine Node-Pakete, wie bekomme ich sie?". Die Antwort auf diese Frage lautet Karten importierenin Kombination mit CDNs, die ES-Module bereitstellen können, wie Skypack oder JSPM. Diese Kombination macht Build-Tools überflüssig und macht es sogar überflüssig, Node lokal zu installieren. Das importmap-rails gem, das standardmäßig in Rails 7 enthalten ist, bildet im Wesentlichen "bloße Modulspezifizierer" auf eine Quelle zum Laden dieses Moduls ab. Sie richten die Konfiguration für Ihre importmap in einer config/importmap.rb Datei ein. Die spezifischen Module werden zur Laufzeit angefordert, wenn sie von bestimmten Layouts benötigt werden, und zwar über ein <script> Tag des Typs "importmap" in der Datei <head> des jeweiligen Layouts. Ziemlich genial!

Dieser Ansatz wird nicht für jeden funktionieren. Einige Entwickler werden React mit JSX oder Typescript verwenden wollen und benötigen daher weiterhin einen Kompilierungs-/Transpilierungsschritt und die Möglichkeit, sich in das Node-Ökosystem einzuklinken. Nun, das kann man in Rails 7 immer noch tun. Das jsbundling-rails gem können Sie esbuild, rollup.js oder Webpack verwenden, um Ihr JavaScript zu bündeln und es dann über die Asset-Pipeline in Rails auszuliefern.

Obwohl einige Entwickler immer noch diese Art von geteiltem Front-End/Back-End-Ansatz verwenden wollen, ist die Botschaft von Rails 7, dass man für die meisten Anwendungsfälle nicht unbedingt ein schwergewichtiges Front-End-Framework oder viel benutzerdefiniertes JavaScript auf dem Front-End benötigt, um eine reaktive Benutzererfahrung im Browser zu bieten. Sie können diese Erfahrung mit einer viel einheitlicheren Anwendungsarchitektur bieten, indem Sie Hotwire.

Hotwire ist Rails-y

Hotwire ist nicht völlig neu - es konnte in Rails 6 mit einigen Einstellungen verwendet werden - aber es ist jetzt der Standardansatz in Rails 7. Hotwire, entwickelt von den Teams von Basecamp und Hey, besteht aus drei Bibliotheken: Turbo, Stimulus, und die noch nicht veröffentlichte Strada.

Turbo

Turbo übernimmt den größten Teil der schweren Arbeit. Es verwendet Server-Side Rendering (SSR), um HTML anstelle von JSON über die Leitung zu senden, wodurch die Anforderungen an das Front-End für Rendering, Statusverwaltung usw. entfallen. Turbo kombiniert mehrere sich ergänzende Konzepte und Techniken.

• Antrieb: Fängt Link-Klicks und Formular-Eingaben ab, stellt eine fetch Anfrage für den neuen Inhalt und rendert die HTML-Antwort.

• Frames: Ermöglicht es Ihnen, eine Ansicht in einzelne Teile oder Komponenten aufzuteilen, so dass beim Klicken auf einen Link oder bei der Eingabe eines Formulars nur bestimmte Teile der Webseite aktualisiert werden, anstatt die gesamte Seite neu zu laden.

• Streams: Liefert partielle Seitenaktualisierungen als Reaktion auf asynchrone Aktionen, die über WebSocket oder ein vom Server gesendetes Ereignis gesendet werden.

Das mag alles nach ziemlich standardmäßigen SPA-Funktionen klingen. Der entscheidende Unterschied zu Turbo ist, dass die Logik für all diese Front-End-Reaktionsfähigkeit nicht in ein separates Framework aufgeteilt wird, das an die Vorderseite Ihrer Rails-Anwendung geschraubt wird. Stattdessen befindet sie sich direkt in Ihren Rails-Modellen, -Ansichten und -Controllern und verwendet klare, logische und elegante Konventionen.

Dieser Artikel ist nicht als Tutorial gedacht, daher werde ich hier nicht auf die Details dieser Konventionen eingehen, aber schauen Sie sich unbedingt das Turbo Handbuch und Entwickler-Referenzsowie die README Seite für die Rails-Implementierung von Turbo, turbo-rails.

Stimulus

Stimulus bezeichnet sich selbst als "JavaScript-Framework mit bescheidenen Ambitionen" und ist als Ergänzung zu Turbo gedacht. Es stützt sich stark auf HTML-Datenattribute und verwendet JavaScript-Objekte namens Steuerungen um auf Browser-Ereignisse zu reagieren, die von Elementen mit einem passenden data-controller Attribut ausgelöst werden, oder spezifische Aktionen auf DOM-Ereignisse mit data-action Attribute. Auch hier werde ich nicht auf die Einzelheiten eingehen, aber Sie können mehr im Stimulus Handbuch, Entwickler-Referenzund der README Seite für die Rails-Implementierung von Stimulus stimulus-rails.

Hotwire ist so konzipiert, dass es nicht auf ein bestimmtes Framework angewiesen ist. In einem Rails-Kontext macht es jedoch sehr viel Sinn, insbesondere angesichts der Art und Weise, wie die Rails-Implementierungen der Bibliotheken mit ActiveRecord. Zum Beispiel können Sie einen broadcasts_to Helfer in Ihren Modellen verwenden, um verschiedene Callbacks einzurichten, die an einen bestimmten benannten Kanal veröffentlichen, sagen wir :todo_listveröffentlicht werden, wenn Datenänderungen im Kontext dieses Modells vorgenommen werden (d.h. durch Erstellungs-, Aktualisierungs- oder Zerstörungsaktionen).

class Todo < ApplicationRecord
  broadcasts_to :todo_list
end

Sie können dann Turbo-Stream-Elemente einrichten, um die Übertragung zu abonnieren. :todo_list Übertragung abonnieren. Diese Elemente werden entsprechend aktualisiert, wenn Datenänderungen auftreten. Jeder, der eine Seite anschaut, die ein Stream-Element enthält, das diese bestimmte Übertragung abonniert hat, sieht, wie sein Browser dieses Element der Seite in Echtzeit aktualisiert.

Diese Funktionalität verwendet ActionCabledie seit langem ein Bestandteil von Rails ist, im Hintergrund. Was turbo-rails verdrahtet alles auf eine logische und zugängliche Weise miteinander.

Die große Sache für mich über Hotwire ist, dass es fühlt sich Rails-y. Es abstrahiert eine Menge von Front-End-Komplexität über einen innovativen Ansatz und einige solide Konventionen weg. Das war schon immer die Art und Weise Rails, und seine Integration in Rails 7 scheint, wie es viel enger an der Rails-Doktrin als der Webpacker Kompromiss jemals könnte.

Andere Highlights

Obwohl die auffälligste Änderung in Rails 7 der neue Standardansatz für die Arbeit mit dem Frontend ist, gibt es auch einige bemerkenswerte Änderungen in Bezug auf das Backend. Die interessantesten davon betreffen verschiedene Aspekte der Arbeit mit Daten.

• Active Record Encryption bietet eine zusätzliche Sicherheitsebene durch Hinzufügen von verschlüsselte Attribute zu ActiveRecord.

• Paralleles Abfrageladen bietet Leistungsverbesserungen für Situationen, in denen Ihre Controller-Aktionen mehrere unverbundene Abfragen gleichzeitig laden müssen.

Ich persönlich bin begeistert von Rails 7 und freue mich darauf, dieses Jahr einige coole Dinge mit Rails 7 und den Vonage APIs zu entwickeln. Ich würde gerne hören, was Sie über Rails 7 denken! Lass es mich wissen auf Twitter.