I den här första artikeln i en ny serie på Asset Pipeline in Rails vill jag diskutera några högkoncept som är praktiska för att fullt ut förstå vad Asset Pipeline har att erbjuda och vad det gör under huven. De viktigaste sakerna som man hanterar för dig är sammandragning, minifiering och förbehandling av tillgångar. Som nybörjare måste du bekanta dig med dessa begrepp så tidigt som möjligt.
ämnen
Asset Pipeline?
Organisation
Sammanställning och kompression?
Hög nivå språk
Asset Pipeline?
Asset Pipeline är inte exakt nyheter för personer i branschen, men för nybörjare kan det vara lite knepigt att räkna ut snabbt. Utvecklare spenderar inte mycket tid på front-end saker, särskilt när de börjar. De är upptagna med många rörliga delar som inte har något att göra med HTML, CSS eller de ofta baserade JS-bitarna.
Asset Pipeline kan hjälpa till genom att hantera sammanlänkning, minifiering och förbehandling av tillgångar, till exempel tillgångar som skrivs på högnivå språk som CoffeeScript eller Sass.
Detta är ett viktigt steg i byggprocessen för Rails-appar. Asset Pipeline kan ge dig en boost inte bara i kvalitet och hastighet utan även i bekvämlighet. Att behöva skapa ett eget skräddarsytt byggverktyg kan ge dig några fler alternativ för att finjustera dina behov, men det kommer med en kostnad som kan vara tidskrävande för nybörjare, kanske till och med skrämmande. I detta avseende kan vi prata om Asset Pipeline som en lösning som främjar bekvämligheten över konfigurationen.
Den andra sak som inte bör underskattas är organisation. Rörledningen erbjuder en solid ram för att placera dina tillgångar. På mindre projekt kanske det inte verkar så viktigt, men större projekt kanske inte återhämtar sig lätt från att gå i fel riktning på ämnen som detta. Detta kanske inte är det vanligaste exemplet i världen, men föreställ dig bara ett projekt som Facebook eller Twitter med dålig organisation för sina CSS- och JS-tillgångar. Inte så svårt att föreställa sig att detta skulle uppstå problem och att människor som måste arbeta och bygga på en sådan grund inte skulle ha en lätt tid att älska sina jobb.
Som med många saker i Rails finns det ett konventionellt tillvägagångssätt för hur man hanterar tillgångar. Detta gör det lättare att ombord på nya människor och för att undvika att utvecklare och designers blir för besatta av att föra sin egen deg till festen.
När du går med i ett nytt lag vill du snabbt kunna snabba och slå marken. Att behöva räkna ut den speciella såsen av hur andra människor organiserade sina tillgångar är inte precis till hjälp med det. I extrema fall kan detta även betraktas som slöseri och kan bränna pengar i onödan. Men låt oss inte bli alltför dramatiska här.
Så den här artikeln är för nybörjare bland dig, och jag rekommenderar att du tar en titt på pipelinen direkt och får ett bra grepp om det här ämnet, även om du inte förväntar dig att arbeta på markup eller front-endiga saker mycket i framtiden . Det är en viktig aspekt i Rails och inte så stor av en affär. Plus dina lagmedlemmar, speciellt designers som tillbringar hälften av sina liv i dessa kataloger, kommer att lägga mindre roliga saker i ditt kaffe om du har en gemensam mark som inte strider mot varandra.
Organisation
Du har tre alternativ för att placera dina tillgångar. Dessa uppdelningar är mer av en logisk typ. De representerar inte några tekniska begränsningar eller begränsningar. Du kan placera tillgångar i någon av dem och se samma resultat. Men för smartare organisation borde du ha en bra anledning att placera innehåll på rätt plats.
De app / tillgångar mappen är för tillgångar som är specifika för dessa app-bilder, JS och CSS-filer som skräddarsys för ett visst projekt.
lib / tillgångar
lib / tillgångar /
De lib / tillgångar mapp är å andra sidan hemmet för din egen kod som du kan återanvända från projekt till projekt-saker som du själv kan ha extraherat och vill ta från ett projekt till nästa specifikt tillgångar som du kan dela mellan program.
försäljaren / tillgångar är ett annat steg utåt. Det är hemmet för tillgångar som du återanvändit från andra externa källor-plugins och ramar från tredje part.
Det här är de tre platser där Sprockets kommer att leta efter tillgångar. Inom ovanstående kataloger förväntas du placera dina tillgångar inom /bilder, / formatmallar och / javascripts mappar. Men det här är mer av en konventionell sak; eventuella tillgångar inom */tillgångar mappar kommer att korsas. Du kan också lägga till underkataloger efter behov. Rails kommer inte att klaga och förkompilera sina filer ändå.
Det finns ett enkelt sätt att titta på sökvägen för tillgångsrörledningen. När du slår upp en Rails-konsol med rails konsolen, du kan inspektera det med följande kommando:
Terminal
Rails.application.config.assets.paths
Vad du kommer att få tillbaka är en uppsättning med alla kataloger över tillgångar som är tillgängliga och hittas av Sprockets-aka sökvägen.
Det trevliga med allt detta är lätt att missa. Det är aspekten av att ha konventioner. Det betyder att även utvecklare och designare, faktiskt, kan alla ha vissa förväntningar om var man ska leta efter filer och var de ska placera dem. Det kan vara en stor (Trump Voice) tidsbesparare. När någon ny går med ett projekt, har de en bra idé hur man navigerar ett projekt direkt.
Det är inte bara bekvämt, men kan också förhindra tvivelaktiga idéer eller återuppfinna hjulet hela tiden. Ja, konventet över konfigurationen kan låta lite tråkigt ibland, men det är ändå kraftfulla saker. Det håller oss fokuserade på det som är viktigt: själva arbetet och bra teamsamarbete.
De angivna tillgångarnas vägar är dock inte i sten. Du kan också lägga till anpassade sökvägar. Öppna config / application.rb och lägg till anpassade vägar som du vill känna igen av Rails. Låt oss ta en titt på hur vi skulle lägga till en custom_folder.
config.application.rb
modul TestApp klass Application < Rails::Application config.assets.paths << Rails.root.join("custom_folder") end end
När du nu kontrollerar sökvägen igen hittar du din anpassade mapp som en del av sökvägen för tillgångsrörledningen. Förresten kommer det nu att vara det sista objektet i arrayen:
Varför behöver vi det där? Lång historia kort, du vill att dina appar ska ladda snabbare. Period! Allt som hjälper till med det är välkommen. Naturligtvis kan du komma undan utan att optimera för det, men det har för många fördelar som man helt enkelt inte kan ignorera. Komprimera filstorlekar och sammanfoga flera aktiva filer till en enda "master" -fil som laddas ned av en klient som en webbläsare, är inte så mycket arbete. Det hanteras mestadels av rörledningen.
Att minska antalet förfrågningar om att göra sidor är mycket effektivt för att påskynda saker. Istället för att ha kanske 10, 20, 50 eller vad som helst antal förfrågningar innan webbläsaren är klar med att få dina tillgångar, kan du eventuellt bara ha en för varje CSS och JS-tillgång. Idag är det här en bra sak att ha, men någon gång var det en spelväxlare. Sådana förbättringar i webbutveckling bör inte försummas eftersom vi arbetar med millisekunder som en enhet.
Massor av förfrågningar kan lägga upp ganska väsentligt. Och trots allt är användarupplevelsen det som är mest viktigt för framgångsrika projekt. Att få användarna att vänta på just den lilla extrabiten innan de kan se innehåll som gjorts på din sida kan vara en enorm affärsavbrott. Tålamod är inte något vi kan förvänta oss av våra användare.
Minifiering är cool eftersom det blir i princip borta onödiga saker i dina filer-whitespace och kommentarer, i grund och botten. Dessa komprimerade filer är inte gjorda med mänsklig läsbarhet i åtanke. De är endast avsedda för maskinförbrukning. Filerna kommer till slut att se lite kryptiska och svåra att läsa även om det fortfarande är alla giltiga CSS- och JS-kodar - bara utan överskott av blankutrymme för att göra den läsbar och förståelig för människor.
JS-komprimeringen är dock lite mer involverad. Webbläsare behöver inte den formateringen. Det gör att vi kan optimera dessa tillgångar. Takeaway-problemet från det här avsnittet är att en minskad mängd begäranden och minimerade filstorlekar snabbar upp saker och bör vara i din väska med tricks. Rails ger dig den här funktionen ur lådan utan ytterligare inställningar.
Hög nivå språk
Du kanske har hört talas om dem redan, men som nybörjare kanske du inte snabbare på varför du borde lära dig ännu ett språk - speciellt om du fortfarande är upptagen med att lära dig att skriva klassisk HTML och CSS. Dessa språk skapades för att hantera brister som utvecklare ville stryka ut. De hanterar mestadels problem som utvecklare inte vill hantera dagligen. Klassisk latskapsdriven utveckling, antar jag.
"Högnivå språk" låter mer snyggt än det kan vara-de är rad. Vi pratar om Sass, CoffeeScript, Haml, Slim, Jade och sådant. Dessa språk låter oss skriva i en (mestadels) användarvänlig syntax som kan vara mer bekväm och effektiv att arbeta med. Alla måste förkompileras under en byggprocess.
Jag nämner detta eftersom detta kan hända bakom kulisserna utan att du märker det. Det betyder att det tar dessa tillgångar och omvandlar dem till CSS, HTML och JS innan de distribueras och kan göras av webbläsaren.
sass
Sass står för "Syntactically Awesome Style Sheets" och är mycket mer potent än ren CSS. Det låter oss skriva smartare stilark som har några programmeringsverktyg bakade in. Vad pratar vi om här, exakt? Du kan deklarera variabler, boetregler, skrivfunktioner, skapa mixins, enkelt importera partier och många andra saker som programmerare ville ha tillgång till medan du spelar med stilar.
Det har vuxit till ett ganska rikt verktyg redan nu och är utmärkt för att organisera stylesheets-för stora projekt skulle jag även kalla det nödvändigt. Dessa dagar är jag inte säker på om jag inte skulle hålla sig borta från en stor app som inte använder ett verktyg som Sass-eller vad som inte är Ruby centriska ramverk har att erbjuda i det avseendet.
För dina aktuella problem finns det två syntaxversioner av Sass du behöver veta om. Sassy CSS-versionen, aka SCSS, är den mer allmänt antagna. Den ligger närmare vanlig CSS, men erbjuder alla de fina tilläggen som utvecklare och designers kom att älska att leka med stylesheets. Den använder .SCSS filtillägg och ser så här ut:
Visuellt är det inte så annorlunda än CSS-det är därför det är det mer populära valet, särskilt bland designers tycker jag. En av de riktigt coola och praktiska aspekterna av SCSS och Sass i allmänhet är den nestande aspekten. Det här är en effektiv strategi för att skapa läsbara stilar, men skär ner också mycket på repetitiva deklarationer.
Den indragna Sass-syntaxen har .sass filtillägg. Den här låter dig undvika att hantera alla dessa dumma, krulliga hängslen och semikolon som lata devs gillar att undvika.
Hur gör det så? Utan parentes använder Sass inryckningar, i stort utrymme för att skilja sina egenskaper. Det är ganska rad och ser riktigt coolt ut. För att se skillnaderna visar jag båda versionerna sida vid sida.
Ganska trevligt och kompakt, va? Men båda versionerna behöver bearbetas innan det blir en giltig CSS som webbläsare kan förstå. Asset Pipeline tar hand om det för dig. Om du träffar webbläsare med något som Sass, skulle de inte ana vad som händer.
Jag föredrar personligen den indragna syntaxen. Den här mellanslagskänsliga Sass-syntaxen är mindre populär än SCSS-syntaxen, vilket kanske inte gör det till ett idealiskt val för andra projekt än dina personliga. Det är nog en bra idé att gå med det mest populära valet bland ditt lag, särskilt med inblandade designers. Fördjupa whitespace hipness med människor som har spenderat år tömmar alla de lockiga hängslen och semikolon där ute verkar som en dålig idé.
Båda versionerna har samma programmeringstrummar upp sina ärmar. De är utmärkta för att göra processen med att skriva stilar mycket trevligare och effektivare. Det har tur för oss att Rails och Asset Pipeline gör det så lätt att arbeta med någon av dessa - ganska mycket ur lådan.
Slim & Haml
Liknande argument kan göras om fördelarna med att använda något som Slim och Haml. De är ganska praktiska för att skapa mer kompakt markup. Den kommer att kompileras till giltig HTML, men filerna du hanterar är mycket mer reducerade.
Du kan spara dig själv besväret med att skriva stängningskoder och använda fina förkortningar för taggnamn och liknande. Dessa kortare utbrott av markup är lättare att skumma och läsa. Personligen har jag aldrig varit en stor fan av Haml, men Slim är inte bara snyggt och bekvämt, det är också väldigt smart. För personer som gillar den indragna Sass-syntaxen, skulle jag definitivt rekommendera att spela med det. Låt oss ta en snabb titt:
Smal
#content .left.column h2 Välkommen till vår hemsida! p = print_information .right.column = render: partial => "sidebar"
HAML
#content .left.column% h2 Välkommen till vår hemsida! % p = print_information .right.column = render: partial => "sidebar"
Båda resulterar i följande ERB-förbättrade HTML i Rails:
Välkommen till vår sida!
<%= print_information %>
<%= render :partial => "sidobar"%>
På ytan är skillnaderna inte så stora, men jag fick aldrig riktigt varför Haml vill att jag ska skriva alla dessa extra % att förordna taggar. Slim hittade en lösning som blev av med dessa, och därför hälsar jag laget! Inte en stor smärta, men en irriterande men ändå. De andra skillnaderna ligger under huven och ligger inte inom ramen för denna del idag. Ville bara bota din aptit.
Som du kan se, minskar båda förprocessorerna betydligt det belopp du behöver skriva. Ja, du måste lära dig ett annat språk, och det läser lite konstigt först. Samtidigt känner jag avlägsnandet av att mycket rodnad är helt värt det. När du väl vet hur du skriver ERB-smaksatt HTML kommer du också att kunna hämta några av dessa förbehandlare ganska snabbt. Ingen raketvetenskap - detsamma gäller för Sass, förresten.
Om du är intresserad finns det två praktiska pärlor för att använda någon av dem i Rails. Gör dig själv en tjänst och kolla upp dem när du blir trött på att skriva alla dessa tröttsamma öppnings- och stängningskoder.
pärla "slim-rails" pärla "haml-rails"
CoffeeScript
CoffeeScript är ett programmeringsspråk som alla andra, men det har den Ruby-smaken för att skriva din JavaScript. Genom förbehandling sammanställs den till vanlig gammal JavaScript som webbläsare kan hantera. Det korta argumentet för att arbeta med CoffeeScript var att det hjälpte till att övervinna några brister som JS bär på. Dokumentationen säger att det syftar till att avslöja "bra delar av JavaScript på ett enkelt sätt". Rimligt nog! Låt oss se en kort titt på ett kort exempel och se vad vi har att göra med:
$ (dokument) .ready -> $ on = 'section' $ ($ på) .css 'bakgrund': 'ingen' gräns ':' ingen 'box-skugga': 'ingen' återvändande
Läser bara en tad trevligare utan alla curlies och semikolon, nej? CoffeeScript försöker ta hand om några av de irriterande bitarna i JavaScript, låter dig skriva mindre, gör koden lite mer läsbar, erbjuder en vänligare syntax och handlar mer behagligt med skrivklasser. Definiera klasser var ett stort plus en stund, särskilt för människor som kommer från Ruby som inte var så förtjusta i att hantera ren JavaScript. CoffeeScript tog en liknande inställning till Ruby och ger dig en fin bit av syntaktiskt socker. Klasser ser så här ut, till exempel:
Klass
klassen Agentkonstruktor: (@firstName, @lastName) -> namn: -> "# @ first_name # @ last_name" introduktion: (namn) -> "Mitt namn är # @ last_name, # name "
Detta språk var ganska populärt i Ruby land ett tag. Jag är inte säker på hur antagningsgraden är idag, men CoffeeScript är standard JS-smaken i Rails. Med ES6 stöder JavaScript nu också klasser - en stor anledning att kanske inte använda CoffeeScript och spela med vanlig JS istället. Jag tror att CoffeeScript fortfarande läser trevligare, men många mindre kosmetiska skäl att använda den har tagits upp med ES6 idag. Jag tycker att det fortfarande är en bra anledning att ge det ett skott, men det är inte vad du kom för här. Jag ville bara ge dig en annan aptitretare och ge en liten bit av kontext kring varför Asset Pipeline gör att du kan arbeta i CoffeeScript ur lådan.
Slutgiltiga tankar
Asset Pipeline har bevisat sig långt bortom min förväntan när den introducerades. Vid den tiden gjorde det verkligen en stänk och åtgärdade en allvarlig smärta för utvecklare. Det gör det självklart och har etablerat sig som ett friktionslöst, smidigt verktyg som förbättrar kvaliteten på dina applikationer.
Det jag tycker mest om är hur lite krångel det handlar om att få det att fungera. Förse mig inte fel, verktyg som Gulp och Grunt är också imponerande. Alternativen för anpassning är mycket. Jag kan bara inte skaka den bekväma känslan som Rails ger mig när jag inte behöver hantera några setup innan jag börjar. Konventioner kan vara kraftfulla, särskilt vassle, de resulterar i något sömlöst och problemfritt.
Share
Accentsconagua
