Sass Best Practices Tips og værktøjer til udviklere

Meget som hvordan jQuery revolutionerede vanilla JavaScript, Sass har revolutioneret vanilje CSS. De fleste udviklere, der lærer Sass, er enige om, at de aldrig vil gå tilbage. Mange er også enige om, at det største problem med nye udviklere er vej de bruger Sass, ikke Sass selv.

Jeg har slettet nettet og samlet denne artikel i bedste praksis til at skrive udvidelig og genanvendelig Sass kode. Forslag er fra mine egne meninger og fra troværdige hjemmesider som Sass Guidelines.

Du skal helt sikkert ikke gennemføre alle disse funktioner i din workflow. Men det er værd at i det mindste underholde disse ideer og overveje de potentielle fordele.

Fil Organisation

Det bedste sted at starte med Sass udvikling er filorganisation. Hvis du allerede er i modulær kode, skal du forstå værdien af ​​import og partials (mere om disse senere).

Men i øjeblikket bare kig på dette filstruktur eksempel fra DoCSSa. Jeg har genoprettet denne filstruktur, som du kan se nedenfor:

Dette er kun et forslag, og det er en af ​​de mange måder, du kan organisere dine filer på. Du kan finde andre metoder, der bruger forskellige mappestrukturer som “globals” til SCSS og “sider” til sidespecifik SCSS.

Lad os gå gennem denne foreslåede organisationsstil for at undersøge formålet med hver mappe:

• / globals - indeholder Sass-filer, der bliver anvendt på hele webstedet som typografi, farver og net
• / komponenter - indeholder Sass-filer med komponentstile som knapper, tabeller eller indtastningsfelter
• / sektioner - indeholder Sass-filer dedikeret til bestemte sider eller områder på en side (måske fungerer bedre kombineret i / komponenter / mappe)
• / utils - indeholder tredjeparts hjælpeprogrammer som Normaliser, der kan opdateres dynamisk med værktøjer som Bower.
• main.scss - den primære Sass-fil i rodmappen, der importerer alle andre.

Dette er bare et grundlæggende udgangspunkt, og der er masser af plads til at udvide med dine egne ideer.

Men uanset hvordan du vælger at organisere dit SCSS, er det afgørende, at du har nogen organisation med en separat fil (eller mappe) til biblioteker som Normaliser, der skal opdateres, plus komponenter i Sass partials til dit projekt.

Sass partials er afgørende for moderne bedste praksis. Disse er stærkt anbefalet af Zurbs designteam og af mange andre professionelle frontend-udviklere.

Her er et citat fra Sass hjemmeside, der forklarer partials:

“Du kan oprette delvise Sass-filer, der indeholder små uddrag af CSS, som du kan medtage i andre Sass-filer. Dette er en fantastisk måde at Modularize dit CSS og hjælpe med at holde tingene lettere at vedligeholde. En del er simpelthen en Sass-fil med en førende understregning. Du kan nævne det noget lignende _partial.scss. Undersøgelsen gør det muligt for Sass at filen kun er en delvis fil, og at den ikke skal genereres til en CSS-fil. Sass partials bruges sammen med @importere direktiv.”

Se også på disse andre indlæg vedrørende Sass filstruktur:

• Hvordan jeg strukturerer mine Sass-projekter
• Æstetisk Sass: Arkitektur og Stil Organisation
• Katalogstrukturer, der hjælper dig med at opretholde din kode

Import Strategier

Der kan ikke siges nok om værdien af ​​Sass import og partials. Kodeorganisation er nøglen til at få en importstruktur og arbejdsgang, der netop virker.

Det bedste sted at starte er med et globals-ark indeholdende import, variabler og mixins sammen. Mange udviklere foretrækker at adskille variabler og mixins, men det kommer ned til semantik.

Husk at mixins er en måde at importere eller rettere duplikere på, Sass-kode. De er utroligt kraftfulde, men bør ikke bruges sammen med “statisk” kode. Husk, at der er forskel på mixins, strækninger og pladsholdere, som alle har brug for i Sass-udvikling.

Mixiner anvendes bedst med dynamiske værdier, der overføres til mixin til kodendringer. Se for eksempel denne Sass mixin, der skaber en baggrundsgradient mellem to farver.

@mixin linearGradient ($ top, $ bottom) baggrund: $ top; / * Gamle browsere * / baggrund: -moz-lineær-gradient (top, $ top 0%, $ bund 100%); / * FF3.6 + * / baggrund: -webkit-gradient (lineær, venstre top, venstre bund, farve stop (0%, $ top), farve stop (100%, $ bund)); / * Chrome, Safari4 + * / baggrund: -webkit-lineær-gradient (top, $ top 0%, $ bund 100%); / * Chrome10 +, Safari5.1 + * / baggrund: -o-lineær-gradient (top, $ top 0%, $ bund 100%); / * Opera 11.10+ * / baggrund: -ms-lineær-gradient (top, $ top 0%, $ bund 100%); / * IE10 + * / baggrund: lineær gradient (til bund, $ top 0%, $ bund 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin tager to værdier: en topfarve og en bundfarve. Du kan skrive forskellige mixins til forskellige typer af gradienter, der indeholder 3 eller 4 + forskellige farver. Dette giver dig mulighed for at importere og klone mixin-koden, mens du ændrer parametrene for brugerdefinerede indstillinger.

Eksemplet fra Code Responsible ser sådan ud:

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

I forbindelse med mixin er Sass 'pladsholder, der primært er nyttig med udvidelsesdirektivet. Det er ganske vist mere komplekst end mixins, men det kan være en måde at kombinere selektorer sammen uden at overskrive overskydende kode.

Mens Sass kun har en @import-metode, har jeg inkluderet mixins og placeholders for at demonstrere fleksibiliteten af ​​kode, der kan skrives i en fil, men inkluderet hvor som helst.

Ved opbygning af en importstruktur skal du bare huske at følge begreberne DRY-kodning (ikke gentag dig selv).

Navngivningskonventioner

Generelle regler for navngivning af konventioner gælder for variabler, funktioner og mixins. Når man navngiver noget i Sass, anbefales det at Brug alle små bogstaver med bindestreger til separation.

Sass kode syntaks er faktisk baseret på CSS retningslinjer regelsæt. Her er nogle anbefalede bedste metoder til at huske på:

• to (2) mellemrum inders, ingen faner
• ideelt set, 80 tegn brede linjer eller mindre
• meningsfuld brug af hvide rum
• brug kommentarer til at forklare CSS operationer

Disse er ikke påkrævede varer til gyldig Sass-kode. Men disse forslag kommer fra professionelle udviklere, som har fundet disse regelsæt giver den mest ensartede kodningserfaring.

Men med hensyn til navngivningskonventioner kan du ende med to forskellige strukturer: en til Sass navne og en anden til CSS klassenavne. Nogle udviklere foretrækker BEM over Sass-forslag. Ingen er mere eller mindre korrekt; bare anderledes med forskellige driftsprocedurer.

Problemet er, at BEM ikke overfører godt til Sass-variabler eller mixiner, fordi de ikke har blok / element / modifier (BEM) struktur. Jeg foretrækker personligt at bruge Sass navngivningskonventioner, men du kan prøve alt fra camelCase til din egen interne syntaks.

Når du organiserer dine variabler og mixins anbefales det at opdele dem efter kategori, og list dem i alfabetisk rækkefølge. Dette gør redigering meget lettere, fordi du ved præcis, hvor du finder noget.

Hvis du for eksempel vil ændre en linkfarve, åbner du din variabelfil (måske _variables.scss) og find sektionen for farvevariabler. Find derefter linket ved navn (header link, tekst link osv.) Og opdater farven. Enkel!

For at få en ide om, hvordan du kan strukturere en indholdsfortegnelse for dine Sass-filer, skal du se fondens indstillingsfil.

 // Foundation for Sites Settings // ----------------------------- // // Indholdsfortegnelse: // // 1 . Globalt // 2. Afbrydelser // 3. Rutenettet // 4. Basistypografi // 5. Typografihjælpere ... // 1. Globalt // --------- $ globalt skriftstørrelse: 100 %; $ global-bredde: rem-calc (1200); $ global-lineheight: 1,5; // etc

En anden navnepraksis vedrører responsive breakpoints. Når du navngiver Sass-brydpunkter, skal du forsøge at undgå enhedsspecifikke navne. Det er bedre at skrive navne som små, med, lg og xlg, fordi de er i forhold til hinanden.

Dette er bedre for interne forhold mellem breakpoints, men også godt for hold, hvor udviklere måske ikke ved, hvilke enheder der er relateret til hinanden.

Med hensyn til faktisk at sætte navne ned, anbefales det at du Vær så specifik som muligt uden ekstra lange variabler. Du burde vedtage site-wide navne konventioner, der er nemme at huske mens kodning.

Giv specifikke navngivningskonventioner til alt som farver, margener, fontstabler og liniehøjder. Ikke kun kan navnene hentes hurtigt, men det gør dit job lettere, når du skriver nye variabelnavne, der skal matche en eksisterende syntaks.

Men der er en fin linje mellem specificitet og konvolvering. Øvelse vil hjælpe dig med at finde den linje, og at skrive mere mindeværdige navne gør det nemmere at kopiere kode til andre projekter.

Nesting Og Looping

Disse to Sass teknikker er meget forskellige i aktion, men begge har Evnen til at blive misbrugt, hvis den ikke anvendes betragteligt.

nesting er processen med tilføjer selektorer nestet sammen gennem indrykning for at skabe mere specificitet med mindre kode. Sass har en nesting guide, som illustrerer eksempler på kode nesting i aktion. Men det er nemt at blive båret væk med nestning. Hvis du er overspændende, kan du ende med en kode, der ser sådan ud:

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

Alt for specifikt og næsten umuligt at overskrive, denne type kode besejrer formålet med cascading stylesheets.

Skimming denne SitePoint guide finder du tre gyldne regler for nesting:

• Gå aldrig mere end 3 niveauer dybt.
• Sørg for, at CSS-udgangen er ren og genanvendelig.
• Brug nesting, når det giver mening, ikke som en standardindstilling.

Udvikler Josh Broton foreslår nesting, når det er nødvendigt, indrykke resten som en generel syntaksregel.

Indrykning af dine selektorer vil ikke forårsage nogen cascading CSS-effekter. Men du får en nemmere tid på at skumme din Sass-fil, der fastslår hvilke klasser der er knyttet til hinanden.

Loops kan også blive overbrugt, hvis det ikke anvendes korrekt. De tre Sass loops er @til, @mens, og @hver. Jeg vil ikke gå i detaljer om hvordan de alle arbejder, men hvis du er interesseret, tjek dette indlæg.

I stedet vil jeg gerne dække Formålet med at bruge sløjfer og hvordan de fungerer i Sass. Disse bør bruges til at spare tid på at skrive kode, der kan automatiseres. For eksempel er her en kodebrikke fra Clubmate-posten, der viser nogle Sass-kode efterfulgt af output:

/ * Sass kode * / @for $ i fra 1 til 8 $ bredde: procent (1 / $ i) .col - # $ i bredde: $ width;  / * output * / .col-1 bredde: 100%; .col-2 bredde: 50%; .col-3 bredde: 33.333%; .col-4 bredde: 25%;  .col-5 bredde: 20%; .col-6 bredde: 16.666%; .col-7 bredde: 14.285%; .col-8 bredde: 12,5%;

Disse kolonne klasser kan bruges i forbindelse med et gitter system. Du kan endda tilføje flere kolonner eller fjerne nogle bare ved at redigere loop-koden.

loops skulle gerne ikke bruges til at duplikere selektorer eller egenskaber til en vælger; det er hvad mixins er til.

Også når der er looping, er der noget, der hedder Sass-kort, som butiksnøglen: værdipar af data. Avancerede brugere bør drage fordel af disse, når det er muligt.

Men regelmæssige Sass-sløjfer er enkle og effektive til at give kodeudgang uden gentagelse. Den bedste grund til at bruge sløjfer er med CSS egenskaber, der varierer data output.

Her er en god måde at kontrollere, om din sløjfe er nyttig: spørg dig selv hvis der er nogen anden måde at output CSS du har brug for med færre linjer af kode. Hvis ikke så er loop-syntaksen sandsynligvis en god idé.

Hvis du nogensinde er forvirret eller vil have feedback om nesting eller Sass sløjfer, skal du stille et spørgsmål i enten / r / sass / eller / r / css /, aktive Reddit samfund med meget kyndige Sass udviklere.

modularisering

Udøvelsen af ​​at skrive modulære Sass er en absolut nødvendighed for de fleste projekter (jeg vil argumentere for hvert projekt). Modularisering er processen med nedbryde et projekt i mindre moduler. Dette kan opnås ved brug af Sass deltoner.

Ideen bag modulær Sass er at skrive individuelle SCSS-filer med et bestemt formål, der målretter mod globalt indhold (typografi, grids) eller sideelementer (faner, formularer).

Sass-modul definitionen er ret klar og gør et meget specifikt forslag: Hvis du importerer et modul, skal du aldrig udføre kode.

Ideen om obligatorisk produktion for alle moduler ville være et mareridt for optimering. I stedet skal du oprette moduler individuelt og ring kun dem, du har brug for. Moduler kan defineres af mixins eller funktioner, men det er muligt at oprette moduler, der også indeholder selektorer.

Men en Sass Way artikel foreslår at skrive alle selektorer som mixins og kun kalde dem efter behov. Uanset om du vedtager dette eller ej, er det i sidste ende dit valg. Jeg tror, ​​det afhænger af projektets størrelse og din komfort med håndtering af mixins.

Citerer John Long fra sit indlæg på The Sass Way:

“For mig er moduler blevet de grundlæggende enheder eller byggesten i mine Sass projekter.”

Hvis du virkelig leder efter en Sass-rutine, anbefaler jeg, at du går fuldt modulært. Prøv at bygge næsten alt som en modulær del, der bliver inkluderet i en primær CSS-fil. I første omgang kan denne arbejdsgang virke skræmmende, men det giver mening på en større skala - især med store projekter.

Plus det er meget nemmere at kopiere moduler fra et projekt til et andet, når de er placeret i separate filer. Fleksibilitet og genbrugelige kode er hjørnestenene i moduludvikling.

For at lære mere om Sass moduler og modularisering teknikker tjek disse indlæg:

• CSS-moduler: Velkommen til fremtiden
• Fordele og ulemper ved modulære Sass
• Modulær CSS Organisation med SMACSS & SASS

Find din perfekte arbejdsgang

Hvert hold og individuel udvikler har deres egen praksis, der fungerer bedst. Du bør vedtage praksis, der fungerer bedst for dig personligt, eller vælger at vedtage dem, der fungerer bedst for dit team professionelt.

Overvej også at bruge Gulp eller Grunt til projektautomatisering og minificere din kode. Dette vil spare meget manuelt arbejde, og automatiseringsværktøjer er uden tvivl en del af de bedste metoder til moderne frontend-udvikling.

Skim gennem open source-biblioteker som Foundation's SCSS på GitHub for at lære mere om bedste praksis anvendt af andre biblioteker.

Ting ved bedste praksis er, at de virkelig forbedrer dit arbejde det meste af tiden, men der er mange alternativer. Bare prøv ting og se, hvordan de føler. Du vil altid lære, så dine bedste praksis kan ændre sig hurtigt i løbet af 5 år.

Et sidste forslag, jeg har for hele Sass-processen, er at træffe beslutninger med klarhed i tankerne. Skriv kode, der gør dit job lettere. Overkompliser ikke et projekt, hvis der er en enklere måde at gøre det på.

Sass skal forbedre CSS udviklingsoplevelsen arbejde med klarhed og bedste praksis for at få den bedste oplevelse muligt.

Wrap-Up

Congestion i en Sass-arbejdsgang kan korrigeres ved at tilpasse kodestile og følge bedste praksis. Jeg har skitseret en håndfuld forslag i dette indlæg givet fra Sass blogs og professionelle udviklere.

Den bedste måde at lære mere på er at anvende disse fremgangsmåder i din workflow og se hvad der virker. Over tid vil du opdage, at nogle aktiviteter er mere fordelagtige end andre, i hvilket tilfælde du skal holde det, hvad der virker, og slip det, der ikke gør det.

Tjek disse links for at finde flere tip og bedste praksis til Sass udvikling:

• Sass Retningslinjer
• En vision for vores Sass
• 8 tips til at hjælpe dig med at få det bedste ud af Sass
• Udvidelse i Sass uden at skabe en Mess
• Sass Best Practices - Nesting mere end 3 niveauer dybt