alt hvad du bør vide om Rails Asset Pipeline

Hvad er asset pipeline?

hvis du bygger et Rails-program, har du sikkert hørt om asset pipeline. Aktivrørledningen kan betragtes som de værktøjer og mekanismer, hvormed Javascript-filer, stilark og billeder behandles og forberedes til brug af bro.sereren. Disse processer kan minificere og komprimere aktiver såvel som forbehandlingsaktiver, der er skrevet på andre sprog, såsom Coffeescript eller Sass.

aktivrørledningen blev oprettet for at løse en række problemer relateret til statiske aktiver. Et sådant problem er, at hvert aktiv, der er specificeret separat i HTML-markeringen, skal hentes separat, hvilket resulterer i et højere antal HTTP-anmodninger og i sidste ende en længere belastningstid. Rå Javascript-og CSS-filer kan også spilde en masse båndbredde med kommentarer, ekstra hvidt rum og lange variabelnavne. Et andet problem, der kommer op, involverer caching. Når du f.eks. serverer en Javascript-fil fra din server, cachelagrer bro. sereren automatisk den pågældende fil i en periode. Det forbedrer sideindlæsningstiden, men hvad nu hvis aktivet ændres på et senere tidspunkt? Den vil ikke vide noget om det, så den vil fortsætte med at bruge det cachelagrede aktiv, indtil dets cache-levetid er udløbet. Endelig har sprog som Coffeescript, Sass, Less og Erb gjort det lettere at organisere og skrive Javascript og CSS, men bro.sereren kan ikke fortolke dem direkte, så en forprocessor er nødvendig for at konvertere disse filer til deres passende kolleger, før de sendes til bro. ser.

aktivrørledningen kan i sin velvilje løse alle ovenstående problemer, når de bruges korrekt. Det kan kompilere flere aktiver i en, minify og komprimere aktiver, give fordøjelse af aktiver for at undgå caching problemer, og kan pre-behandle alternative sprog og gøre dem til Javascript og CSS.

dette indlæg dækker en række emner relateret til asset pipeline:

• grundlæggende om, hvordan du bruger aktivrørledningen
• bedste fremgangsmåder til strukturering af, hvor du skal placere dine aktiver
• Sådan bruges prækompileringsarrayet til at specificere, hvilke filer der behandles af aktivrørledningen
• hvordan Sass og Coffeescript kan udnyttes
• Sådan bruges Rails asset helper-metoder, og
• nogle gotchas

grundlæggende brug

der er to grundlæggende måder, hvorpå aktivrørledningen bruges:

1. når du kører en server i udviklingstilstand, forarbejder og forbereder den automatisk dine aktiver on-the-fly.
2. i produktionstilstand vil du sandsynligvis bruge den til at forbehandle, versionisere og komprimere og kompilere dine aktiver. Du kan gøre det ved at køre følgende kommando:

1

bundle exec rake assets:precompile

dette vil oprette (som standard) EN assets mappe i din public/ mappe. Det vil derefter tilføje alle de komprimerede og kompilerede filer i denne mappe, i de relevante formater og med de nye fordøjede versioner. Du kan derefter konfigurere Apache til at servere disse filer direkte, så Rails ikke behøver at levere dem (og køre forbehandlingen on-the-fly osv.) selv.

Husk, at standardindstillingerne kan ændres, så hvis tingene ikke fungerer som forventet, skal du kontrollere din programkonfigurationsfil i config/application.rb. I Rails 4 er aktivhåndtering typisk konfigureret i config/initializers/assets.rb.

filstruktur

det er vigtigt at organisere dine aktiver på en måde, der er forståelig for dig, og letter den eksisterende funktionalitet i aktivrørledningen. Den første ting du bør vide er, at alle dine brugerdefinerede Javascript, stilark og billeder skal gå i app/assets/ mappen. Som standard er der en mappe hver for javascripts, stylesheetsog images. Du kan også tilføje fonts, audios og videos til mappen app/assets/ for disse typer af aktiver. Al tredjeparts kode, du bruger (f.eks.js osv.) skal placeres i vendor/assets/ – mappen:

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 din server automatisk vil servere statiske filer fra public/ – mappen, hvorfor skal ikke alle Javascript -, billed-og stylesheet-aktiver placeres der? For det første vil intet i mappen public blive forbehandlet, kompileret eller komprimeret automatisk, så ved at sætte aktiver der, omgår du helt aktivrørledningen og mister alle fordelene. Når du lægger aktiver der, mister du også muligheden for let at henvise til dem i din Rails-kode. Have en visning, der har følgende kode:

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" />

i det andet scenario (public/images/logo.png) fungerer siden kun, hvis den leveres fra basismappen. Det kan heller ikke drage fordel af aktivrørledningens versionering af filen.

Prækompilering

du spekulerer måske nu på, om alt, hvad du lægger i mappen app/assets/javascripts/, automatisk bliver forkompileret til din app. Heldigvis giver aktivrørledningen en måde at specificere, hvilke filer der er kompileret, og i hvilken rækkefølge. Som standard ansøgning.css og applikation.js (eller deres Sass/coffeescript-ækvivalenter) sammen med alle ikke-Javascript, ikke-CSS-aktiver er inkluderet. At inkludere en anden CSS-eller Javascript-fil end applikation.css og applikation.js, du skal kræve det på en af to måder:

1. føj det til precompile array i config/initializers/assets.rb(Rails 4) eller din programkonfigurationsfil (f.eks. config/application.rb), eller
2. Medtag filen i dit aktivs manifest eller en af dets underfils manifest.

den første mulighed ser sådan ud:

12

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

denne mulighed er bedst for filer, som det giver mening at kun medtage på bestemte sider, og bør ikke medtages på andre. Hvis du f.eks. har en del af din hjemmeside, der vil blive brugt som en integreret iFrame-kontrol, vil du måske kun have widget.js og widget.css eller lignende, der skal bruges på den pågældende side. Disse filer skal tilføjes til precompile array som vist ovenfor.

den anden mulighed er, hvad der skal bruges mest af tiden, og tillader, at dine Javascript-og CSS-filer kompileres til en applikation.js og en ansøgning.css-fil. Manifestet er skrevet øverst på det relevante aktiv.

i coffeescript ser det sådan ud:

12345

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

ovenstående manifest vil omfatte jespersel, Rails jespersel diskret scripting adapter (jespersel_ujs), og alle filerne i det aktuelle træ (dvs. app/assets/javascript/*). Bemærk, at require_tree ikke kompilerer aktiver rekursivt gennem mapper. Hvis du har en mappe med filer, som du vil medtage, skal du også tilføje det til manifestet:

1

#= require_tree ./components

et mere manifest direktiv er require_self, som bruges til at inkludere den aktuelle fils Javascript på det tidspunkt i kæden. Ovenstående, med en require_self kan skrives i en .js fil som følger:

1234567

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

Sass / CSS-manifesterne bruger det samme grundlæggende format, men med den passende kommentarstil:

123456

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

Bemærk, at når du bruger Sass, skal du bruge dens @import – regel for at drage fordel af variabler og blandinger, da hver fil, der er udarbejdet af manifestet, har sit eget omfang.

vær forsigtig med din brug af require_tree direktivet. Aktiver i træet medtages i alfabetisk rækkefølge, hvilket betyder, at hvis en fil, der starter med “a”, afhænger af en fil, der starter med “å”, kan du løbe ind i problemer, hvor de nødvendige stykker ikke er tilgængelige, når Javascript evalueres af bro.sereren. Dette problem kan undgås ved at bruge de relevante jQuery(document).ready() eller window.onload vagter ved at angive en ordre manuelt eller præfiksere filerne med tal som 01_, 02_:

12345

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

Husk, at enhver forudkompileret Javascript-eller CSS-fil kan indeholde et manifest øverst, så du kan bruge undermappernes filer til at forenkle dit manifest på øverste niveau.

Sass og Coffescript og Rails Asset Helpers

jeg har nævnt Sass og Coffeescript lidt i ovenstående afsnit, men jeg har endnu ikke gået ind på, hvad de er. Hvis du allerede er bekendt med dem, er du velkommen til at springe ned til afsnittet “Rails Asset Helpers”.

Sass og Coffeescript

Sass og Coffeescript er sprog, der bruger præprocessorer til at omdanne deres syntaks til henholdsvis CSS og Javascript. Der er flere andre forbehandlede sprog som Typescript og mindre, men Sass og Coffeescript er som standard inkluderet med skinner og er sandsynligvis de mest populære. Jeg vil ikke gå i detaljer her på disse sprog, så tjek linkene ovenfor for mere information.

fra min erfaring, mens Sass og Coffeescript giver en masse syntaktisk sukker (smukke kodefunktioner), er det faktum, at undtagelser kastes for ugyldig kode i forbehandlingsfasen, nok til at berettige at bruge dem. Coffeescript ombryder automatisk din kode per fil og tilføjer var nøgleordet til dine lokale variabler, hvilket forhindrer en masse omfang hovedpine, der kan ske lettere i vanille Javascript.

for eksempel følgende Coffeescript kode:

12345

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

konverteres til følgende Javascript:

1234567891011

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

når forprocessoren behandler filen, indpakker den automatisk koden i en anonym funktion ((function() {}).call(this)) og tilføjer nøgleordet vartil den første brug af state. Bemærk, at hvis du vil bruge det globale omfang, skal du angive det ved at angive window..

der er meget mere at Coffeescript, men den automatiske scoping har været yderst nyttig for mig personligt for at forhindre svære at finde fejl.

Rails Asset Helpers

en anden fantastisk funktion, som du kun kan få ved at bruge Sass i dit Rails-projekt, er Asset path helpers. Når du henviser til andre aktiver i din Sass, kan du bruge følgende syntaks til at få de relevante stier:

123

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

hjælperne image-path, asset-url og asset-path kan også bruges. De -urlhjælpere ombryde stien med url().

Erb i aktiver

asset pipeline giver dig mulighed for at evaluere ERB-kode i dine CSS-og Javascript-aktiver ved at suffiks filnavnet med .ERB (f. eks. application.js.erb eller application.scss.erb). Selvom dette kan være nyttigt til at tilføje aktivstier til dit Javascript, anbefaler jeg i det store og hele ikke at bruge denne funktion. Det tilføjer endnu et forbehandlingstrin til filen og øger dermed den tid, det tager at prækompilere. Det kan også føre til dårlige vaner. Du kan blive fristet til at tilføje kode, der ikke giver mening på kompileringstidspunktet, som at oversætte strenge. Disse strenge ville kun blive oversat på kompileringstidspunktet og dermed negere hele formålet med at oversætte dem. Den eneste grund til at bruge Erb i en Javascript-fil bør være at bruge asset_path hjælperen som diskuteret i vejledningen.

Asset Pipeline Gotchas

følgende er nogle gotchas og godbidder, der kan være nyttige i udviklingen af din Rails applikations aktiver.

• Hvordan tilføjer jeg globale data til min Javascript til brug?
  • gon gem kan bruges til at indsætte globalt scoped data til siden for din Javascript til at forbruge. Dette er fantastisk til ting som at give den aktuelle brugers ID eller sideindstillinger.
• hvor skal jeg udvide precompile array?
  • i Rails 4 skal du udvide arrayet i config/initializers/assets.rb, og i Rails 3 skal du gøre det i config/application.rb. Brug af aktiver.rb eller ansøgning.rb indstiller precompile array for alle miljøer, så hvis du tilføjer et miljø (måske staging), behøver du ikke at udvide precompile array specifikt til det nye miljø.
    • aktiver.rb: Rails.application.config.assets.precompile += %w( widget.css widget.js )
    • ansøgning.rb: config.assets.precompile += %w( widget.js widget.css )
• Hvornår skal jeg forudkompilere aktiver separat ved at udvide prækompileringsarrayet?
  • dette bør sjældent gøres. Det meste af tiden er den eneste grund til, at du vil gøre dette, hvis aktivet er inkluderet alene på en speciel side, hvor du ikke vil have resten af aktiverne, f.eks. Brug din ansøgning.js og ansøgning.css manifesterer at trække i dine aktiver.
• skal jeg tillade Rails at tjene statiske filer?
  • Ja. Dette følger de tolv-faktor app retningslinjer og forhindrer fejl, hvis du har glemt at medtage en fil i precompile array, eller hvis du har glemt at precompile.
  • sæt config.serve_static_assets = true i Skinner 3 og config.serve_static_files = true i Skinner 4.
• Hvordan kan jeg sikre, at min Javascript / CSS er velskrevet?
  • at skrive Javascript og CSS af høj kvalitet (eller Coffeescript og Sass) kan tage meget tid og erfaring, men en ting, der i høj grad har hjulpet mig, er at bruge en linter). Nogle ide ‘ er, såsom Sublim tekst, har plugins, der integrerer linters. Jeg bruger personligt SublimeLinter-pakken. Hvis du vil skrive almindeligt gammelt Javascript og CSS, skal du bestemt bruge en linter.
• Hvordan ændrer jeg den mappe, hvor mine forudkompilerede aktiver er placeret?
  • du kan ændre indstillingen config.asset.prefixtil en anden mappe, f.eks. /static.
  • Skift aktivpræfikset i development.rb, hvis du vil spore forudkompilerede aktiver i git til produktionsbrug.
  • Skift aktivpræfikset globalt, hvis du vil bruge /assets path namespace til dine controllere.
• Hvordan tjener jeg statiske aktiver med ?
  • det grundlæggende nginksdirektiv skal se sådan ud (se afsnittet Prækompileringsaktiver i Skinnevejledningen for mere information):

1234567

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

• Hvad er manifest.yml eller manifest -.json?
  • manifestet.yml (skinner 3) eller manifest-.JSON (Rails 4) filer oprettes automatisk, når du forudkompilerer dine aktiver med rake assets:precompile. De indeholder oplysninger om, hvilke filer der skal bruges af din app.
• hvilke typer filer skal ikke medtages i aktivpipelinen?
  • du vil normalt beholde store filer (videoer, et stort antal PDF-overførsler osv.) i et separat arkiv eller i en cloud-Filhåndtering, f.eks. Filerne kan derefter refereres fra din app, men behøver ikke at mose ned din git repository.
• Hvordan kan jeg få mine Rails 3 aktiver til at kompilere hurtigere?
  • brug turbo-sprockets-rails3 gem.
• kan jeg bruge et CDN (content delivery netværk) til mine aktiver?
  • Ja! Fordøjelsen eller fingeraftrykket, der er suffikset på hvert aktiv, får dem til at fungere godt med CDN ‘ er. Indstil dit CDN til at betjene aktiver fra din Rails-app, og indstil derefter config.action_controller.asset_host – konfigurationen til det relevante domæne for dit CDN (f.eks. config.action_controller.asset_host = 'mycdn.fictional-cdn.com'). Jeg anbefaler at bruge miljøvariabler til at indstille dette: config.action_controller.asset_host = ENV.

indpakning af det

brug af asset pipeline korrekt kan forbedre den samlede kvalitet af din applikation med hensyn til ydeevne, modstandsdygtighed og koderenhed. Ved at bruge asset pipeline ‘ s funktioner kan du automatisk overvinde nogle af de største problemer i forbindelse med kodning og levering af statiske aktiver.