Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby

Erste Schritte mit der Asset-Pipeline, Teil 2

by
Length:LongLanguages:
This post is part of a series called Getting Started with the Asset Pipeline.
Getting Started With the Asset Pipeline, Part 1

German (Deutsch) translation by Tatsiana Bochkareva (you can also view the original English article)

Am Ende dieses Artikels sollten Sie ein gutes Verständnis der Funktionen der Asset-Pipeline in Rails haben, mit denen Anfänger normalerweise Schwierigkeiten haben. Sie haben auch ein gutes Einführungsverständnis in Kompilierung, Fingerabdruck, Caching, Minimierung und Komprimierung. Die Pipeline bietet Ihnen viele Kilometer und ein gutes Verständnis dafür, warum dies genauso wichtig ist wie die Kenntnis der Funktionen.

Themen

  • Kettenräder?
  • Assets vorkompilieren
  • MD5 Fingerabdruck
  • Asset-Links
  • Zuhälterstile

Kettenräder?

Die Asset-Pipeline in Rails wird vom sprockets-rails gem verwaltet. Standardmäßig ist es aktiviert, wenn Sie eine neue Rails-Anwendung erstellen. Sprockets ist eine Ruby-Bibliothek und hilft Ihnen bei der Verwaltung Ihrer JavaScript- und CSS-Assets.

Darüber hinaus werden übergeordnete Sprachen wie Sass, SCSS und CoffeeScript kompiliert und vorverarbeitet. Vorverarbeitung bedeutet einfach, dass Ihre Stile, HTML oder JavaScript generiert werden, nachdem Sie Code in einer anderen Sprache geschrieben haben. Beispielsweise werden Ihre Sass-Stylesheets in gültiges CSS vorkompiliert. Da Browser Dinge wie CoffeeScript nicht verstehen können, müssen wir sie zuerst vorverarbeiten.

Dabei spielen drei Edelsteine eine entscheidende Rolle:

  • coffee-rails
  • uglifier
  • sass-rails

Mit sass-rails können Sie die Sass-Variante Ihrer Wahl für die Erstellung Ihres CSS schreiben, mit coffee-rails erhalten Sie eine bessere Syntax für das Schreiben Ihres JavaScript, und uglifier komprimiert diese Elemente. Übrigens ist sass-rails für die Komprimierung der CSS-Dateien selbst verantwortlich. Alle drei Edelsteine werden automatisch zu Ihrer Gemfile hinzugefügt, wenn Sie eine neue Rails-App erstellen. Wenn Sie einen Grund haben, Kettenräder nicht mit Schienen zu verwenden, können Sie diese über die Befehlszeile überspringen, wenn Sie Ihre App starten:

Terminal

Dieser Befehl verhindert, dass die oben genannten Edelsteine zu Ihrer Gemfile hinzugefügt werden, und gibt Ihnen eine andere Version der Datei config/application.rb. Jetzt müssen Sie Ihre eigene Lösung für den Umgang mit Ihren Assets einrichten.

Bearbeitung

Wenn Sie so etwas wie CoffeeScript in gültiges JS oder Sass in CSS vorverarbeiten, haben Sie auch die Möglichkeit, diese Dateien weiter zu verarbeiten. Minfikation und Komprimierung sind die beiden großen. Durch die Minimierung werden Dinge entfernt, die dem Browser egal sind - Leerzeichen und Kommentare sind beispielsweise gute Kandidaten. Sass kann sich auch direkt mit der Minifizierung befassen. Oder Sie verwenden einfach die Rails-Standardeinstellung des YUI-Kompressors, wenn Sie mit Stylesheets arbeiten. Abgesehen davon können Sie mit Rails sogar Ihren eigenen benutzerdefinierten Kompressor schreiben und konfigurieren.

Ich sollte erwähnen, dass Sass eine komprimierte Version der Ausgabestile hat. Dies ist tatsächlich verwirrend, da es Ihre Stylesheets minimiert. Die Komprimierung ist ein anderer Prozess und reduziert die Dateigröße erheblich. Die Komprimierung oder das Komprimieren zielt auf sich wiederholende Teile des Codes ab und ersetzt sie durch Zeiger, die weniger Platz beanspruchen. Je sich Ihre Asset-Dateien wiederholen, desto mehr werden sie komprimiert und verkleinert.

Die Minimierung ist ganz nett, aber Sie werden die größten Verringerungen der Dateigröße feststellen, wenn Sie gzipping verwenden. Es ist nicht selten, dass Dateien auf 14% ihrer ursprünglichen Größe verkleinert werden, wenn Sie sie sowohl minimieren als auch komprimieren. Wenn Sie daran denken, Tonnen von Assets über langsamere Netzwerke herunterzuladen, kann dies von großem Vorteil sein.

Assets vorkompilieren

Für die Produktion müssen Ihre Assets zuerst kompiliert werden. Dateien, die Sie in app/assets ablegen, müssen normalerweise vorverarbeitet werden, bevor sie bereitgestellt werden können. Worüber reden wir hier? Angenommen, Sie haben an einer neuen App gearbeitet, die auf Ihrem lokalen Server funktioniert. Ihre Sass-Dateien und Ihr JavaScript mit CoffeeScript-Geschmack funktionieren sofort. Cool, aber was passiert, wenn Sie dies auf einen Produktionsserver übertragen möchten? Ein solcher Server, der für die Bereitstellung dieses Inhalts für ein möglicherweise viel größeres Publikum verantwortlich ist, hat einige andere Anforderungen als Ihr lokaler Server.

Standardmäßig sucht Rails nach Dateien mit dem Namen application und versucht, diese für Sie vorkompilieren. In diesem Schritt werden Assets aus Hochsprachen wie Sass in CSS kompiliert und miteinander verknüpft - aus mehreren Dateien zu weniger Dateibündeln. So wenige Dateien wie möglich zu haben, wirkt sich positiv auf Leistung und Geschwindigkeit aus. Die Komprimierung ihrer Größe auf ein Minimum ist ebenfalls von enormer Bedeutung - insbesondere für größere Anwendungen. Darüber hinaus werden Dateien zwischengespeichert. Das bedeutet, dass Sie neue Assets nur laden, wenn sie auf Ihrer Seite geändert wurden.

Zusammenstellung

Sie haben zwei Möglichkeiten, wo Sie Ihre Assets kompilieren möchten. Sie kompilieren auf Ihrem Produktionsserver oder lokal. Lokale Kompilierung bedeutet, dass Sie diesen Prozess zuerst auf Ihrem eigenen Computer ausführen und dann in die Produktion übertragen. Dies hat den Vorteil, dass Sie auf einem Produktionsserver keinen Schreibzugriff auf das Dateisystem benötigen. Wenn Sie auf mehreren Servern bereitstellen, können Sie diesen Vorgang nur einmal ausführen. Ein weiterer Vorteil der lokalen Vorkompilierung besteht darin, dass Sie Ihre Assets auf dem Server nicht vorkompilieren müssen, wenn die bereitgestellten Änderungen keine Änderungen an den Assets enthalten.

Das Vorkompilieren von Assets ist eines dieser Dinge, die wir tun müssen, bevor wir ihnen unser "reines", kompiliertes CSS, HTML und JS senden. Server sollten wahrscheinlich nicht wissen müssen, wie sie mit Hochsprachen wie Sass, Slim und so weiter umgehen sollen. Sie haben bereits genug Verantwortung. Damit dies funktioniert, sind Sie dafür verantwortlich, dass die Komprimierungs- und Minimierungssteine auf Ihrer Maschine bereitstehen. Sie können diese kompilierten Assets in Ihr Git-Repo einfügen - oder in ein beliebiges Tool zur Versionskontrolle, das Sie bevorzugen - und nur diese endgültigen Assets für die Produktion bereitstellen.

Rails bietet Ihnen eine Rake-Aufgabe, die sich jedoch um das Vorkompilieren von Assets kümmert. Eine solche Aufgabe besteht einfach aus einer Reihe vordefinierter Schritte, die ausgeführt werden, um ein bestimmtes Ziel zu erreichen. Die Verwendung des Rake-Build-Tools für solche Dinge ist in Ruby Land sehr verbreitet. Sie können ganz einfach Ihre eigenen Aufgaben in Rake selbst schreiben. Rails macht das sehr einfach. Im Lieferumfang von Rails ist das Verzeichnis lib/tasks enthalten, in dem Sie Ihre Rake-Aufgaben bequem parken können. Keine weitere Einrichtung erforderlich. Also, wenn Sie laufen:

Terminal

Kettenräder nehmen die Assets, die sie in ihrem Suchpfad finden können, und verarbeiten sie vor oder kompilieren sie zu public/assets. Die Ausgabe sieht ungefähr so aus:

Terminal

Wenn Sie lokal kompilieren möchten, wird empfohlen, den Speicherort zu ändern, an dem Rails Ihre Assets ausgibt. Wenn Sie dies nicht tun, müssen Sie die Assets für die Entwicklung neu kompilieren, da Sie ohne sie keine lokalen Änderungen sehen würden. Die geänderte URL wird von Sprockets verwendet, um Ihre Assets im Entwicklungsmodus bereitzustellen.

config/environments/development.rb

Für die Produktion werden die kompilierten Dateien standardmäßig weiterhin in einem Verzeichnis /assets abgelegt.

Sie erhalten einzelne Assets, auch Manifestdateien wie application.js und application.css genannt. Auf diese Weise müssen Sie in Ihrem Markup nicht manuell manuell mit all Ihren Assets verknüpfen und müssen nicht mehrere Asset-Dateien anstelle einer für jede Kategorie laden.

Die lange Nummer, die angehängt ist, wird als Fingerabdruck bezeichnet. Es wird verwendet, um Dateien zu vergleichen und festzustellen, ob sich ihr Inhalt möglicherweise geändert hat, bevor sie erneut zwischengespeichert werden müssen. Was Sie auch sehen können, ist, dass Sie zwei Versionen derselben Datei erhalten. Die mit der Dateierweiterung .gz ist die komprimierte Version der Assets. gzip wird zur Komprimierung und Dekomprimierung von Dateien verwendet, um ein wenig Fett zu entfernen, das wir nicht über das Kabel gesendet haben möchten. Eine weitere Verbesserung, um die Geschwindigkeit zu erhöhen.

Wenn Sie das Gefühl haben, Ihre Assets auf einem Produktionsserver vorkompilieren zu müssen, werden mit dem folgenden Befehl die Assets direkt auf Ihren Servern erstellt. Ich füge dies jedoch nur der Vollständigkeit halber hinzu. Ich bin mir nicht sicher, ob Sie als Anfänger im Moment viel Bedarf daran haben werden.

Terminal

Manifestdateien und Richtlinien

Diese Manifestdateien wie application.css enthalten die Logik zum Importieren aller Dateien in den Suchpfad. Rails importiert diese Partials zuerst und kompiliert sie dann in eine einzige autorisierende Datei, die der Browser verwendet. Dies ist jedoch nur eine Standardeinstellung, und Sie können dies natürlich ändern.

Jede Manifestdatei verfügt über Anweisungen. Hierbei handelt es sich um Anweisungen, die festlegen, welche Dateien zum Erstellen dieser Manifestdateien erforderlich sind. Dort wird auch die Reihenfolge festgelegt, in der sie importiert werden.

Das Endergebnis enthält den gesamten Inhalt aller Dateien, auf die die Anweisungen Zugriff haben. Sprockets lädt diese Dateien, führt die erforderliche Vorverarbeitung durch und rundet das Ganze durch Komprimieren des Ergebnisses ab. Ziemlich verdammt nützlich!

Für Ihre CSS-Manifestdatei app/assets/stylesheets/application.css sieht dies folgendermaßen aus:

Das JavaScript-Äquivalent app/assets/javascripts/application.js sieht ähnlich aus:

Wie Sie diesem Beispiel entnehmen können, ist es ein Muss, zuerst jQuery zu benötigen, wenn Sie sich in Ihrem JavaScript-Code darauf verlassen.

MD5 Fingerabdruck?

Standardmäßig erstellt Rails während des Vorkompilierungsprozesses einen Fingerabdruck für jeden Dateinamen. Insbesondere erstellt Sprockets einen MD5-Hash aus dem Inhalt Ihrer Dateien. Die resultierende hexadezimale Zeichenfolge mit 32 Zeichen, auch als Digest bezeichnet, wird dann an die Dateinamen Ihrer Assets angehängt.

Das heißt, wenn sich der Inhalt Ihrer Dateien ändert, ändern sich auch Ihre Dateinamen, der MD5-Hash-Teil davon. Warum heißt es Fingerabdruck? Solche Hashes haben eine sehr hohe Wahrscheinlichkeit, eindeutig zu sein, und können daher verwendet werden, um die Eindeutigkeit einer Datei zu identifizieren - genau wie Fingerabdrücke.

Beispiel für Dateinamen

Wir sprechen nicht über eine zufällige hexadezimale Zeichenfolge. Der Inhalt von Dateien wird durch eine mathematische Funktion geleitet, die ihn in eine eindeutige Sequenz mit 32 Zeichen konvertiert. Das bedeutet, dass Sie dasselbe Hash-Ergebnis erhalten, wenn Sie die Funktion zweimal auf denselben Inhalt anwenden - oder wie oft Sie möchten.

Durch diesen cleveren Mechanismus ist es möglich, nach Änderungen zu suchen und nur Dateien zu aktualisieren, die zu einem anderen MD5-Hash führen würden. Für Caching-Zwecke ist dies golden. Wenn sich nichts geändert hat, wird es vom Webbrowser für zukünftige Anforderungen zwischengespeichert. In diesem Zusammenhang bedeutet Cache-Busting einfach, dass Remote-Clients eine neue Kopie einer Datei anfordern, da sich der Fingerabdruck geändert hat. Natürlich wird ein neuer Fingerabdruck erstellt und dem Dateinamen Ihres Assets hinzugefügt.

Ausgabe

Sie können den Fingerabdruck sowohl für die Produktion als auch für die Entwicklung deaktivieren:

config/environments/production.rb

config/environments/development.rb

Asset-Links

Vergessen wir nicht, warum es schön ist, die Asset-Pipeline zu haben. Es soll Ihnen den Umgang mit Vermögenswerten erleichtern. Das Schreiben der Stile und Verhaltensweisen für Apps ist zunehmend nuancierter und komplexer geworden. Einige der Werkzeuge sind auch erfreulicher geworden, mit ihnen zu arbeiten. Das Vorbereiten und Bereitstellen von Assets für die Produktion sollte zumindest etwas trivialer sein und Ihnen Zeit sparen.

Ein bisschen Automatisierung und Konventionen zum Organisieren von Assets sind wirklich nett, weil es Ihre eigentliche Arbeit auf dem Weg erleichtert. Die Asset Pipeline versüßt den Deal sogar und rundet die Sache mit ein paar zuckerhaltigen Assets-Links ab. Dies macht es zum Kinderspiel, mit Assets in Ihrem Code umzugehen. Schauen wir uns einige der üblichen Verdächtigen an, die Ihr Glück hoffentlich noch weiter steigern:

  • javascript_include_tag
  • stylesheet_link_tag
  • image_tag

Seit seiner Extraktion hat Sprockets die Art und Weise, wie Sie Ihre Assets verknüpfen können, nicht geändert. es funktioniert immer noch genauso wie zuvor. Bei den obigen Beispielen handelt es sich um Convenience-Methoden, bei denen der Name Ihres Assets als Argumente verwendet wird. Sie ermitteln dann selbst die Erweiterungsnamen für korrelierte Dateien. Diese Hilfsmethoden erstellen nicht nur die erforderlichen Tags für den richtigen HTML-Code, sondern sorgen auch für die Verknüpfung mit den Asset-Dateien. Sie sind natürlich nicht obligatorisch, aber immer noch schön zu haben und auch sehr gut lesbar. Es gibt ein bisschen weniger Unordnung in Ihrem Markup, wenn Sie sie verwenden.

Einige Ansicht

In Ihrer globalen Layoutdatei erhalten Sie von Rails sofort drei davon.

app/views/layouts/application.html.erb

Dies führt zu der folgenden Ausgabe im gerenderten HTML:

Schauen wir uns den Umgang mit Bildelementen genauer an.

image_tag

Auf Bilder, die sich im Verzeichnis public/assets/images befinden, kann über diese bequeme Methode zugegriffen werden - Sie müssen nicht selbst mit Pfadnamen herumspielen. Dies ist ein gutes Beispiel für "Konvention über Konfiguration" bei der Arbeit.

some.html.erb Datei

Das würde Folgendes ergeben:

Wenn aktiviert, werden Sprockets solche Dateien bereitstellen, wenn sie gefunden werden. Wenn eine Datei wie some-image.png mit einem Fingerabdruck versehen wird, wie z. B. some-image-9e107d9d372bb6826bd81d3542a419d6.png, wird sie auf die gleiche Weise behandelt.

Wenn Sie andere Verzeichnisse in public/assets/images oder in app/assets/images benötigen, um Ihre Bilder zu organisieren, möglicherweise etwas Besonderes für Symbole oder svg-Dateien, kann Rails sie problemlos finden. Sie müssen lediglich zuerst den Namen des Verzeichnisses hinzufügen:

Sehen Sie, keine Raketenwissenschaft, und die anderen Asset-Helfer werden auf die gleiche Weise behandelt.

Effiziente Stile

CSS & ERB

Die Asset-Pipeline ist so eingerichtet, dass ERB-Code von Anfang an ausgewertet wird. Alles, was Sie tun müssen, ist, die Erweiterung .erb zu einer Datei hinzuzufügen, und schon kann es losgehen - Sprockets kümmert sich um den Rest. Wenn Sie Controller generieren, werden auch Ansichten erstellt, die bereits die Erweiterung .erb haben. Gleiches gilt für Gerüste.

Dies funktioniert aber auch für Stylesheets. Sie können sie verbessern, indem Sie ERB in ihnen verwenden. Sie erstellen einfach so etwas wie example.css.erb-Dateien. Ich bin mir jedoch nicht sicher, ob es sich um eine weit verbreitete Technik handelt. Es kann sehr praktisch sein, aber ich wäre wahrscheinlich vorsichtig, wenn ich es überbeanspruchen würde, da Sie es sehr weit bringen können. Diese dynamischen CSS-Dateien sollten wahrscheinlich nicht zu viel Logik enthalten. Es fühlt sich an wie ein Codegeruch, aber der Schaden scheint eingedämmt zu sein, wenn Sie sich hauptsächlich auf ERB-Helfer verlassen.

Dieses Bild wird gefunden, wenn Sie es in einem der Ladepfade der Asset-Pipeline haben - normalerweise irgendwo unter app/assets/images. Das Coole ist, wenn diese Datei bereits verarbeitet und mit einem Fingerabdruck versehen wurde, verwendet Sprockets den Pfad public/assets und findet ihn dort. Gleiches gilt natürlich auch für andere Arten von Vermögenswerten. Vergessen Sie nicht, <%= %>, <% %> zu verwenden, um dort Ruby-Code zu interpolieren. Ohne sie geht es nicht. Während der Vorkompilierung interpoliert Sprockets den in den CSS- oder Sass-Dateien verwendeten Code und gibt einfache .css-Dateien erneut aus - natürlich mit oder ohne Fingerabdruck gemäß Ihren Einstellungen.

Im Folgenden finden Sie einige weitere Optionen, die für die Verknüpfung mit verschiedenen Asset-Kategorien nützlich sein können:

  • asset_path
  • asset_url
  • image_path
  • image_url
  • audio_path
  • audio_url
  • font_path
  • font_url
  • video_path
  • video_url

Der Unterschied zwischen diesen Geschwistern besteht darin, dass die _url-Version den vollständigen Pfad wie http://example.com/assets/application.css angibt, während die _path-Version in den relativen Pfad zu einem Asset wie /assets/application.css übersetzt wird.

Sass Asset Helfer

Wenn Sie das sass-rail gem verwenden, können Sie auch die path und url-Helfer für Ihr Vermögen verwenden. Sie sind wirklich ein Kinderspiel. So einfach ist das:

some-stylesheet.css.erb

Beachten Sie, dass diese Helfer einen Bindestrich ( - ) und keinen Unterstrich ( _ ) verwenden.

Der image-path("some-image.png") wird in "/assets/some-image.png" übersetzt. Die image-url("some-image.png") wird in die url(/assets/some-image.png) erweitert, die wiederum in die vollständige URL übersetzt wird, z. B. "http://www.example.com/assets/some-image.png". Gleiches gilt natürlich auch für den asset-path.

Interessanterweise bietet dieses Juwel auch seinen eigenen Geschmack von anderen Asset-Helfern von Rails. Das bedeutet, dass Sie keine .erb-Dateien verwenden und <%= %> Interpolationen in Ihren Stylesheets durchführen müssen. Sie verwenden einfach diese Asset-Helfer von sass-rails, was sich meiner Meinung nach etwas eleganter anfühlt. Auch weniger nach Code stinkend.

  • asset-path
  • asset-url
  • image-path
  • image-url
  • audio-path
  • audio-url
  • font-path
  • font-url
  • video-path
  • video-url

Diese Hilfsmethoden wissen genau, wo sich Ihre Assets befinden. Wenn Sie sie in das herkömmliche Verzeichnis stellen, ist der Suchpfad im Grunde genommen. Der Unterschied zwischen path und url besteht darin, dass Sie relative Pfade und einen absoluten Pfad haben. Eine kurze Erinnerung: Ein relativer Pfad ist der Pfad zu einem bestimmten Dateiziel von einem anderen Dateispeicherort. Absolute Pfade geben Ihnen den Speicherort in Bezug auf das Stammverzeichnis an.

Abschließende Gedanken

Die Asset-Pipeline wurde seit Rails 4 extrahiert und ist keine Kernfunktionalität mehr. Es ist standardmäßig aktiviert, aber Sprockets ist jetzt dafür verantwortlich. Sie können es überspringen, wenn Sie ein Projekt initiieren.

Durch die Verwendung der Pipeline wird die Verwaltung und Kompilierung von Assets zum Kinderspiel. Sie müssen nichts einrichten und können sich nur auf die Arbeit mit diesen Assets konzentrieren. Die Kirsche an der Spitze ist, dass Sie auch viele praktische Bequemlichkeitsmethoden erhalten.

Ihre Dateien für CSS, JS, CoffeeScript, Sass, Haml, Slim usw. sind an einem zentralen Ort unter app/assets übersichtlich angeordnet. Sprockets ist für die Bereitstellung von Dateien aus diesem Verzeichnis verantwortlich. Die dort enthaltenen Dateien müssen normalerweise vorverarbeitet werden, z. B. um Sass-Dateien in entsprechende CSS-Dateien umzuwandeln.

Mittlerweile kennen Sie die meisten Funktionen der Asset Pipeline, die Anfängern normalerweise schwer fallen. Wichtiger als nur die Funktionalität zu kennen, kennen Sie jetzt auch das Warum. Sie sollten ein gutes Einführungsverständnis in Kompilierung, Fingerabdruck, Caching, Minimierung und Komprimierung haben. Ich hoffe, Sie werden es zu schätzen wissen, wie viel diese Pipeline für Sie tut, um Ihr Entwicklerleben ein bisschen stressfreier zu gestalten.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.