Alles, was Sie über die Rails Asset Pipeline wissen sollten

Was ist die Asset Pipeline?

Wenn Sie eine Rails-Anwendung erstellen, haben Sie wahrscheinlich von der Asset-Pipeline gehört. Die Asset-Pipeline kann als die Werkzeuge und Mechanismen betrachtet werden, mit denen Javascript-Dateien, Stylesheets und Bilder verarbeitet und für die Verwendung durch den Browser vorbereitet werden. Diese Prozesse können Assets minimieren und komprimieren sowie Assets vorverarbeiten, die in anderen Sprachen wie Coffeescript oder Sass geschrieben sind.

Die Asset-Pipeline wurde erstellt, um eine Vielzahl von Problemen im Zusammenhang mit statischen Assets zu lösen. Ein solches Problem besteht darin, dass jedes im HTML-Markup separat angegebene Asset separat abgerufen werden muss, was zu einer höheren Anzahl von HTTP-Anforderungen und letztendlich zu einer längeren Ladezeit führt. Rohe Javascript- und CSS-Dateien können auch viel Bandbreite mit Kommentaren, zusätzlichem Leerraum und langen Variablennamen verschwenden. Ein weiteres Problem, das auftaucht, betrifft das Caching. Wenn Sie beispielsweise eine Javascript-Datei von Ihrem Server bereitstellen, speichert der Browser diese Datei automatisch für einen bestimmten Zeitraum zwischen. Das verbessert die Ladezeit der Seite, aber was ist, wenn sich dieses Asset zu einem späteren Zeitpunkt ändert? Der Browser weiß nichts davon und verwendet das zwischengespeicherte Asset weiterhin, bis die Cache-Lebensdauer abgelaufen ist. Schließlich haben Sprachen wie Coffeescript, Sass, Less und Erb es einfacher gemacht, Javascript und CSS zu organisieren und zu schreiben, aber der Browser kann sie nicht direkt interpretieren, so dass ein Vorprozessor benötigt wird, um diese Dateien in ihre entsprechenden Gegenstücke zu konvertieren, bevor sie an den Browser gesendet werden.

Die Asset-Pipeline kann in ihrem Wohlwollen alle oben genannten Probleme lösen, wenn sie ordnungsgemäß verwendet wird. Es kann mehrere Assets zu einem kompilieren, Assets minimieren und komprimieren, Assets verdauen, um Caching-Probleme zu vermeiden, und alternative Sprachen vorverarbeiten und in Javascript und CSS umwandeln.

Dieser Beitrag behandelt eine Vielzahl von Themen im Zusammenhang mit der Asset-Pipeline:

• die Grundlagen der Verwendung der Asset-Pipeline
• Best Practices für die Strukturierung, wo Sie Ihre Assets ablegen können
• Verwendung des Precompile-Arrays zum Angeben, welche Dateien von der Asset-Pipeline verarbeitet werden
• Wie Sass und Coffeescript genutzt werden können
• Verwendung von Rails Asset Helper methods und
• Einige Fallstricke

Grundlegende Verwendung

Die Asset-Pipeline wird auf zwei grundlegende Arten verwendet:

1. Wenn Sie einen Server im Entwicklungsmodus ausführen, werden Ihre Assets automatisch im laufenden Betrieb vorverarbeitet und vorbereitet.
2. Im Produktionsmodus werden Sie es wahrscheinlich verwenden, um Ihre Assets vorzuverarbeiten, zu versionieren, zu komprimieren und zu kompilieren. Sie können dies tun, indem Sie den folgenden Befehl ausführen:

1

bundle exec rake assets:precompile

Dadurch wird (standardmäßig) ein assets -Verzeichnis in Ihrem public/ -Ordner erstellt. Anschließend werden alle komprimierten und kompilierten Dateien in den entsprechenden Formaten und mit den neuen kompilierten Versionen in dieses Verzeichnis eingefügt. Sie können dann Nginx oder Apache einrichten, um diese Dateien direkt zu bearbeiten, damit Rails sie nicht liefern muss (und die On-the-Fly-Vorverarbeitung usw. ausführen muss.) selbst.

Denken Sie daran, dass Standardwerte geändert werden können. Wenn die Dinge nicht wie erwartet funktionieren, überprüfen Sie Ihre Anwendungskonfigurationsdatei in config/application.rb. In Rails 4 wird die Asset-Handhabung normalerweise in config/initializers/assets.rb konfiguriert.

Dateistruktur

Es ist wichtig, Ihre Assets so zu organisieren, dass Sie für Sie verständlich sind und die vorhandene Funktionalität der Asset-Pipeline erleichtern. Das erste, was Sie wissen sollten, ist, dass alle Ihre benutzerdefinierten Javascript, Stylesheets und Bilder in das Verzeichnis app/assets/ gehen sollten. Standardmäßig gibt es jeweils einen Ordner für javascripts, stylesheets und images. Sie können auch fonts, audios und videos zum Verzeichnis app/assets/ für diese Asset-Typen hinzufügen. Der gesamte Code von Drittanbietern, den Sie verwenden (z. B. jQuery, Backbone.js, etc.) sollte im Verzeichnis vendor/assets/ abgelegt werden:

1234567891011

rails-app/ app/ assets/ images/ # Image assets javascripts/ # Custom Javascript/coffeescript stylesheets/ # Custom CSS/Sass ... vendor/ assets/ javascripts/ # Javascript libraries, etc. stylesheets/ # Vendor themes, javascript library themes, etc.

Da Ihr Webserver automatisch statische Dateien aus dem Verzeichnis public/ speichert, warum sollten nicht alle Javascript-, Bild- und Stylesheet-Assets dort abgelegt werden? Zum einen wird nichts im Ordner public automatisch vorverarbeitet, kompiliert oder komprimiert, sodass Sie durch das Ablegen von Assets die Asset-Pipeline vollständig umgehen und alle Vorteile verlieren. Wenn Sie Assets dort ablegen, verlieren Sie auch die Möglichkeit, sie einfach in Ihrem Rails-Code zu referenzieren. Sie könnten beispielsweise eine Ansicht haben, die den folgenden Code enthält:

12345678910

# app/assets/images/logo.png= image_tag('logo')# Outputs something like <img src="/assets/logo-.png" /># public/images/logo.png= image_tag('/images/logo.png')# Outputs something like# <img src="/images/logo.png" />

Im zweiten Szenario (public/images/logo.png) funktioniert die Site nur, wenn sie aus dem Basisverzeichnis geliefert wird. Es kann auch nicht die Versionierung der Datei durch die Asset-Pipeline nutzen.

Vorkompilierung

Möglicherweise fragen Sie sich jetzt, ob alles, was Sie in den Ordner app/assets/javascripts/ einfügen, automatisch für Ihre App vorkompiliert wird. Glücklicherweise bietet die Asset-Pipeline eine Möglichkeit anzugeben, welche Dateien in welcher Reihenfolge kompiliert werden. Standardmäßig Anwendung.css und Anwendung.js (oder ihre sass / Coffeescript-Äquivalente) sowie alle Nicht-Javascript- und Nicht-CSS-Assets sind enthalten. Um eine andere CSS- oder Javascript-Datei als die Anwendung einzuschließen.css und Anwendung.js, Sie müssen es auf zwei Arten benötigen:

1. Fügen Sie es dem Vorkompilierungsarray in config/initializers/assets.rb (Rails 4) oder Ihrer Anwendungskonfigurationsdatei (z. B. config/application.rb ) oder
2. hinzu Fügen Sie die Datei in das Manifest Ihres Assets oder eines der Manifeste seiner Unterdatei ein.

Die erste Option sieht folgendermaßen aus:

12

# In config/initializers/assets.rbRails.application.config.assets.precompile += %w( some-other-file.js even-another.css )

Diese Option eignet sich am besten für Dateien, die nur auf bestimmten Seiten und nicht auf anderen Seiten enthalten sein sollten. Wenn Sie beispielsweise einen Teil Ihrer Website haben, der als eingebettetes Iframe-Widget verwendet wird, möchten Sie möglicherweise nur widget.js und widget.css oder ähnliches auf dieser Seite verwenden. Diese Dateien müssten wie oben gezeigt zum Vorkompilierungsarray hinzugefügt werden.

Die zweite Option sollte die meiste Zeit verwendet werden und ermöglicht das Kompilieren Ihrer Javascript- und CSS-Dateien in einer Anwendung.js und eine Anwendung.CSS-Datei. Das Manifest wird oben in das entsprechende Asset geschrieben.

In Coffeescript sieht es so aus:

12345

# In application.coffee##= require jquery#= require jquery_ujs#= require_tree .

Das obige Manifest enthält jQuery, den Rails jQuery unobtrusive Scripting Adapter (jquery_ujs) und alle Dateien im aktuellen Baum (dh app/assets/javascript/*). Beachten Sie, dass require_tree Assets nicht rekursiv über Verzeichnisse kompiliert. Wenn Sie einen Ordner mit Dateien haben, den Sie einschließen möchten, müssen Sie diesen auch zum Manifest hinzufügen:

1

#= require_tree ./components

Eine weitere Manifest-Direktive ist require_self , die verwendet wird, um das Javascript der aktuellen Datei an diesem Punkt in der Kette einzuschließen. Das Obige mit einem require_self kann wie folgt in eine .js -Datei geschrieben werden:

1234567

// In application.js////= require jquery//= require jquery_ujs//= require_tree .//= require_tree ./components//= require_self

Die Sass / CSS-Manifeste verwenden dasselbe Grundformat, jedoch mit dem entsprechenden Kommentarstil:

123456

/** In application.css * *= require reset *= require global *= require layout */

Beachten Sie, dass Sie bei Verwendung von Sass die @import -Regel verwenden müssen, um Variablen und Mixins zu nutzen, da jede vom Manifest kompilierte Datei einen eigenen Gültigkeitsbereich hat.

Seien Sie vorsichtig bei der Verwendung der require_tree -Direktive. Assets im Baum werden in alphabetischer Reihenfolge enthalten sein, was bedeutet, dass, wenn eine Datei, die mit „a“ beginnt, von einer Datei abhängt, die mit „z“ beginnt, Probleme auftreten können, bei denen die erforderlichen Teile nicht verfügbar sind, wenn das Javascript vom Browser ausgewertet wird. Dieses Problem kann vermieden werden, indem Sie die entsprechenden Wachen jQuery(document).ready() oder window.onload verwenden, indem Sie eine Bestellung manuell angeben oder den Dateien Zahlen wie 01_ , 02_ voranstellen:

12345

# application.js# Note that the `.js` isn't needed at the end of the filename.##= require subfolder/library#= require subfolder/depends-on-library

Denken Sie daran, dass jede vorkompilierte Javascript- oder CSS-Datei oben ein Manifest enthalten kann, sodass Sie die Dateien von Unterordnern verwenden können, um Ihr Manifest der obersten Ebene zu vereinfachen.

Sass und Coffescript und Rails Asset Helpers

Ich habe Sass und Coffeescript in den obigen Abschnitten ein wenig erwähnt, aber ich bin noch nicht darauf eingegangen, was sie sind. Wenn Sie bereits mit ihnen vertraut sind, können Sie den Abschnitt „Rails Asset Helpers“ überspringen.

Sass und Coffeescript

Sass und Coffeescript sind Sprachen, die Präprozessoren verwenden, um ihre Syntax in CSS bzw. Es gibt mehrere andere vorverarbeitete Sprachen wie Typescript und Less, aber Sass und Coffeescript sind standardmäßig in Rails enthalten und wahrscheinlich die beliebtesten. Ich werde hier nicht ausführlich auf diese Sprachen eingehen, bitte schauen Sie sich die obigen Links an, um weitere Informationen zu erhalten.

Aus meiner Erfahrung ist die Tatsache, dass Ausnahmen für ungültigen Code in der Vorverarbeitungsphase ausgelöst werden, ausreichend, um ihre Verwendung zu rechtfertigen, während Sass und Coffeescript viel syntaktischen Zucker (hübsche Codefunktionen) bereitstellen. Coffeescript umschließt Ihren Code automatisch pro Datei und fügt Ihren lokalen Variablen das Schlüsselwort var hinzu, wodurch viele Bereichskopfschmerzen vermieden werden, die in Vanilla Javascript leichter auftreten können.

Zum Beispiel der folgende Coffeescript-Code:

12345

$ -> $('#element').on 'click', -> state = 'clicked' window.state = 'clicked' console.log 'element clicked'

wird in das folgende Javascript konvertiert:

1234567891011

(function() { $(function() { return $('#element').on('click', function() { var state; state = 'clicked'; window.state = 'clicked'; return console.log('element clicked'); }); });}).call(this);

Wenn der Präprozessor die Datei verarbeitet, umschließt er den Code automatisch in eine anonyme Funktion ((function() {}).call(this) ) und fügt der ersten Verwendung von state das Schlüsselwort var hinzu. Wenn Sie den globalen Bereich verwenden möchten, müssen Sie dies mit dem Präfix window. angeben.

Coffeescript enthält noch viel mehr, aber das automatische Scoping war für mich persönlich äußerst hilfreich, um schwer zu findende Fehler zu verhindern.

Rails Asset Helpers

Eine weitere großartige Funktion, die Sie nur mit Sass in Ihrem Rails-Projekt erhalten können, sind die Asset Path Helpers. Wenn Sie auf andere Assets in Ihrem Sass verweisen, können Sie die folgende Syntax verwenden, um die entsprechenden Pfade abzurufen:

123

.logo { background-image: image-url("logo.png");}

Die Helfer image-path, asset-url und asset-path können ebenfalls verwendet werden. Die -url Helfer umschließen den Pfad mit url() .

Erb in Assets

Mit der Asset-Pipeline können Sie Erb-Code in Ihren CSS- und Javascript-Assets auswerten, indem Sie den Dateinamen mit anhängen.erb (z. B. application.js.erb oder application.scss.erb). Dies kann zwar nützlich sein, um Ihrem Javascript Asset-Pfade hinzuzufügen, aber im Großen und Ganzen empfehle ich die Verwendung dieser Funktion nicht. Es fügt der Datei einen weiteren Vorverarbeitungsschritt hinzu, wodurch die Zeit für die Vorkompilierung erhöht wird. Es kann auch zu schlechten Gewohnheiten führen. Sie könnten versucht sein, Code hinzuzufügen, der zur Kompilierungszeit keinen Sinn ergibt, z. B. das Übersetzen von Zeichenfolgen. Diese Zeichenfolgen würden nur zur Kompilierungszeit übersetzt, wodurch der gesamte Zweck der Übersetzung zunichte gemacht würde. Der einzige Grund, Erb in einer Javascript-Datei zu verwenden, sollte darin bestehen, den asset_path -Helfer zu verwenden, wie im Handbuch beschrieben.

Asset-Pipeline-Fallstricke

Im Folgenden finden Sie einige Fallstricke und Leckerbissen, die bei der Entwicklung der Assets Ihrer Rails-Anwendung hilfreich sein können.

• Wie füge ich globale Daten für mein Javascript hinzu?
  • Mit dem gon-Juwel können Daten mit globalem Gültigkeitsbereich in die Seite eingefügt werden, damit Ihr Javascript sie verwenden kann. Dies ist ideal für Dinge wie die Bereitstellung der aktuellen Benutzer-ID oder Site-Einstellungen.
• Wo soll ich das vorkompilierte Array erweitern?
  • In Rails 4 sollten Sie das Array in config/initializers/assets.rb erweitern, und in Rails 3 sollten Sie dies in config/application.rb tun. Assets verwenden.rb oder Anwendung.rb legt das Vorkompilierungsarray für alle Umgebungen fest, sodass Sie beim Hinzufügen einer Umgebung (möglicherweise staging) das Vorkompilierungsarray nicht speziell für diese neue Umgebung erweitern müssen.
    • Vermögenswerte.rb: Rails.application.config.assets.precompile += %w( widget.css widget.js )
    • anwendung.rb: config.assets.precompile += %w( widget.js widget.css )
• Wann sollte ich Assets separat vorkompilieren, indem ich das Vorkompilier-Array erweitere?
  • Dies sollte selten getan werden. In den meisten Fällen möchten Sie dies nur tun, wenn das Asset allein auf einer speziellen Seite enthalten ist, auf der Sie den Rest der Assets nicht möchten, z. B. ein in iframe eingebettetes Widget. Verwenden Sie Ihre Anwendung.js und Anwendung.CSS-Manifeste zum Abrufen Ihrer Assets.
• Sollte ich Rails erlauben, statische Dateien bereitzustellen?
  • Ja. Dies folgt den Zwölf-Faktor-App-Richtlinien und verhindert Fehler, wenn Sie vergessen haben, eine Datei in das Vorkompilierungsarray aufzunehmen oder wenn Sie vergessen haben, eine Vorkompilierung durchzuführen.
  • Setzen Sie config.serve_static_assets = true in Schienen 3 und config.serve_static_files = true in Schienen 4.
• Wie kann ich sicherstellen, dass mein Javascript / CSS gut geschrieben ist?
  • Das Schreiben von hochwertigem Javascript und CSS (oder Coffeescript und Sass) kann viel Zeit und Erfahrung in Anspruch nehmen, aber eine Sache, die mir sehr geholfen hat, ist die Verwendung eines Linters. Einige IDEs, wie Sublime Text, haben Plugins, die Linters integrieren. Ich persönlich benutze das SublimeLinter-Paket. Wenn Sie einfaches Javascript und CSS schreiben möchten, sollten Sie auf jeden Fall einen Linter verwenden.
• Wie ändere ich das Verzeichnis, in dem meine vorkompilierten Assets abgelegt werden?
  • Sie können die Einstellung config.asset.prefix in ein anderes Verzeichnis ändern, z. B. /static.
  • Ändern Sie das Asset-Präfix in development.rb, wenn Sie vorkompilierte Assets in git für die Produktion verfolgen möchten.
  • Ändern Sie das Asset-Präfix global, wenn Sie den Pfadnamespace /assets für Ihre Controller verwenden möchten.
• Wie stelle ich statische Assets mit Nginx bereit?
  • Die grundlegende Nginx-Direktive sollte folgendermaßen aussehen (weitere Informationen finden Sie im Abschnitt Vorkompilieren von Assets im Rails-Handbuch):

1234567

location ~ ^/assets/ { expires 1y; add_header Cache-Control public; add_header ETag ""; break;}

• Was ist manifest.yml oder Manifest-.json?
  • Das Manifest.yml (Rails 3) oder Manifest-.json-Dateien (Rails 4) werden automatisch erstellt, wenn Sie Ihre Assets mit rake assets:precompile vorkompilieren. Sie enthalten Informationen darüber, welche Dateien von Ihrer App verwendet werden sollen.
• Welche Dateitypen sollten NICHT in die Asset-Pipeline aufgenommen werden?
  • Normalerweise möchten Sie große Dateien (Videos, eine große Anzahl von PDF-Downloads usw.) aufbewahren.) in einem separaten Repository oder in einem Cloud-Dateimanager wie AWS S3. Die Dateien können dann von Ihrer App aus referenziert werden, müssen jedoch nicht Ihr Git-Repository durchsuchen.
• Wie kann ich meine Rails 3-Assets schneller kompilieren?
  • Verwenden Sie den Edelstein turbo-sprockets-rails3.
• Kann ich ein CDN (Content Delivery Network) für meine Assets verwenden?
  • Ja! Durch den Digest oder Fingerabdruck, der jedem Asset hinzugefügt wird, funktionieren sie hervorragend mit CDNs. Richten Sie Ihr CDN so ein, dass Assets aus Ihrer Rails-App bereitgestellt werden, und legen Sie dann die Konfiguration config.action_controller.asset_host auf die entsprechende Domäne für Ihr CDN fest (z. B. config.action_controller.asset_host = 'mycdn.fictional-cdn.com'). Ich empfehle, Umgebungsvariablen zu verwenden, um dies festzulegen: config.action_controller.asset_host = ENV .

Einpacken

Wenn Sie die Asset-Pipeline ordnungsgemäß verwenden, kann die Gesamtqualität Ihrer Anwendung in Bezug auf Leistung, Ausfallsicherheit und Code-Sauberkeit verbessert werden. Mithilfe der Funktionen der Asset-Pipeline können Sie einige der größten Probleme im Zusammenhang mit der Codierung und Bereitstellung statischer Assets automatisch beheben.