Sass Best Practices Tips och verktyg för utvecklare

Mycket som hur jQuery revolutionerade vanilj JavaScript, Sass har revolutionerat vanilj CSS. De flesta utvecklare som lär sig Sass är överens om att de aldrig skulle vilja gå tillbaka. Många är också överens om att det största problemet med nya utvecklare är sätt De använder Sass, inte Sass själv.

Jag har scoured webben och sammanställt denna artikel i bästa praxis för att skriva utökningsbar och återanvändbar Sass-kod. Förslag är från mina egna åsikter och från betrodda webbplatser som Sass Guidelines.

Du behöver verkligen inte implementera alla dessa funktioner i ditt arbetsflöde. Men det är värt att åtminstone underhålla dessa idéer och överväga de potentiella fördelarna.

Filorganisation

Det bästa stället att börja med Sass utveckling är filorganisation. Om du redan är i modulär kod ska du förstå värdet av import och partials (mer om dessa senare).

Men för tillfället bara ta en titt på det här filstrukturen exempel från DoCSSa. Jag har återskapat den här filstrukturen som du kan se nedan:

Detta är bara ett förslag och det är ett av de många sätten att organisera dina filer. Du kan hitta andra metoder som använder olika mappstrukturer som “globals” för SCSS och “sidor” för sidspecifikt SCSS.

Låt oss gå igenom den här föreslagna organisationsstilen för att undersöka syftet med varje mapp:

• / globals - innehåller Sass-filer som används på hela webbplatsen, som typografi, färger och rutor
• /komponenter - innehåller Sass-filer med komponentstilar som knappar, tabeller eller inmatningsfält
• / sektioner - innehåller Sass-filer som är dedikerade till specifika sidor eller områden på en sida (kan fungera bättre kombinerat i / komponenter / mapp)
• / utils - innehåller tredjepartsverktyg som Normalisera som kan uppdateras dynamiskt med verktyg som Bower.
• main.scss - Den primära Sass-filen i rotmappen som importerar alla andra.

Detta är bara en grundläggande utgångspunkt och det finns gott om utrymme att expandera med dina egna idéer.

Men oavsett hur du väljer att organisera din SCSS, är det viktigt att du ha någon organisation med en separat fil (eller mapp) för bibliotek som Normalisera som behöver uppdateras, plus komponenter i Sass partials för ditt projekt.

Sass partials är avgörande för moderna bästa praxis. Dessa rekommenderas starkt av Zurbs designteam och av många andra professionella frontendutvecklare.

Här är ett citat från Sass webbplats som förklarar partials:

“Du kan skapa partiella Sass-filer som innehåller små snippets av CSS som du kan inkludera i andra Sass-filer. Detta är ett bra sätt att modulera din CSS och hjälpa till att hålla saker enklare att behålla. En del är helt enkelt en Sass-fil som heter en ledande understrykning. Du kan kanske namnge det något _partial.scss. Undersignalen låter Sass veta att filen bara är en partiell fil och att den inte ska genereras till en CSS-fil. Sass partials används med @importera direktiv.”

Titta även på dessa andra inlägg om Sass filstruktur:

• Hur jag strukturerar Mina Sass-projekt
• Estetisk Sass: Arkitektur och Stil Organisation
• Katalogstrukturer som hjälper dig att behålla din kod

Importera strategier

Inte tillräckligt kan man säga om värdet av Sass import och partials. Kodorganisation är nyckeln till att få en importstruktur och arbetsflöde som bara fungerar.

Det bästa stället att börja är med ett globalsblad som innehåller import, variabler och mixins tillsammans. Många utvecklare föredrar att skilja variabler och mixins men det här kommer ner till semantik.

Tänk på att mixins är ett sätt att importera, eller snarare duplicera, Sass-kod. De är otroligt kraftfulla men ska inte användas med “statisk” koda. Tänk på att det finns en skillnad mellan mixins, sträcker sig och platshållare, som alla har sin användning i Sass-utveckling.

Mixiner används bäst med dynamiska värden som skickas in i mixin för kodändringar. Titta till exempel på denna Sass mixin som skapar en bakgrundsgradient mellan två färger.

@mixin linearGradient ($ top, $ bottom) bakgrund: $ top; / * Gamla webbläsare * / bakgrund: -moz-linjär-gradient (topp, $ topp 0%, $ botten 100%); / * FF3.6 + * / bakgrund: -webkit-gradient (linjär, vänster topp, vänster botten, färgstopp (0%, $ topp), färgstopp (100%, $ botten)); / * Chrome, Safari4 + * / bakgrund: -webkit-linjär-gradient (topp, $ topp 0%, $ botten 100%); / * Chrome10 +, Safari5.1 + * / background: -o-linear-gradienten (topp, $ topp 0%, $ botten 100%); / * Opera 11.10+ * / bakgrund: -ms-linjär-gradient (topp, $ topp 0%, $ botten 100%); / * IE10 + * / bakgrund: Linjär gradient (till botten, $ topp 0%, $ botten 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin tar två värden: en toppfärg och en bottenfärg. Du kan skriva olika mixins för olika typer av gradienter som innehåller 3 eller 4 + olika färger. Detta låter dig importera och klona mixin-koden medan du ändrar parametrarna för anpassade alternativ.

Exemplet från Code Responsible ser ut så här:

.knappen @include linearGradient (#cccccc, # 666666); 

När det gäller mixin är Sass platshållare vilket är främst användbart med förlängningsdirektivet. Det är visserligen mer komplicerat än mixins, men det kan vara ett sätt att kombinera selektörer tillsammans utan att skriva om överskottskoden.

Medan Sass bara har en @import-metod har jag inkluderat mixins och platshållare för att visa flexibiliteten hos kod som kan skrivas i en fil men inkluderad var som helst.

När du bygger en importstruktur, kom ihåg att följa koncepten DRY-kodning (Repetera inte dig själv).

Namnkonventioner

Allmänna regler för namngivningskonventioner gäller för variabler, funktioner och mixins. När du namnger någonting i Sass rekommenderas det att Använd alla små bokstäver med bindestreck för separation.

Sass-kodsyntaxen baseras faktiskt på CSS-riktlinjerna. Här är några rekommenderade bästa metoder för att komma ihåg:

• två (2) mellanslag, inga flikar
• idealiskt, 80 tecken breda linjer eller mindre
• meningsfull användning av blankutrymme
• Använd kommentarer för att förklara CSS-verksamheten

Dessa är inte obligatoriska föremål för giltig Sass-kod. Men dessa förslag kommer från professionella utvecklare som har funnit att dessa regler ger den mest enhetliga kodningsupplevelsen.

Men när det gäller namngivningskonventioner kan du sluta med två olika strukturer: en för Sass-namn och en annan för CSS-klassnamn. Vissa utvecklare föredrar BEM över Sass-förslag. Ingen av dem är mer eller mindre korrekt. bara annorlunda med olika operativa procedurer.

Problemet är att BEM inte överför bra till Sass-variabler eller mixins eftersom de inte har block / element / modifier (BEM) -strukturen. Jag föredrar personligen att använda Sass namngivningskonventioner, men du kan försöka allt från camelCase till din egen interna syntax.

När du organiserar dina variabler och mixins rekommenderas det att dela upp dem efter kategori och lista dem i alfabetisk ordning. Det gör det mycket enklare att redigera eftersom du vet exakt var du ska hitta något.

Om du exempelvis vill ändra en länkfärg öppnar du din variablerfil (kanske _variables.scss) och hitta sektionen för färgvariabler. Sök sedan länken efter namn (header länk, textlänk, etc.) och uppdatera färgen. Enkel!

För att få en uppfattning om hur du kan strukturera en innehållsförteckning för dina Sass-filer kolla in Foundation-inställningsfilen.

 // Foundation for Sites Settings // ----------------------------- // // Innehållsförteckning: // // 1 . Globalt // 2. Brytpunkter // 3. Grid // 4. Bas Typografi // 5. Typografi Hjälpare ... // 1. Global // --------- $ Global-Font-Size: 100 %; $ global-bredd: rem-calc (1200); $ global-lineheight: 1,5; // etc

En annan namngivning gäller för responsiva brytpunkter. När du anger Sass-brytpunkter, försök att undvika enhetsspecifika namn. Det är bättre att skriva namn som små, med, lg och xlg eftersom de är i förhållande till varandra.

Detta är bättre för interna relationer mellan brytpunkter, men också bra för lag där utvecklare kanske inte vet vilka enheter som är relaterade till varandra.

När det gäller att faktiskt lägga ner namn, rekommenderas att du vara så specifik som möjligt utan extra långvariga variabler. Du borde anta webbplatsövergripande namnkonventioner som är lätta att komma ihåg medan kodning.

Ge specifika namngivningskonventioner för allt som färger, marginaler, teckensnittsstackar och rader. Inte bara kan namnen återkallas snabbt, men det gör ditt jobb enklare när du skriver nya variabla namn som måste matcha en befintlig syntax.

Men det finns en fin linje mellan specificitet och konvolvering. Övning hjälper dig att hitta den linjen och skriva mer minnesvärda namn gör det lättare att kopiera kod till andra projekt.

Nesting And Looping

Dessa två Sass tekniker är väldigt olika i åtgärd, men båda har förmåga att missbrukas om den inte används avsevärt.

Nesting är processen med lägga till selektorer nestade tillsammans genom indragning för att skapa mer specificitet med mindre kod. Sass har en häckningsguide som illustrerar exempel på kodning i handling. Men det är lätt att få bäras med häckning. Om du är överdriven kan du sluta med kod som ser ut så här:

body div.content div.container ... body div.content div.container div.articles ... body div.content div.container div.articles> div.post ... 

Alltför specifikt och nästan omöjligt att skriva över, denna typ av kod besegrar syftet med cascading styleheets.

Skimming av denna SitePoint guide hittar du tre gyllene regler för nesting:

• Gå aldrig mer än 3 nivåer djupt.
• Kontrollera att CSS-utgången är ren och återanvändbar.
• Använd häckning när det är vettigt, inte som standardalternativ.

Utvecklaren Josh Broton föreslår att det häckas när det behövs, indraga resten som en allmän syntaxregel.

Inmatning av dina väljare kommer inte att orsaka några CSS-effekter. Men du får en enklare tid att skumma din Sass-fil och identifiera vilka klasser som är relaterade till varandra.

Loops kan också överanvändas om det inte tillämpas korrekt. De tre Sass-slingorna är @för, @medan, och @varje. Jag kommer inte att gå in i detalj om hur de alla fungerar men om du är intresserad kolla in det här inlägget.

Istället skulle jag vilja täcka Syftet med att använda slingor och hur de fungerar i Sass. Dessa bör användas för att spara tid att skriva kod som kan automatiseras. Till exempel, här är ett kodfragment från Clubmate-posten som visar lite Sass-kod följt av utgången:

/ * Sass-kod * / @för $ i från 1 till 8 $ bredd: procent (1 / $ i) .col - # $ i bredd: $ width;  / * utgång * / .col-1 bredd: 100%; .col-2 bredd: 50%; .col-3 bredd: 33.333%; .col-4 bredd: 25%;  .col-5 bredd: 20%; .col-6 bredd: 16.666%; .col-7 bredd: 14.285%; .col-8 bredd: 12,5%;

Dessa kolumnklasser kan användas i samband med ett nätsystem. Du kan till och med lägga till fler kolumner eller ta bort några bara genom att redigera loop-koden.

Loops skall inte användas för att duplicera selektorer eller egenskaper för en väljare; det är vad mixins är för.

Även vid looping finns det något som heter Sass-kartor som lagrar nyckeln: värdespar av data. Avancerade användare ska utnyttja dessa när det är möjligt.

Men vanliga Sass-loopar är enkla och effektiva för att ge kodutmatning utan repetition. Den bästa anledningen till att använda slingor är med CSS-egenskaper som varierar datautgången.

Här är ett bra sätt att kontrollera om din slinga är till hjälp: fråga dig själv om det finns något annat sätt att utföra CSS du behöver med färre linjer kod. Om inte då är loop-syntaxen troligen en bra idé.

Om du någonsin är förvirrad eller vill ha feedback om nesting eller Sass loopar bör du posta en fråga i antingen / r / sass / eller / r / css /, aktiva Reddit-grupper med mycket kunniga Sass-utvecklare.

Modularisering

Övningen av att skriva modulär Sass är en absolut nödvändighet för de flesta projekt (jag skulle argumentera, varje projekt). Modularisering är processen för bryta ner ett projekt i mindre moduler. Detta kan åstadkommas i Sass användning partials.

Tanken bakom modulär Sass är att skriva individuella SCSS-filer med ett specifikt syfte som riktar sig mot globalt innehåll (typografi, galler) eller sidelement (flikar, blanketter).

Sassmoduldefinitionen är ganska tydlig och gör ett mycket specifikt förslag: Importera en modul får aldrig mata ut kod.

Idén om obligatorisk produktion för alla moduler skulle vara en mardröm för optimering. Istället bör du skapa moduler individuellt och Ring bara de du behöver. Moduler kan definieras av mixins eller funktioner, men det är möjligt att skapa moduler som även innehåller selektorer.

Men en Sass Way artikel föreslår att alla väljare ska skrivas som mixins och bara ringer dem efter behov. Oavsett om du antar detta eller inte, är det slutligen ditt val. Jag tror att det beror på projektets storlek och din komfort med hantering av mixins.

Citat John Long från hans inlägg på The Sass Way:

“För mig har moduler blivit de grundläggande enheterna eller byggstenarna i mina Sass-projekt.”

Om du verkligen söker en Sass-rutin rekommenderar jag att du går helt modulär. Prova att bygga nästan allt som en modulär del som ingår i en primär CSS-fil. Först kan detta arbetsflöde vara skrämmande men det är vettigt i större skala - speciellt med stora projekt.

Dessutom är det mycket lättare att kopiera moduler från ett projekt till ett annat när de finns i separata filer. Flexibilitet och återanvändbar kod är hörnstenar för modulär utveckling.

För att lära dig mer om Sass moduler och modulariseringstekniker kolla in dessa inlägg:

• CSS-moduler: Välkommen till framtiden
• Fördelar och nackdelar med modulär Sass
• Modulär CSS Organisation med SMACSS & SASS

Hitta ditt perfekta arbetsflöde

Varje lag och enskild utvecklare har sina egna rutiner som fungerar bäst. Du bör anta praxis som fungerar bäst för dig personligen, eller väljer att anta de som fungerar bäst för ditt lag professionellt.

Också överväga att använda Gulp eller Grunt för projektautomatisering och minifiera din kod. Detta kommer att spara mycket manuellt arbete och automationsverktyg är nu utan tvekan en del av de bästa metoderna för modern frontend-utveckling.

Skim genom open source-bibliotek som Foundation's SCSS på GitHub för att lära dig mer om bästa metoder som används av andra bibliotek.

Saken med bästa praxis är att de verkligen förbättrar ditt arbete för det mesta, men det finns många alternativ. Prova bara saker och se hur de känner. Du lär alltid dig så att dina bästa metoder kan förändras snabbt under 5 år.

Ett sista förslag som jag har för hela Sass-processen är att fatta beslut med tydlighet i åtanke. Skriv kod som gör ditt jobb enklare. Komplicera inte ett projekt om det finns ett enklare sätt att göra det.

Sass är tänkt att förbättra CSS-utvecklingsupplevelsen, så arbeta med tydlighet och bästa praxis för att få bästa möjliga upplevelse.

Sammanfatta

Överbelastning i ett Sass-arbetsflöde kan åtgärdas genom att tweak kodformat och följa bästa praxis. Jag har skisserat en handfull förslag i det här inlägget från Sass bloggar och professionella utvecklare.

Det bästa sättet att lära dig mer är att tillämpa dessa metoder i ditt arbetsflöde och se vad som fungerar. Med tiden kommer du att upptäcka att vissa aktiviteter är mer fördelaktiga än andra, i vilket fall du borde behåll det som fungerar och släpp det som inte gör det.

Kolla in dessa länkar för att hitta fler tips och bästa metoder för Sass utveckling:

• Sass riktlinjer
• En vision för vår Sass
• 8 tips som hjälper dig att få ut det mesta av Sass
• Utsträckning i Sass utan att skapa en Mess
• Sass Best Practices - Nestar mer än 3 nivåer djupt