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

Erste Schritte mit der Asset-Pipeline, Teil 1

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

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

In diesem ersten Artikel einer neuen Reihe über die Asset-Pipeline in Rails möchte ich einige allgemeine Konzepte erörtern, die nützlich sind, um zu verstehen, was die Asset-Pipeline zu bieten hat und was sie unter der Haube tut. Die wichtigsten Dinge, die es für Sie verwaltet, sind Verkettung, Minimierung und Vorverarbeitung von Assets. Als Anfänger müssen Sie sich so früh wie möglich mit diesen Konzepten vertraut machen.

Themen

  • Asset Pipeline?
  • Organisation
  • Verkettung & Komprimierung?
  • Hochsprachen

Asset Pipeline?

Die Asset-Pipeline ist nicht gerade eine Neuigkeit für Geschäftsleute, aber für Anfänger kann es etwas schwierig sein, dies schnell herauszufinden. Entwickler verbringen nicht gerade viel Zeit mit Front-End-Dingen, insbesondere wenn sie anfangen. Sie sind mit vielen beweglichen Teilen beschäftigt, die nichts mit HTML, CSS oder den oft verprügelten JS-Bits zu tun haben.

Die Asset-Pipeline kann helfen, indem sie die Verkettung, Minimierung und Vorverarbeitung von Assets verwaltet, z. B. Assets, die in Hochsprachen wie CoffeeScript oder Sass geschrieben sind.

Dies ist ein wichtiger Schritt im Erstellungsprozess für Rails-Apps. Mit der Asset-Pipeline können Sie nicht nur Qualität und Geschwindigkeit, sondern auch Komfort steigern. Wenn Sie Ihr eigenes maßgeschneidertes Build-Werkzeug einrichten müssen, haben Sie möglicherweise einige weitere Optionen für die Feinabstimmung Ihrer Anforderungen. Dies ist jedoch mit einem Aufwand verbunden, der für Anfänger zeitaufwändig und möglicherweise sogar einschüchternd sein kann. In diesem Zusammenhang könnten wir über die Asset-Pipeline als eine Lösung sprechen, die den Komfort gegenüber der Konfiguration fördert.

Das andere, was nicht zu unterschätzen ist, ist die Organisation. Die Pipeline bietet einen soliden Rahmen für die Platzierung Ihrer Assets. Bei kleineren Projekten scheint dies zwar nicht so wichtig zu sein, aber größere Projekte können sich möglicherweise nicht leicht davon erholen, bei solchen Themen in die falsche Richtung zu gehen. Dies ist möglicherweise nicht das häufigste Beispiel auf der Welt, aber stellen Sie sich ein Projekt wie Facebook oder Twitter vor, dessen CSS- und JS-Ressourcen schlecht organisiert sind. Es ist nicht schwer vorstellbar, dass dies zu Problemen führen würde und dass Menschen, die auf einer solchen Basis arbeiten und bauen müssen, es nicht leicht haben würden, ihre Arbeit zu lieben.

Wie bei vielen Dingen in Rails gibt es einen herkömmlichen Ansatz für den Umgang mit Assets. Diesmacht es einfacher, neue Leute zu gewinnen und zu vermeiden, dass Entwickler und Designer zu besessen davon sind, ihren eigenen Teig zur Party zu bringen.

Wenn Sie einem neuen Team beitreten, möchten Sie in der Lage sein, schnell auf den neuesten Stand zu kommen und sofort loszulegen. Es ist nicht gerade hilfreich, herauszufinden, wie andere Leute ihr Vermögen organisiert haben. In extremen Fällen kann dies sogar als verschwenderisch angesehen werden und unnötig Geld verbrennen. Aber lassen Sie uns hier nicht zu dramatisch werden.

Dieser Artikel richtet sich also an Anfänger unter Ihnen, und ich empfehle, sich sofort die Pipeline anuschauen und dieses Thema in den Griff zu bekommen, auch wenn Sie nicht erwarten, in Zukunft viel an Markup- oder Front-Endy-Dingen zu arbeiten . Es ist ein wesentlicher Aspekt in Rails und kein so großer Deal. Außerdem werden Ihre Teammitglieder, insbesondere Designer, die die Hälfte ihres Lebens in diesen Verzeichnissen verbringen, weniger lustige Dinge in Ihren Kaffee einbringen, wenn Sie Gemeinsamkeiten haben, die nicht miteinander in Konflikt stehen.

Organisation

Sie haben drei Möglichkeiten, Ihr Vermögen zu platzieren. Diese Unterteilungen sind eher logisch. Sie stellen keine technischen Einschränkungen oder Einschränkungen dar. Sie können Assets in jedem von ihnen platzieren und die gleichen Ergebnisse sehen. Für eine intelligentere Organisation sollten Sie jedoch einen guten Grund haben, Inhalte an der richtigen Stelle zu platzieren.

  • app/assets

Der Ordner app/assets ist für Assets vorgesehen, die speziell für diese App bestimmt sind - Bilder, JS- und CSS-Dateien, die auf ein bestimmtes Projekt zugeschnitten sind.

  • lib/assets

Der lib/assets-Ordner ist andererseits die Heimat Ihres eigenen Codes, den Sie von Projekt zu Projekt wiederverwenden können - Dinge, die Sie möglicherweise selbst extrahiert haben und von einem Projekt zum nächsten übertragen möchten - insbesondere Assets, die Sie verwenden kann zwischen Anwendungen teilen.

  • vendor/assets

vendor/assets ist ein weiterer Schritt nach außen. Hier finden Sie Assets, die Sie aus anderen externen Quellen wiederverwendet haben - Plugins und Frameworks von Drittanbietern.

Dies sind die drei Standorte, an denen Sprockets nach Assets suchen wird. In den oben genannten Verzeichnissen wird von Ihnen erwartet, dass Sie Ihre Assets in den Ordnern /images, /stylesheets und /javascripts ablegen. Aber das ist eher eine konventionelle Sache; Alle Assets in den Ordnern */assets werden durchlaufen. Sie können bei Bedarf auch Unterverzeichnisse hinzufügen. Rails wird sich ohnehin nicht beschweren und ihre Dateien vorkompilieren.

Es gibt eine einfache Möglichkeit, den Suchpfad der Asset-Pipeline zu überprüfen. Wenn Sie eine Rails-Konsole mit rails console starten, können Sie sie mit dem folgenden Befehl überprüfen:

Terminal

Sie erhalten ein Array mit allen Verzeichnissen der Assets, die von Sprockets verfügbar und gefunden werden - auch bekannt als Suchpfad.

Das Schöne an all dem ist leicht zu übersehen. Es ist der Aspekt von Konventionen. Das bedeutet, dass Entwickler - und eigentlich auch Designer - bestimmte Erwartungen haben können, wo nach Dateien gesucht und wo sie abgelegt werden sollen. Das kann eine enorme Zeitersparnis (Trump Voice) bedeuten. Wenn jemand neu einem Projekt beitritt, hat er eine gute Idee, wie er sofort in einem Projekt navigieren kann.

Das ist nicht nur praktisch, sondern kann auch fragwürdige Ideen verhindern oder das Rad ständig neu erfinden. Ja, Konventionen über die Konfiguration können manchmal etwas langweilig klingen, aber es ist trotzdem mächtiges Zeug. Wir konzentrieren uns auf das Wesentliche: die Arbeit selbst und eine gute Zusammenarbeit im Team.

Die genannten Vermögenspfade sind jedoch nicht in Stein gemeißelt. Sie können auch benutzerdefinierte Pfade hinzufügen. Öffnen Sie config/application.rb und fügen Sie benutzerdefinierte Pfade hinzu, die von Rails erkannt werden sollen. Schauen wir uns an, wie wir einen custom_folder hinzufügen würden.

config.application.rb

Wenn Sie jetzt den Suchpfad erneut überprüfen, wird Ihr benutzerdefinierter Ordner Teil des Suchpfads für die Asset-Pipeline. Übrigens ist es jetzt das letzte Objekt im Array:

Terminal

Ausgabe

Verkettung & Komprimierung?

Warum brauchen wir das Zeug? Kurz gesagt, Sie möchten, dass Ihre Apps schneller geladen werden. Zeitraum! Alles, was dabei hilft, ist willkommen. Natürlich können Sie davonkommen, ohne dafür zu optimieren, aber es hat zu viele Vorteile, die man einfach nicht ignorieren kann. Das Komprimieren von Dateigrößen und das Verketten mehrerer Asset-Dateien zu einer einzigen „Master“ -Datei, die von einem Client wie einem Browser heruntergeladen wird, ist ebenfalls nicht so viel Arbeit. Es wird sowieso meistens von der Pipeline gehandhabt.

Das Reduzieren der Anzahl von Anforderungen zum Rendern von Seiten ist sehr effektiv, um die Dinge zu beschleunigen. Anstatt vielleicht 10, 20, 50 oder eine beliebige Anzahl von Anforderungen zu haben, bevor der Browser Ihre Assets abruft, könnten Sie möglicherweise nur eine für jedes CSS- und JS-Asset haben. Heute ist das eine schöne Sache, aber irgendwann war dies ein Game Changer. Diese Art von Verbesserungen in der Webentwicklung sollten nicht vernachlässigt werden, da es sich um Millisekunden als Einheit handelt.

Viele Anfragen können sich erheblich summieren. Und schließlich ist die Benutzererfahrung für erfolgreiche Projekte am wichtigsten. Es kann ein großer Deal-Breaker sein, wenn Benutzer nur auf das gewisse Extra warten, bevor sie den auf Ihrer Seite gerenderten Inhalt sehen können. Geduld können wir von unseren Nutzern nicht erwarten.

Die Minimierung ist cool, weil unnötige Inhalte in Ihren Dateien entfernt werden - Leerzeichen und Kommentare im Grunde. Diese komprimierten Dateien werden nicht unter Berücksichtigung der menschlichen Lesbarkeit erstellt. Sie sind ausschließlich für den Maschinenverbrauch bestimmt. Die Dateien sehen am Ende etwas kryptisch und schwer zu lesen aus, obwohl es sich immer noch um gültigen CSS- und JS-Code handelt - nur ohne überschüssige Leerzeichen, um sie für Menschen lesbar und verständlich zu machen.

Die JS-Komprimierung ist jedoch etwas komplizierter. Webbrowser benötigen diese Formatierung nicht. Dadurch können wir diese Assets optimieren. Das Problem in diesem Abschnitt ist, dass eine geringere Anzahl von Anfragen und minimierte Dateigrößen die Dinge beschleunigen und in Ihrer Trickkiste stecken sollten. Rails bietet Ihnen diese Funktionalität sofort ohne zusätzliche Einrichtung.

Hochsprachen

Sie haben vielleicht schon davon gehört, aber als Anfänger wissen Sie vielleicht nicht genau, warum Sie noch eine andere Sprache lernen sollten - insbesondere, wenn Sie noch damit beschäftigt sind, klassisches HTML und CSS zu lernen. Diese Sprachen wurden entwickelt, um Mängel zu beheben, die Entwickler ausbügeln wollten. Sie befassen sich hauptsächlich mit Problemen, mit denen sich Entwickler nicht täglich befassen wollten. Klassische faulheitsgetriebene Entwicklung, denke ich.

„Hochsprachen“ klingen ausgefallener als es vielleicht ist - sie sind jedoch radikal. Wir sprechen über Sass, CoffeeScript, Haml, Slim, Jade und ähnliches. Mit diesen Sprachen können wir in einer (meistens) benutzerfreundlichen Syntax schreiben, mit der bequemer und effizienter gearbeitet werden kann. Alle müssen während eines Erstellungsprozesses vorkompiliert werden.

Ich erwähne dies, weil dies hinter den Kulissen passieren kann, ohne dass Sie es merken. Das bedeutet, dass diese Assets verwendet und in CSS, HTML und JS umgewandelt werden, bevor sie bereitgestellt werden und vom Browser gerendert werden können.

Sass

Sass steht für "Syntactically Awesome Style Sheets" und ist viel leistungsfähiger als reines CSS. Damit können wir intelligentere Stylesheets schreiben, in die einige Programmierwerkzeuge integriert sind. Worüber reden wir hier genau? Sie können Variablen deklarieren, Regeln verschachteln, Funktionen schreiben, Mixins erstellen, Partials einfach importieren und viele andere Dinge, die Programmierer beim Spielen mit Stilen zur Verfügung haben wollten.

Es hat sich mittlerweile zu einem ziemlich umfangreichen Werkzeug entwickelt und eignet sich hervorragend zum Organisieren von Stylesheets - für große Projekte würde ich es sogar als wesentlich bezeichnen. Heutzutage bin ich mir nicht sicher, ob ich mich nicht von einer großen App fernhalten würde, die kein Werkzeug wie Sass verwendet - oder was auch immer nicht Ruby-zentrierte Frameworks in dieser Hinsicht zu bieten haben.

Für Ihre aktuellen Bedenken gibt es zwei Syntaxversionen von Sass, die Sie kennen müssen. Die freche CSS-Version, auch bekannt als SCSS, ist die am weitesten verbreitete. Es bleibt näher an einfachem CSS, bietet aber alle ausgefallenen Erweiterungen, die Entwickler und Designer lieben, um mit Stylesheets zu spielen. Es verwendet die Dateierweiterung .scss und sieht folgendermaßen aus:

SCSS

Optisch unterscheidet es sich nicht wesentlich von CSS - deshalb ist es die beliebteste Wahl, insbesondere bei Designern, denke ich. Einer der wirklich coolen und praktischen Aspekte von SCSS und Sass im Allgemeinen ist der Verschachtelungsaspekt. Dies ist eine effektive Strategie zum Erstellen lesbarer Stile, reduziert aber auch die Anzahl der sich wiederholenden Deklarationen erheblich.

SCSS

Vergleichen Sie das obige Beispiel mit der jeweiligen CSS-Version. Sieht gut aus, um diese Stile mit Nesting abzunehmen, oder?

CSS

Die eingerückte Sass-Syntax hat die Dateierweiterung .sass. Mit diesem können Sie vermeiden, mit all diesen albernen geschweiften Klammern und Semikolons umzugehen, die faule Entwickler gerne vermeiden.

Wie macht es das? Ohne die Klammern verwendet Sass Einrückungen, im Wesentlichen Leerzeichen, um seine Eigenschaften zu trennen. Es ist ziemlich toll und sieht auch sehr cool aus. Um die Unterschiede zu erkennen, zeige ich Ihnen beide Versionen nebeneinander.

.sass

.scss

Ziemlich schön und kompakt, oder? Beide Versionen müssen jedoch verarbeitet werden, bevor sie zu einem gültigen CSS werden, das Browser verstehen können. Die Asset Pipeline erledigt das für Sie. Wenn Sie Browser mit etwas wie Sass aufrufen, haben diese keine Ahnung, was los ist.

Ich persönlich bevorzuge die eingerückte Syntax. Diese Whitespace-sensitive Sass-Syntax ist weniger beliebt als die SCSS-Syntax, weshalb sie möglicherweise nicht die ideale Wahl für andere als Ihre persönlichen Projekte ist. Es ist wahrscheinlich eine gute Idee, die beliebteste Wahl in Ihrem Team zu treffen, insbesondere bei beteiligten Designern. Es scheint eine schlechte Idee zu sein, Whitespace-Hipness mit Menschen zu erzwingen, die jahrelang alle geschweiften Klammern und Semikolons gezähmt haben.

Beide Versionen haben die gleichen Programmiertricks im Ärmel. Sie eignen sich hervorragend, um den Prozess des Schreibens von Stilen viel angenehmer und effektiver zu gestalten. Es ist ein Glück für uns, dass Rails und die Asset Pipeline es so einfach machen, mit beiden zu arbeiten - so ziemlich sofort.

Slim & Haml

Ähnliche Argumente können über die Vorteile der Verwendung von Slim und Haml vorgebracht werden. Sie sind sehr praktisch, um kompaktere Markups zu erstellen. Es wird in gültiges HTML kompiliert, aber die Dateien, mit denen Sie arbeiten, sind viel reduzierter.

Sie können sich die Mühe ersparen, schließende Tags zu schreiben und coole Abkürzungen für Tag-Namen und dergleichen zu verwenden. Diese kürzeren Markup-Bursts sind leichter zu überfliegen und zu lesen. Persönlich war ich noch nie ein großer Fan von Haml, aber Slim ist nicht nur schick und praktisch, es ist auch sehr klug. Für Leute, die die eingerückte Sass-Syntax mögen, würde ich definitiv empfehlen, damit zu spielen. Werfen wir einen kurzen Blick:

Schlank

Haml

Beides führt zu folgendem ERB-erweitertem HTML in Rails:

An der Oberfläche sind die Unterschiede nicht so groß, aber ich habe nie ganz verstanden, warum Haml möchte, dass ich all diese zusätzlichen % schreibe, um Tags voranzustellen. Slim hat eine Lösung gefunden, die diese beseitigt, und deshalb grüße ich das Team! Kein großer Schmerz, aber dennoch ein nerviger. Die anderen Unterschiede liegen unter der Haube und fallen heute nicht in den Geltungsbereich dieses Stücks. Ich wollte nur Appetit machen.

Wie Sie sehen können, reduzieren beide Präprozessoren den Schreibaufwand erheblich. Ja, Sie müssen eine andere Sprache lernen, und sie liest sich zunächst etwas seltsam. Gleichzeitig denke ich, dass es sich absolut lohnt, so viel Unordnung zu beseitigen. Sobald Sie wissen, wie man HTML mit ERB-Geschmack schreibt, können Sie jeden dieser Präprozessoren ziemlich schnell erkennen. Keine Raketenwissenschaft - das gilt übrigens auch für Sass.

Falls Sie interessiert sind, gibt es zwei praktische Edelsteine, mit denen Sie beide in Rails verwenden können. Tun Sie sich selbst einen Gefallen und probieren Sie sie aus, wenn Sie es satt haben, all diese lästigen Öffnungs- und Schließ-Tags zu schreiben.

CoffeeScript

CoffeeScript ist eine Programmiersprache wie jede andere, hat aber das Ruby-Flair zum Schreiben Ihres JavaScript. Durch die Vorverarbeitung wird es in einfaches altes JavaScript kompiliert, mit dem Browser umgehen können. Das kurze Argument für die Arbeit mit CoffeeScript war, dass es dazu beitrug, einige Mängel zu beseitigen, die JS mit sich herumtrug. In der Dokumentation heißt es, dass die "guten Teile von JavaScript auf einfache Weise" verfügbar gemacht werden sollen. Meinetwegen! Schauen wir uns ein kurzes Beispiel an und sehen, womit wir es zu tun haben:

JavaScript

In CoffeeScript würde dieser Typ folgendermaßen aussehen:

CoffeeScript

Liest nur ein bisschen schöner ohne all die Locken und Semikolons, oder? CoffeeScript versucht, einige der nervigen Teile in JavaScript zu beseitigen, lässt Sie weniger tippen, macht den Code ein bisschen lesbarer, bietet eine freundlichere Syntax und geht angenehmer mit dem Schreiben von Klassen um. Das Definieren von Klassen war für eine Weile ein großes Plus, insbesondere für Leute aus Ruby, die sich nicht besonders gern mit reinem JavaScript beschäftigten. CoffeeScript verfolgte einen ähnlichen Ansatz wie Ruby und gibt Ihnen ein schönes Stück syntaktischen Zuckers. Klassen sehen zum Beispiel so aus:

Class

Diese Sprache war im Rubinland eine Weile sehr beliebt. Ich bin mir nicht sicher, wie die Adoptionsraten heutzutage sind, aber CoffeeScript ist die Standard-JS-Variante in Rails. Mit ES6 unterstützt JavaScript jetzt auch Klassen - ein wichtiger Grund, möglicherweise kein CoffeeScipt zu verwenden und stattdessen mit einfachem JS zu spielen. Ich denke, CoffeeScript liest sich immer noch besser, aber viele der weniger kosmetischen Gründe für die Verwendung wurden heutzutage mit ES6 behoben. Ich denke, es ist immer noch ein guter Grund, es zu versuchen, aber dafür sind Sie nicht gekommen. Ich wollte Ihnen nur eine weitere Vorspeise geben und ein wenig Kontext dazu geben, warum Sie mit der Asset-Pipeline sofort in CoffeeScript arbeiten können.

Abschließende Gedanken

Die Asset Pipeline hat sich bei ihrer Einführung weit über meine Erwartungen hinaus bewährt. Zu der Zeit sorgte es wirklich für Furore und war ein ernstes Problem für Entwickler. Dies ist natürlich immer noch der Fall und hat sich als reibungsloses und müheloses Werkzeug etabliert, das die Qualität Ihrer Anwendungen verbessert.

Was mir am besten gefällt, ist, wie wenig Aufwand es bedeutet, es zum Laufen zu bringen. Versteh mich nicht falsch, Werkzeugs wie Gulp und Grunt sind ebenfalls beeindruckend. Die Anpassungsmöglichkeiten sind vielfältig. Ich kann das angenehme Gefühl, das Rails mir gibt, einfach nicht loswerden, wenn ich mich vor dem Start nicht mit einem Setup befassen muss. Konventionen können mächtig sein, insbesondere Molke, die nahtlos und problemlos zu etwas führt.

Advertisement
Advertisement
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.