In diesem ersten Artikel einer neuen Serie über die Asset Pipeline in Rails möchte ich ein paar hochrangige Konzepte erläutern, die praktisch sind, um zu verstehen, was die Asset Pipeline zu bieten hat und was sie unter der Haube leistet. Die wichtigsten Dinge, die für Sie verwaltet werden, sind Verkettung, Minifizierung 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 für Leute in der Branche nicht gerade eine Neuigkeit, für Anfänger kann es jedoch ein bisschen schwierig sein, schnell etwas herauszufinden. Entwickler verbringen nicht gerade viel Zeit mit Front-End-Sachen, besonders wenn sie anfangen. Sie sind mit vielen beweglichen Teilen beschäftigt, die nichts mit HTML, CSS oder den oftmals basierten 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 Build-Prozess für Rails-Apps. Mit der Asset-Pipeline können Sie nicht nur hinsichtlich Qualität und Geschwindigkeit, sondern auch hinsichtlich des Komforts einen Schub erzielen. Wenn Sie Ihr eigenes, maßgeschneidertes Build-Tool einrichten müssen, haben Sie möglicherweise ein paar weitere Optionen zur Feinabstimmung Ihrer Anforderungen. Dies ist jedoch mit einem Aufwand verbunden, der für Anfänger zeitaufwendig sein kann - vielleicht sogar einschüchternd. In dieser Hinsicht könnten wir über die Asset-Pipeline als eine Lösung sprechen, die den Komfort der Konfiguration erleichtert.
Die andere Sache, die nicht unterschätzt werden sollte, ist die Organisation. Die Pipeline bietet einen soliden Rahmen für die Platzierung Ihrer Vermögenswerte. Bei kleineren Projekten scheint dies zwar nicht so wichtig zu sein, sicher, aber größere Projekte können sich nicht leicht erholen, wenn sie bei solchen Themen in die falsche Richtung gehen. Dies ist möglicherweise nicht das häufigste Beispiel der Welt, aber stellen Sie sich nur ein Projekt wie Facebook oder Twitter vor, das eine schlechte Organisation für CSS und JS hat. Es ist nicht schwer vorstellbar, dass dies zu Schwierigkeiten führen würde und dass Menschen, die auf einer solchen Grundlage arbeiten und bauen müssen, keine leichte Zeit haben werden, wenn sie ihren Job lieben.
Wie bei vielen Dingen in Rails gibt es einen konventionellen Ansatz für den Umgang mit Assets. Dies macht es einfacher, neue Leute an Bord zu nehmen und zu vermeiden, dass Entwickler und Designer zu besessen davon sind, ihren eigenen Teig mit auf die Party zu bringen.
Wenn Sie sich einem neuen Team anschließen, möchten Sie in der Lage sein, schnell auf den neuesten Stand zu kommen und den Boden zu rennen. Es ist nicht gerade hilfreich, wenn man herausfinden muss, wie andere Menschen ihre Vermögenswerte 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.
Daher ist dieser Artikel für Anfänger unter Ihnen gedacht, und ich empfehle Ihnen, sofort einen Blick auf die Pipeline zu werfen und dieses Thema in den Griff zu bekommen, auch wenn Sie in Zukunft nicht viel mit Markup oder Frontendy-Dingen zu tun haben . Dies ist ein wesentlicher Aspekt in Rails und kein so großer Deal. Außerdem werden Ihre Teammitglieder, insbesondere Designer, die ihr halbes Leben in diesen Verzeichnissen verbringen, weniger lustige Sachen in Ihren Kaffee stecken, wenn Sie Gemeinsamkeiten haben, die nicht miteinander in Konflikt stehen.
Organisation
Sie haben drei Möglichkeiten, Ihr Vermögen zu platzieren. Diese Spaltungen sind eher logischer Natur. Sie stellen keine technischen Einschränkungen oder Einschränkungen dar. Sie können Assets in jedem von ihnen platzieren und dieselben Ergebnisse sehen. Für eine intelligentere Organisation sollten Sie jedoch einen guten Grund haben, Inhalte an der richtigen Stelle zu platzieren.
Das App / Vermögenswerte Ordner ist für Assets, die speziell für diese App-Bilder, JS- und CSS-Dateien sind, die für ein bestimmtes Projekt maßgeschneidert sind.
lib / Vermögenswerte
lib / assets /
Das lib / Vermögenswerte Ordner ist dagegen die Heimat für Ihren eigenen Code, den Sie von Projekt zu Projekt wiederverwenden können - Dinge, die Sie möglicherweise selbst extrahiert haben und die Sie von einem Projekt zum nächsten bringen möchten, nämlich Assets, die Sie zwischen Anwendungen gemeinsam nutzen können.
Verkäufer / Vermögenswerte ist ein weiterer Schritt nach außen. Es ist das Zuhause für Assets, die Sie von anderen externen Quell-Plugins und Frameworks von Dritten wiederverwenden.
Dies sind die drei Standorte, an denen Sprockets nach Assets suchen. Es wird erwartet, dass Sie innerhalb der oben genannten Verzeichnisse Ihre Assets in der / Bilder, / Stylesheets und / Javascripts Ordner. Dies ist jedoch eher eine konventionelle Sache; alle Vermögenswerte innerhalb der */Vermögenswerte Ordner werden durchlaufen. Sie können bei Bedarf auch Unterverzeichnisse hinzufügen. Rails beschwert sich nicht und kompiliert ihre Dateien sowieso vorkompiliert.
Es gibt eine einfache Möglichkeit, den Suchpfad der Asset-Pipeline einzusehen. Wenn Sie eine Rails-Konsole mit einschalten Schienen-Konsole, Sie können es mit dem folgenden Befehl überprüfen:
Terminal
Rails.application.config.assets.paths
Sie erhalten ein Array mit allen Verzeichnissen von Assets, die von Sprockets-alias Suchpfad gefunden werden.
Das Schöne an all dem ist leicht zu übersehen. Es ist der Aspekt von Konventionen. Das bedeutet, dass Entwickler - und eigentlich auch Entwickler - bestimmte Erwartungen haben, wo sie nach Dateien suchen und wo sie abgelegt werden müssen. Das kann eine große Zeitersparnis (Trump-Stimme) sein. Wenn ein neuer Mitarbeiter einem Projekt beitritt, hat er eine gute Idee, wie er ein Projekt direkt navigieren kann.
Das ist nicht nur bequem, 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 sie sind trotzdem mächtig. Dadurch bleiben wir auf das Wesentliche fokussiert: auf die Arbeit selbst und auf eine gute Zusammenarbeit mit dem Team.
Die genannten Vermögenspfade sind jedoch nicht in Stein gemeißelt. Sie können auch benutzerdefinierte Pfade hinzufügen. Öffnen config / application.rb und fügen Sie benutzerdefinierte Pfade hinzu, die von Rails erkannt werden sollen. Schauen wir uns an, wie wir eine hinzufügen würden benutzerdefinierter Ordner.
config.application.rb
Modul TestApp-Klasse Anwendung < Rails::Application config.assets.paths << Rails.root.join("custom_folder") end end
Wenn Sie nun den Suchpfad erneut überprüfen, wird Ihr benutzerdefinierter Ordner Teil des Suchpfads für die Asset-Pipeline. Übrigens ist es jetzt das letzte im Array platzierte Objekt:
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 kann man auch ohne Optimierung davonkommen, aber es hat zu viele Vorteile, die man einfach nicht ignorieren kann. Das Komprimieren von Dateigrößen und das Verketten mehrerer Asset-Dateien in einer einzigen "Master" -Datei, die von einem Client wie einem Browser heruntergeladen wird, ist ebenfalls nicht so viel Arbeit. Sie wird meistens ohnehin von der Pipeline abgewickelt.
Das Reduzieren der Anzahl von Anforderungen für das Rendern von Seiten ist sehr effektiv, um die Abläufe zu beschleunigen. Anstatt 10, 20, 50 oder eine beliebige Anzahl von Anforderungen zu haben, bevor der Browser Ihre Assets abgerufen hat, können Sie möglicherweise nur eine für jedes CSS- und JS-Asset haben. Heute ist das eine nette Sache, aber irgendwann war dies ein Spielveränderer. Diese Art von Verbesserungen in der Webentwicklung sollte nicht vernachlässigt werden, da es sich bei Millisekunden um eine Einheit handelt.
Viele Anfragen können sich ziemlich beträchtlich summieren. Und schließlich ist die Benutzererfahrung für erfolgreiche Projekte am wichtigsten. Wenn Benutzer nur auf das gewisse Extra warten müssen, bevor sie den auf Ihrer Seite gerenderten Inhalt sehen können, kann dies ein massiver Dealbreaker sein. Geduld ist nicht etwas, was wir von unseren Nutzern erwarten können.
Minification ist cool, weil dadurch unnötiges Material in Ihren Dateien entfernt wird - Leerzeichen und Kommentare. Diese komprimierten Dateien werden nicht für die menschliche Lesbarkeit erstellt. Sie sind nur für den Maschinenverbrauch bestimmt. Die Dateien werden am Ende etwas kryptisch und schwer zu lesen sein, obwohl sie immer noch alle gültigen CSS- und JS-Codes enthalten - nur ohne übermäßige Leerzeichen, um sie für den 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 Ressourcen optimieren. In diesem Abschnitt ist es zum Mitnehmen, dass eine geringere Anzahl von Anforderungen und minimierte Dateigrößen die Abläufe beschleunigen und in Ihrem Trickkorb stecken sollten. Rails bietet Ihnen diese Funktionalität ohne zusätzliche Einstellungen.
Hochsprachen
Sie haben vielleicht schon von ihnen gehört, aber als Anfänger wissen Sie vielleicht nicht, warum Sie eine weitere Sprache lernen sollten - vor allem, wenn Sie noch mit klassischem HTML und CSS vertraut sind. Diese Sprachen wurden entwickelt, um mit den Fehlern umzugehen, die Entwickler ausbügeln wollten. Sie befassen sich hauptsächlich mit Problemen, mit denen sich Entwickler nicht täglich auseinandersetzen wollten. Ich denke, klassische Faulheitsentwicklung.
"High-Level-Sprachen" klingt mehr als es vielleicht ist - sie sind rad. Wir sprechen über Sass, CoffeeScript, Haml, Slim, Jade und solche Sachen. Diese Sprachen lassen uns in einer (meistens) benutzerfreundlichen Syntax schreiben, mit der man bequemer und effizienter arbeiten kann. Alle müssen während eines Erstellungsprozesses vorkompiliert werden.
Ich erwähne das, weil dies im Hintergrund passieren kann, ohne dass Sie es merken. Das bedeutet, dass diese Assets 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 stärker als reines CSS. Damit können wir intelligentere Stylesheets schreiben, in denen einige Programmiertools installiert sind. Worüber sprechen wir hier genau? Sie können Variablen deklarieren, Regeln verschachteln, Funktionen schreiben, Mixins erstellen, Partials importieren und vieles andere, was Programmierer beim Spielen mit Styles zur Verfügung haben wollten.
Es hat sich mittlerweile zu einem ziemlich reichhaltigen Tool entwickelt und eignet sich hervorragend für das Organisieren von Stylesheets - für große Projekte würde ich es sogar als unerlässlich bezeichnen. Heutzutage bin ich nicht sicher, ob ich mich einer großen App nicht entziehen würde, die kein Tool wie Sass oder was auch immer andere nicht-Ruby-basierte Frameworks in dieser Hinsicht zu bieten hat.
Für Ihre aktuellen Probleme gibt es zwei Syntaxversionen von Sass, die Sie kennen müssen. Die Sassy-CSS-Version, auch bekannt als SCSS, ist die am weitesten verbreitete. Es bleibt dem einfachen CSS näher, bietet jedoch alle ausgefallenen Erweiterungen, die Entwickler und Designer lieben, um mit Stylesheets zu spielen. Es verwendet die .scss Dateierweiterung und sieht so aus:
Optisch ist es nicht so anders als CSS, weshalb es die beliebtere Wahl ist, insbesondere bei Designern, die meiner Meinung nach tätig sind. Einer der wirklich coolen und praktischen Aspekte von SCSS und von Sass im Allgemeinen ist der Verschachtelungsaspekt. Dies ist eine effektive Strategie, um lesbare Stile zu erstellen, reduziert aber auch die Anzahl der wiederholten Deklarationen erheblich.
Die eingerückte Sass-Syntax hat die .sass Dateierweiterung. Damit vermeiden Sie den Umgang mit all diesen dummen geschweiften Klammern und Semikolons, die faule Entwickler gerne vermeiden.
Wie macht es das? Ohne die Klammern verwendet Sass die Einrückung, im Wesentlichen Leerzeichen, um seine Eigenschaften zu trennen. Es ist ziemlich cool und sieht auch wirklich cool aus. Um die Unterschiede zu sehen, zeige ich Ihnen beide Versionen nebeneinander.
Ziemlich schön und kompakt, oder? Beide Versionen müssen jedoch verarbeitet werden, bevor sie sich in gültiges CSS umwandeln, das Browser verstehen können. Die Asset Pipeline erledigt das für Sie. Wenn Sie mit so etwas wie Sass auf Browser stoßen, haben sie keine Ahnung, was los ist.
Ich persönlich bevorzuge die eingerückte Syntax. Diese Whitespace-sensitive Sass-Syntax ist weniger populär als die SCSS-Syntax. Daher ist sie möglicherweise nicht die ideale Wahl für andere Projekte als Ihre persönlichen. Es ist wahrscheinlich eine gute Idee, sich mit der beliebtesten Wahl in Ihrem Team zu beschäftigen, insbesondere mit den beteiligten Designern. Whitespace-Hipness mit Menschen zu erzwingen, die jahrelang alle geschweiften Klammern und Semikolons gezähmt haben, scheint eine schlechte Idee zu sein.
Beide Versionen haben die gleichen Programmier-Tricks im Ärmel. Sie sind hervorragend geeignet, um den Schreibprozess 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 diesen beiden zu arbeiten.
Slim & Haml
Ähnliche Argumente können über die Vorteile von Slim und Haml gesprochen werden. Sie sind sehr praktisch für die Erstellung kompakterer Markups. Es wird in gültigem HTML-Code kompiliert, aber die Dateien, mit denen Sie arbeiten, sind viel kleiner.
Sie können sich die Mühe sparen, schließende Tags zu schreiben, und coole Abkürzungen für Tagnamen und ähnliches verwenden. Diese kürzeren Markup-Bursts lassen sich leichter überfliegen und lesen. Ich persönlich war noch nie ein großer Fan von Haml, aber Slim ist nicht nur schick und bequem, sondern auch sehr schlau. Für Leute, die die eingerückte Sass-Syntax mögen, würde ich definitiv empfehlen, damit zu spielen. Lass uns einen kurzen Blick darauf werfen:
Schlank
#content .left.column h2 Willkommen auf unserer Website! p = print_information .right.column = rendern: teilweise => "Seitenleiste"
Haml
#content .left.column% h2 Willkommen auf unserer Website! % p = print_information .right.column = Rendern: teilweise => "Seitenleiste"
Beides führt zu dem folgenden ERB-erweiterten HTML in Rails:
Willkommen auf unserer Webseite!
<%= print_information %>
<%= render :partial => "Seitenleiste"%>
An der Oberfläche sind die Unterschiede nicht so groß, aber ich habe nie ganz verstanden, warum Haml möchte, dass ich all das extra schreibe % Tags voranstellen. Slim hat eine Lösung gefunden, die diese gelöst hat, und ich begrüße das Team! Kein großer Schmerz, aber trotzdem ein nerviger. Die anderen Unterschiede sind unter der Haube und fallen heute nicht in den Rahmen dieses Stücks. Ich wollte nur Appetit machen.
Wie Sie sehen, reduzieren beide Vorprozessoren den Schreibaufwand erheblich. Ja, Sie müssen eine andere Sprache lernen, und sie liest sich zunächst etwas komisch. Gleichzeitig finde ich, dass die Beseitigung dieser Unordnung sich wirklich lohnt. Sobald Sie wissen, wie man mit ERB-HTML-Code schreibt, können Sie einen dieser Präprozessoren ziemlich schnell abrufen. Keine Raketenwissenschaft - das gilt übrigens auch für Sass.
Für den Fall, dass Sie interessiert sind, gibt es zwei praktische Edelsteine, die Sie in Rails verwenden können. Tun Sie sich selbst einen Gefallen und prüfen Sie sie, wenn Sie es müde sind, all diese lästigen Öffnungs- und Schließ-Tags zu schreiben.
CoffeeScript ist eine Programmiersprache wie jede andere, aber sie hat das Ruby-Flair für das Schreiben von JavaScript. Durch die Vorverarbeitung wird es in altes JavaScript übersetzt, mit dem Browser umgehen können. Das kurze Argument für die Arbeit mit CoffeeScript war, dass es dabei half, einige Mängel zu beseitigen, die JS mit sich brachte. In der Dokumentation heißt es, sie zielt darauf ab, die „guten Teile von JavaScript auf einfache Art und Weise darzustellen“. Meinetwegen! Werfen wir einen kurzen Blick auf ein kurzes Beispiel, um zu sehen, mit was wir es zu tun haben:
$ (document) .ready -> $ on = 'section' $ ($ on) .css 'background': 'none' border ':' none 'box-shadow': 'none' zurück
Liest nur ein bisschen schöner ohne alle Curlys und Semikolons, nein? CoffeeScript versucht, einige der lästigen Bits in JavaScript zu beseitigen, lässt Sie weniger eingeben, macht den Code ein bisschen lesbarer, bietet eine freundlichere Syntax und erledigt das Schreiben von Klassen angenehmer. Das Definieren von Klassen war für eine Weile ein großes Plus, vor allem für Leute, die aus Ruby stammten und nicht mit reinem JavaScript umgehen wollten. CoffeeScript hat einen ähnlichen Ansatz wie Ruby und gibt Ihnen ein schönes Stück syntaktischen Zucker. Klassen sehen zum Beispiel so aus:
Klasse
Klasse Agent-Konstruktor: (@ erster Name, @ lastName) -> Name: -> "# @ Vorname # @ Nachname" Einführung: (Name) -> "Mein Name ist # @ Nachname, # Name "
Diese Sprache war in Ruby Land eine Zeitlang sehr beliebt. Ich bin nicht sicher, wie die Akzeptanzraten heutzutage sind, aber CoffeeScript ist die Standardeinstellung von JS in Rails. Mit ES6 unterstützt JavaScript jetzt auch Klassen. Ein Grund, vielleicht nicht CoffeeScript zu verwenden und stattdessen mit normalem JS zu spielen. Ich denke, CoffeeScript liest sich immer noch besser, aber viele der weniger kosmetischen Gründe für die Verwendung wurden mit ES6 in diesen Tagen angesprochen. Ich denke, es ist immer noch ein guter Grund, es einmal zu versuchen, aber dafür sind Sie nicht gekommen. Ich wollte Ihnen nur eine weitere Vorspeise geben und ein wenig Kontext erläutern, warum Sie mit der Asset-Pipeline direkt 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 machte es wirklich den Nervenkitzel und war ein ernsthafter Schmerz für die Entwickler. Natürlich funktioniert es immer noch und hat sich als reibungsloses, müheloses Werkzeug etabliert, das die Qualität Ihrer Anwendungen verbessert.
Was mir am meisten gefällt, ist, wie wenig Ärger es mit sich bringt, dass es funktioniert. Versteht mich nicht falsch, Werkzeuge wie Gulp und Grunt sind ebenfalls beeindruckend. Die Möglichkeiten zur Anpassung sind vielfältig. Ich kann das bequeme Gefühl, das Rails mir gibt, wenn ich mich vor dem Start nicht mit irgendwelchen Einstellungen beschäftigen muss, einfach nicht entziehen. Konventionen können mächtig sein, besonders wenn sie nahtlos und unkompliziert sind.
Share
Accentsconagua
