I denne første artikkelen av en ny serie på Asset Pipeline in Rails vil jeg diskutere noen konsepter på høyt nivå som er nyttige for å forstå hva Asset Pipeline har å tilby, og hva det gjør under hetten. De viktigste tingene du klarer for deg, er sammenkobling, reduksjon og forbehandling av eiendeler. Som nybegynner må du gjøre deg kjent med disse begrepene så tidlig som mulig.
emner
Asset Pipeline?
Organisasjon
Sammenkobling og komprimering?
Høyt nivå språk
Asset Pipeline?
Asset pipeline er ikke akkurat nyheter til folk i virksomheten, men for nybegynnere kan det være litt vanskelig å finne ut raskt. Utviklere bruker ikke akkurat massevis av tid på front-end ting, spesielt når de starter. De er opptatt med mange bevegelige deler som ikke har noe å gjøre med HTML, CSS eller de ofte baserte JS-bitene.
Asset pipeline kan hjelpe ved å administrere sammenkobling, reduksjon og forhåndsbehandling av eiendeler, for eksempel eiendeler som er skrevet på høyt nivå språk som CoffeeScript eller Sass.
Dette er et viktig skritt i byggeprosessen for Rails apps. Asset pipeline kan gi deg et løft ikke bare i kvalitet og hastighet, men også i bekvemmelighet. Å måtte sette opp eget skreddersydd byggverktøy kan gi deg noen flere muligheter for å finjustere dine behov, men det kommer med en overhead som kan være tidkrevende for nybegynnere, kanskje til og med skremmende. I denne forbindelse kan vi snakke om Asset Pipeline som en løsning som fremmer bekvemmelighet over konfigurasjon.
Den andre tingen som ikke bør undervurderes er organisasjon. Rørledningen gir et solid rammeverk for å plassere eiendeler. På mindre prosjekter kan dette ikke virke så viktig, men større prosjekter kan ikke komme seg lett fra å gå i feil retning på emner som dette. Dette er kanskje ikke det vanligste eksemplet i verden, men bare forestille deg et prosjekt som Facebook eller Twitter med dårlig organisasjon for sine CSS- og JS-eiendeler. Ikke så vanskelig å forestille seg at dette ville oppdype problemer og at folk som må jobbe og bygge på et slikt grunnlag, ikke ville ha en enkel tid å elske jobbene sine.
Som med mange ting i Rails, er det en konvensjonell tilnærming til hvordan man skal håndtere eiendeler. Dette gjør det lettere å ombord på nye mennesker og for å unngå at utviklere og designere blir for besatt av å bringe egen deig til festen.
Når du går med i et nytt lag, vil du være i stand til å komme raskt opp og slå bakken i gang. Trenger å finne ut den spesielle sausen av hvordan andre organiserte sine eiendeler, er ikke akkurat nyttig med det. I ekstreme tilfeller kan dette til og med betraktes som avfall og kan brenne penger unødvendig. Men la oss ikke bli for dramatiske her.
Så denne artikkelen er for nybegynnere blant dere, og jeg anbefaler at du tar en titt på rørledningen med en gang og får et godt grep om dette emnet, selv om du ikke forventer å jobbe med markup eller front-end ting mye i fremtiden . Det er et viktig aspekt i Rails og ikke så stor av en avtale. Pluss lagmedlemmene dine, spesielt designere som tilbringer halvparten av deres liv i disse katalogene, vil legge mindre morsomme ting i kaffen din hvis du har noe felles grunnlag som ikke er i konflikt med hverandre.
Organisasjon
Du har tre alternativer for å plassere dine eiendeler. Disse divisjonene er mer av en logisk type. De representerer ikke noen tekniske begrensninger eller begrensninger. Du kan plassere eiendeler i noen av dem og se de samme resultatene. Men for en smartere organisasjon, bør du ha en god grunn til å plassere innhold på riktig sted.
De app / eiendeler mappen er for eiendeler som er spesifikt for disse app-bildene, JS og CSS-filene som er skreddersydd for et bestemt prosjekt.
lib / eiendeler
lib / assets /
De lib / eiendeler mappe derimot er hjemmet til din egen kode som du kan gjenbruke fra prosjekt til prosjekt-ting som du selv kan ha hentet ut og ønsker å ta fra ett prosjekt til de neste spesifikt, eiendeler som du kan dele mellom programmer.
leverandør / eiendeler er et annet skritt utover. Det er hjemmet for eiendeler som du gjenbrukte fra andre eksterne kilder-plugins og rammer fra tredjeparter.
Dette er de tre stedene hvor Sprockets vil se etter eiendeler. Innenfor de ovennevnte katalogene forventes det å plassere eiendeler i /Bilder, / stilark og / javascripts mapper. Men dette er mer av en konvensjonell ting; eventuelle eiendeler innenfor */eiendeler mapper vil bli krysset. Du kan også legge til underkataloger etter behov. Rails vil ikke klage og forkompilere filene deres uansett.
Det er en enkel måte å ta en titt på søkebanen til aktivrørledningen. Når du brenner opp en Rails konsoll med skinner konsoll, du kan inspisere den med følgende kommando:
Terminal
Rails.application.config.assets.paths
Det du vil få tilbake er en matrise med alle katalogene over eiendeler som er tilgjengelige og funnet av Sprockets-aka søkebanen.
Den fine tingen om alt dette er lett å gå glipp av. Det er aspektet ved å ha konvensjoner. Det betyr at utviklere og designere også, faktisk - alle kan ha visse forventninger om hvor de skal lete etter filer og hvor de skal plasseres. Det kan være en stor (Trump voice) tidsbesparende. Når noen nye blir med i et prosjekt, har de en god ide om å navigere et prosjekt med en gang.
Det er ikke bare praktisk, men kan også forhindre tvilsomme ideer eller gjenoppfinne hjulet hele tiden. Ja, konvensjon over konfigurasjon kan høres litt kjedelig til tider, men det er likevel kraftige ting. Det holder oss fokusert på det som betyr noe: selve arbeidet og godt teamsamarbeid.
Eiendomsbanene nevnt er imidlertid ikke satt i stein. Du kan også legge til tilpassede baner. Åpen config / application.rb og legg til egendefinerte baner som du vil gjenkjenne av Rails. La oss ta en titt på hvordan vi ville legge til en custom_folder.
config.application.rb
modul TestApp klasse Søknad < Rails::Application config.assets.paths << Rails.root.join("custom_folder") end end
Når du nå sjekker søkebanen igjen, vil du finne at din egendefinerte mappe er en del av søkebanen for aktivrørledningen. Forresten vil det nå være det siste objektet som er plassert i arrayet:
Hvorfor trenger vi det? Lang historie kort, du vil at appene dine skal lastes raskere. Periode! Alt som hjelper med det er velkommen. Selvfølgelig kan du komme seg uten å optimere for det, men det har for mange fordeler man ikke kan ignorere. Komprimering av filstørrelser og sammenkobling av flere aktivfiler til en enkelt "master" -fil som lastes ned av en klient som en nettleser, er heller ikke så mye arbeid. Det håndteres for det meste av rørledningen uansett.
Redusering av antall forespørsler om gjengivelse av sider er svært effektiv for å øke hastigheten. I stedet for å ha kanskje 10, 20, 50 eller uansett antall forespørsler før nettleseren er ferdig med å få dine eiendeler, kan du potensielt bare ha en for hvert CSS og JS-aktiv. I dag er dette en fin ting å ha, men på et tidspunkt var dette en spilleskifter. Disse forbedringene i webutvikling bør ikke overses fordi vi arbeider med millisekunder som en enhet.
Mange forespørsler kan legge opp ganske vesentlig. Og tross alt er brukeropplevelsen det som betyr mest for vellykkede prosjekter. Å la brukerne vente på bare den lille ekstra biten før de kan se innhold gjengitt på siden din, kan være en enorm avtale-breaker. Tålmodighet er ikke noe vi kan forvente av våre brukere.
Minifisering er kult fordi det blir i ferd med å unnvike unødvendige ting i filene dine - hvite plass og kommentarer, i utgangspunktet. Disse komprimerte filene er ikke laget med menneskelig lesbarhet i tankene. De er rent for maskinforbruk. Filene vil ende opp med å se litt kryptisk og vanskelig å lese, selv om det fortsatt er alle gyldige CSS- og JS-koden-bare uten overskytende mellomrom for å gjøre det lesbart og forståelig for mennesker.
JS-kompresjonen er litt mer involvert, skjønt. Nettlesere trenger ikke den formateringen. Det lar oss optimalisere disse eiendelene. Takeaway-problemet fra dette avsnittet er at en redusert mengde forespørsler og minimerte filstørrelser gir fart på tingene og bør være i vesken din. Rails gir deg denne funksjonaliteten ut av boksen uten ytterligere oppsett.
Høyt nivå språk
Du har kanskje allerede hørt om dem, men som en nybegynner kan du ikke være raskere på hvorfor du bør lære enda et språk - spesielt hvis du fortsatt er opptatt av å lære å skrive klassisk HTML og CSS. Disse språkene ble opprettet for å håndtere mangler som utviklere ønsket å stryke ut. De behandler for det meste problemer som utviklere ikke ønsker å håndtere hver dag. Klassisk latskapsdrevet utvikling, antar jeg.
"Høyt språk" lyder mer fancy enn det kan være - de er rad, skjønt. Vi snakker om Sass, CoffeeScript, Haml, Slim, Jade, og slike ting. Disse språkene lar oss skrive i en (for det meste) brukervennlig syntaks som kan være mer praktisk og effektiv å jobbe med. Alle av dem må være forkompilert under en byggeprosess.
Jeg nevner dette fordi dette kan skje bak kulissene uten at du merker det. Det betyr at det tar disse eiendelene og forvandler dem til CSS, HTML og JS før de distribueres og kan gjengis av nettleseren.
sass
Sass står for "Syntactically Awesome Style Sheets" og er mye sterkere enn rent CSS. Det lar oss skrive smartere stilark som har noen programmeringsverktøy bakket inn. Hva snakker vi om her, akkurat? Du kan erklære variabler, nestregler, skrivefunksjoner, lage mikser, enkelt importere deler, og mange andre ting som programmerere ønsket å ha tilgjengelig mens de spilte med stiler.
Det har vokst til et ganske rikt verktøy nå og er utmerket for å organisere stilark - for store prosjekter, ville jeg til og med kalle det avgjørende. I disse dager er jeg ikke sikker på om jeg ikke ville holde seg borte fra en stor app som ikke bruker et verktøy som Sass-eller hva ikke-Ruby sentriske rammeverk har å tilby i den forbindelse.
For din nåværende bekymring, er det to syntaksversjoner av Sass du trenger å vite om. Den Sassy CSS versjonen, aka SCSS, er den bredere adopterte. Den holder seg nærmere vanlig CSS, men tilbyr alle de fancy utvidelsene utviklere og designere kom til å elske å leke med stilark. Den bruker .SCSS filtillegg og ser slik ut:
Visuelt er det ikke så annerledes enn CSS-det er derfor det er det mer populære valget, spesielt blant designere jeg tror. En av de veldig kule og praktiske aspektene av SCSS, og Sass generelt, er det nestende aspektet. Dette er en effektiv strategi for å lage lesbare stiler, men også kutt ned mye på gjentatte deklarasjoner.
Den innrykkede Sass-syntaksen har .sass filutvidelse. Denne lar deg unngå å håndtere alle disse dumme, krøllete bøylene og semikolonene som latne devs liker å unngå.
Hvordan gjør det det? Uten beslagene bruker Sass innrykk, hovedsakelig mellomrom, for å skille sine egenskaper. Det er ganske rad og ser veldig kul ut. For å se forskjellene, viser jeg begge versjoner side ved side.
.sass
#main farge: blå skriftstørrelse: 0.3em en skrift: vekt: fet familie: serif &: svever bakgrunnsfarge: #eee
Ganske fin og kompakt, va? Men begge versjoner trenger behandling før det blir til gyldig CSS som nettlesere kan forstå. Asset pipeline tar vare på det for deg. Hvis du treffer nettlesere med noe som Sass, ville de ikke ane hva som skjer.
Jeg personlig foretrekker den innrykkede syntaksen. Denne gjennomsiktige Sass-syntaksen er mindre populær enn SCSS-syntaksen, noe som kanskje ikke gjør det til et ideelt valg for andre prosjekter enn dine personlige. Det er sannsynligvis en god ide å gå med det mest populære valget blant teamet ditt, spesielt med involverte designere. Håndheve hvite romhøfthet med folk som har tilbrakt år å tømme alle de krøllete bøylene og semikolonene der ute, virker som en dårlig ide.
Begge versjonene har de samme programmerings triksene opp i ermene. De er gode i å gjøre prosessen med å skrive stiler mye mer behagelig og effektiv. Det er heldig for oss at Rails og Asset Pipeline gjør det så enkelt å jobbe med noen av disse - ganske mye ute av esken.
Slim & Haml
Lignende argumenter kan gjøres om fordelene ved å bruke noe som Slim og Haml. De er ganske praktiske for å skape mer kompakt oppretting. Det blir samlet inn i gyldig HTML, men filene du behandler er mye mer redusert.
Du kan spare deg selv med å skrive lukkekoder og bruke kule forkortelser for tagnavn og lignende. Disse kortere bruddene på markering er lettere å skumme og lese. Personlig har jeg aldri vært en stor fan av Haml, men Slim er ikke bare fancy og praktisk, det er også veldig smart. For folk som liker den innrykkte Sass-syntaksen, vil jeg definitivt anbefale å spille med det. La oss få en rask titt:
Slank
#content .left.column h2 Velkommen til vårt nettsted! p = print_information .right.column = render: partial => "sidebar"
Haml
#content .left.column% h2 Velkommen til vårt nettsted! % p = print_information .right.column = render: partial => "sidebar"
Begge resulterer i følgende ERB-forbedret HTML i Rails:
Velkommen til vårt nettsted!
<%= print_information %>
<%= render :partial => "sidebar"%>
På overflaten er forskjellene ikke så store, men jeg fikk aldri helt hvorfor Haml vil at jeg skal skrive alle disse ekstra % å prepend merker. Slim fant en løsning som ble kvitt disse, og derfor hilser jeg laget! Ikke en stor smerte, men en irriterende likevel. De andre forskjellene er under hetten og er ikke innenfor rammen av dette stykket i dag. Ville bare gjette appetitten din.
Som du kan se, reduserer begge preprosessorer betydelig mengden du trenger å skrive. Ja, du må lære et annet språk, og det leser litt rart først. Samtidig føler jeg fjerningen av at mye rot er helt verdt det. Også, når du vet hvordan du skriver ERB-flavored HTML, vil du kunne hente noen av disse preprosessorene ganske raskt. Ingen rakettvitenskap - det samme gjelder for Sass, forresten.
Hvis du er interessert, er det to praktiske edelstener for å bruke en av dem i Rails. Gjør deg selv en tjeneste og sjekk dem ut når du blir lei av å skrive alle disse kjedelige åpnings- og lukkekodene.
perle "slank-skinner" perle "haml-skinner"
CoffeeScript
CoffeeScript er et programmeringsspråk som alle andre, men det har den Ruby-smaken for å skrive JavaScript. Gjennom preprocessing, kompilerer den inn i ren gammel JavaScript som nettlesere kan håndtere. Det korte argumentet for å jobbe med CoffeeScript var at det bidro til å overvinne noen mangler som JS hadde med seg. Dokumentasjonen sier at den tar sikte på å avsløre "gode deler av JavaScript på en enkel måte". Greit nok! Leter deg raskt til et kort eksempel og se hva vi har å gjøre med:
$ (dokument) .ready -> $ on = 'section' $ ($ on) .css 'bakgrunn': 'ingen' grense ':' ingen 'boks-skygge': 'ingen' tilbake
Leser bare litt finere uten alle curlies og semikolonene, nei? CoffeeScript prøver å ta vare på noen av de irriterende brikkene i JavaScript, lar deg skrive mindre, gjør koden litt mer lesbar, gir en vennligere syntaks, og behandler mer behagelig med skriveklasser. Definere klasser var et stort pluss for en stund, spesielt for folk som kommer fra Ruby, som ikke var veldig glad i å håndtere ren JavaScript. CoffeeScript tok en lignende tilnærming til Ruby og gir deg et fint stykke syntaktisk sukker. Klasser ser slik ut, for eksempel:
Klasse
klassen Agentkonstruktor: (@firstName, @lastName) -> navn: -> "# @ first_name # @ last_name" introduksjon: (navn) -> "Mitt navn er # @ last_name, # name "
Dette språket var ganske populært i Ruby land for en stund. Jeg er ikke sikker på hvordan adopsjonsraten er i disse dager, men CoffeeScript er standard JS-smaken i Rails. Med ES6 støtter JavaScript nå også klasser - en stor grunn til kanskje ikke å bruke CoffeeScript og spill med vanlig JS i stedet. Jeg tror CoffeeScript fortsatt leser bedre, men mange mindre kosmetiske grunner til å bruke den har blitt tatt opp med ES6 i disse dager. Jeg tror det er fortsatt en god grunn til å gi det et skudd, men det er ikke det du kom for her. Jeg ville bare gi deg en annen forrett og gi litt kontekst rundt hvorfor Asset Pipeline lar deg jobbe i CoffeeScript ut av esken.
Siste tanker
Asset pipeline har bevist seg langt utover forventningen min da den ble introdusert. På det tidspunktet gjorde det virkelig skvett og tok alvorlig smerte for utviklere. Det gjør det selvsagt, og har etablert seg som et friksjonsløst, uanstrengt verktøy som forbedrer kvaliteten på applikasjonene dine.
Det jeg liker mest om det er hvor lite problem det innebærer å få det til å fungere. Ikke ta meg feil, verktøy som Gulp og Grunt er også imponerende. Alternativene for tilpasning er mange. Jeg kan bare ikke riste den behagelige følelsen som Rails gir meg når jeg ikke trenger å gjøre noe med noen oppsett før jeg begynner. Konvensjoner kan være kraftige, spesielt vassle, de resulterer i noe sømløst og problemfritt.
Share
Accentsconagua
