Sass Best Practices Tips og verktøy for utviklere

Mye som hvordan jQuery revolusjonerte vanilla JavaScript, Sass har revolusjonert vanilje CSS. De fleste utviklere som lærer Sass, er enige om at de aldri vil gå tilbake. Mange er også enige om at det største problemet med nye utviklere er vei de bruker Sass, ikke Sass selv.

Jeg har slettet nettet og samlet denne artikkelen av beste praksis for å skrive ut utvidbar og gjenbrukbar Sass-kode. Forslag er fra mine egne meninger og fra pålitelige nettsteder som Sass Guidelines.

Du trenger ikke å implementere alle disse funksjonene i arbeidsflyten din. Men det er verdt å i det minste underholde disse ideene og vurdere de potensielle fordelene.

Fil Organisasjon

Det beste stedet å starte med Sass utvikling er filorganisasjon. Hvis du allerede er i modulær kode, bør du forstå verdien av import og partials (mer om disse senere).

Men for nå bare ta en titt på dette filstrukturen eksempel fra DoCSSa. Jeg har gjenskapt denne filstrukturen som du kan se nedenfor:

Dette er bare et forslag, og det er en av de mange måtene du kan organisere filene dine. Du kan finne andre metoder som bruker forskjellige mappestrukturer som “globals” for SCSS og “sider” for sidespesifikk SCSS.

La oss gå gjennom denne foreslåtte organisasjonsstilen for å undersøke formålet med hver mappe:

• / globals - inneholder Sass-filer som blir brukt på hele nettstedet som typografi, farger og ruter
• / komponenter - inneholder Sass-filer med komponentstiler som knapper, tabeller eller inputfelter
• / seksjoner - inneholder Sass-filer dedikert til bestemte sider eller områder på en side (kan fungere bedre kombinert i komponentene / mappen)
• / utils - inneholder tredjepartsverktøy som Normaliser som kan oppdateres dynamisk med verktøy som Bower.
• main.scss - Den primære Sass-filen i rotmappen som importerer alle andre.

Dette er bare et grunnleggende utgangspunkt, og det er god plass til å utvide med dine egne ideer.

Men uansett hvordan du velger å organisere SCSS, er det viktig at du ha noen organisasjon med en egen fil (eller mappe) for biblioteker som Normaliser som må oppdateres, pluss komponenter i Sass partials for prosjektet ditt.

Sass partials er avgjørende for moderne beste praksis. Disse er sterkt anbefalt av Zurbs designteam og av mange andre profesjonelle frontend-utviklere.

Her er et sitat fra Sass nettsiden som forklarer partials:

“Du kan opprette delvise Sass-filer som inneholder små utdrag av CSS som du kan inkludere i andre Sass-filer. Dette er en fin måte å Modulariser CSS og sørg for at det blir enklere å vedlikeholde. En delvis er bare en Sass-fil oppkalt med en ledende understrekning. Du kan kanskje nevne det som noe _partial.scss. Understreket lar Sass vite at filen bare er en delvis fil, og at den ikke skal genereres til en CSS-fil. Sass partials brukes med @importere direktiv.”

Ta også en titt på disse andre innleggene angående Sass filstruktur:

• Hvordan jeg strukturerer mine Sass-prosjekter
• Estetisk Sass: Arkitektur og stilorganisasjon
• Katalogstrukturer som hjelper deg med å opprettholde koden din

Importer Strategier

Det er ikke nok å si om verdien av Sass import og partials. Kodeorganisasjon er nøkkelen til å få en importstruktur og arbeidsflyt som bare fungerer.

Det beste stedet å starte er med et globals-ark som inneholder import, variabler og mixins sammen. Mange utviklere foretrekker å skille mellom variabler og mixiner, men dette kommer ned til semantikk.

Husk at mixins er en måte å importere, eller rettere duplisere, Sass-kode på. De er utrolig kraftige, men skal ikke brukes sammen med “statisk” kode. Husk det er en forskjell mellom mixins, strekker seg og plassholdere, som alle har bruk for i Sass utvikling.

Mixiner brukes best med dynamiske verdier som sendes inn i mixin for kodeendringer. For eksempel, sjekk ut denne Sass mixin som skaper en bakgrunnsgradient mellom to farger.

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

Mixin tar to verdier: en toppfarge og en bunnfarge. Du kan skrive forskjellige mixins for ulike typer gradienter som inkluderer 3 eller 4 forskjellige farger. Dette lar deg importere og klone mixin-koden mens du endrer parametrene for egendefinerte alternativer.

Eksempelet fra kodeansvarlig ser slik ut:

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

I tilknytning til mixin er Sass 'plassholder som hovedsakelig er nyttig med utvidelsesdirektivet. Det er ganske vist mer komplisert enn mixins, men dette kan være en måte å kombinere selektorer sammen uten å overskrive overskytende kode.

Mens Sass har bare én @import-metode, har jeg tatt med mixins og plassholdere for å demonstrere fleksibiliteten til kode som kan skrives i en fil, men inkludert hvor som helst.

Når du bygger en importstruktur, bare husk å følge konseptene DRY-koding (ikke gjenta selv).

Naming Conventions

Generelle regler for navnekonvensjoner gjelder for variabler, funksjoner og mixins. Når du navngir noe i Sass, anbefales det å bruk alle små bokstaver med bindestreker for separasjon.

Sass-kode syntaks er faktisk basert på CSS retningslinjer regelen. Her er noen anbefalte beste praksiser å huske på:

• to (2) mellomrom indents, ingen faner
• ideelt sett, 80 tegn brede linjer eller mindre
• meningsfull bruk av hvite rom
• bruk kommentarer for å forklare CSS-operasjoner

Dette er ikke obligatoriske elementer for gyldig Sass-kode. Men disse forslagene kommer fra profesjonelle utviklere som har funnet disse reglene gir den mest jevne kodende opplevelsen.

Men når det gjelder navnekonvensjoner, kan du ende opp med to forskjellige strukturer: en for Sass-navn og en annen for CSS-klassenavn. Noen utviklere foretrekker BEM over Sass-forslag. Ingen er mer eller mindre riktig; bare annerledes med forskjellige operasjonsprosedyrer.

Problemet er at BEM ikke overfører godt til Sass-variabler eller mixiner fordi de ikke har blokk / element / modifier (BEM) -strukturen. Jeg personlig foretrekker å bruke Sass navnekonvensjoner, men du kan prøve alt fra camelCase til din egen interne syntaks.

Ved organisering av variablene og mixins anbefales det å del dem opp etter kategori, og skriv dem i alfabetisk rekkefølge. Dette gjør redigering mye enklere fordi du vet nøyaktig hvor du skal finne noe.

Hvis du for eksempel vil endre en koblingsfarge, kan du åpne variabilsfilen din (kanskje _variables.scss) og finn delen for fargevariabler. Deretter finner du linken etter navn (header link, tekst link, etc) og oppdaterer fargen. Enkel!

For å få en ide om hvordan du kan strukturere en innholdsfortegnelse for Sass-filene, sjekk ut instituttets innstillingsfil.

 // Foundation for Sites Settings // ----------------------------- // // Innholdsfortegnelse: // // 1 . Globalt // 2. Brytpunkter // 3. Rutenettet // 4. Basetypografi // 5. Typografihjelpere // // Global // --------- $ global skriftstørrelse: 100 %; $ global-bredde: rem-calc (1200); $ global-lineheight: 1,5; // etc

En annen navngivningsøvelse gjelder responsive breakpoints. Når du angir Sass-brytepunkter, prøv å unngå enhetsspesifikke navn. Det er bedre å skrive navn som små, med, lg og xlg fordi de er i forhold til hverandre.

Dette er bedre for interne forhold mellom breakpoints, men også bra for lag hvor utviklere kanskje ikke vet hvilke enheter som er relatert til hverandre.

Når det gjelder å sette ned navn, anbefales det at du Vær så spesifikk som mulig uten ekstra lange variabler. Du burde vedta nettstedskjede navngivningskonvensjoner som er lette å huske mens koding.

Gi spesifikke navngivningskonvensjoner for alt som farger, marginer, fontstabler og linjehøyder. Ikke bare kan navnene bli raskt tilbakekalt, men det gjør jobben enklere når du skriver nye variabelnavn som må samsvare med en eksisterende syntaks.

Men det er en fin linje mellom spesifisitet og konvolusjon. Øvelse vil hjelpe deg med å finne den linjen, og å skrive mer minneverdige navn gjør det enklere å kopiere kode til andre prosjekter.

Nesting Og Looping

Disse to Sass-teknikkene er svært forskjellige i aksjon, men begge har Evnen til å bli misbrukt hvis ikke brukt betraktelig.

nesting er prosessen med legge til selektorer nestet sammen gjennom innrykk for å skape mer spesifisitet med mindre kode. Sass har en nesting guide som illustrerer eksempler på kode nesting i handling. Men det er lett å bli båret med nesting. Hvis du er overdreven, kan du ende opp med kode som ser slik ut:

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

Altfor spesifikk og nesten umulig å overskrive, slår denne typen koden formålet med kaskende stilark.

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

• Aldri gå mer enn 3 nivåer dypt.
• Kontroller at CSS-utgangen er ren og gjenbrukbar.
• Bruk nesting når det er fornuftig, ikke som standardalternativ.

Utvikler Josh Broton foreslår å nesting når det er nødvendig, inntast resten som en generell syntaksregel.

Indusere dine valgorer vil ikke forårsake noen cascading CSS-effekter. Men du får en enklere tid å skumre Sass-filen din, og finne ut hvilke klasser som er relatert til hverandre.

Looper kan også være overused hvis det ikke brukes riktig. De tre Sass-løkkene er @til, @samtidig som, og @Hver. Jeg vil ikke gå i detalj om hvordan de alle fungerer, men hvis du er interessert, sjekk ut dette innlegget.

I stedet vil jeg gjerne dekke Formålet med å bruke løkker og hvordan de fungerer i Sass. Disse bør brukes til å spare tid å skrive kode som kan automatiseres. For eksempel, her er en kodebit fra Clubmate-innlegget som viser noen Sass-kode etterfulgt av utgangen:

/ * Sass kode * / @for $ i fra 1 til 8 $ bredde: prosentandel (1 / $ i) .col - # $ i bredde: $ width;  / * utgang * / .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 kolonneklassene kan brukes sammen med et rutenett system. Du kan til og med legge til flere kolonner eller fjerne noen bare ved å redigere loop-koden.

Loops bør ikke brukes til å duplisere selektorer eller egenskaper for en velger; det er hva mixins er for.

Også når looping er det noe som heter Sass-kort som lagrer nøkkel: verdipar av data. Avanserte brukere bør dra nytte av disse når det er mulig.

Men vanlige Sass-løkker er enkle og effektive for å gi kodeutgang uten gjentakelse. Den beste grunnen til å bruke løkker er med CSS egenskaper som varierer datautgang.

Her er en god måte å sjekke om sløyfen din er nyttig: spør deg selv hvis det er noen annen måte å utføre CSS du trenger med færre linjer med kode. Hvis ikke, er loop-syntaksen sannsynligvis en god ide.

Hvis du noen gang er forvirret eller vil ha tilbakemelding om nesting eller Sass sløyfer, bør du legge inn et spørsmål i enten / r / sass / eller / r / css /, aktive Reddit-fellesskap med svært kunnskapsrike Sass-utviklere.

modularisering

Øvelsen av å skrive modulær Sass er en absolutt nødvendighet for de fleste prosjekter (jeg vil argumentere, hvert prosjekt). Modularisering er prosessen med bryte ned et prosjekt i mindre moduler. Dette kan oppnås i Sass bruk partials.

Ideen bak modulær Sass er å skrive individuelle SCSS-filer med en bestemt hensikt rettet mot globalt innhold (typografi, grids) eller sideelementer (faner, skjemaer).

Sass-moduldefinisjonen er ganske klar og gir et veldig spesifikt forslag: Hvis du importerer en modul, skal du aldri skrive ut kode.

Ideen om obligatorisk produksjon for alle moduler ville være et mareritt for optimalisering. I stedet bør du opprette moduler individuelt og bare ring de som du trenger. Moduler kan defineres av mixins eller funksjoner, men det er mulig å lage moduler som også inneholder selektorer.

En Sass Way-artikkel foreslår imidlertid å skrive alle selektorer som mixins og bare ringe dem etter behov. Enten du vedtar dette eller ikke, er i siste instans ditt valg. Jeg tror det avhenger av størrelsen på prosjektet og din komfort med å håndtere mixins.

Quoting John Long fra hans innlegg på The Sass Way:

“For meg har moduler blitt de grunnleggende enhetene eller byggeblokkene til mine Sass-prosjekter.”

Hvis du virkelig ser etter en Sass-rutine, anbefaler jeg at du går fullt modulær. Prøv å bygge nesten alt som en modulær del som blir inkludert i en primær CSS-fil. Først kan dette arbeidet virke skremmende, men det gir mening i større skala - spesielt med store prosjekter.

I tillegg er det mye lettere å kopiere moduler fra ett prosjekt til et annet når de er plassert i separate filer. fleksibilitet og gjenbrukbar kode er hjørnesteinene til modulær utvikling.

For å lære mer om Sass moduler og modularisering teknikker sjekk ut disse innleggene:

• CSS Moduler: Velkommen til fremtiden
• Fordeler og ulemper ved modulær sass
• Modulær CSS Organisasjon med SMACSS & SASS

Finn din perfekte arbeidsflyt

Hvert lag og individuell utvikler har sin egen praksis som fungerer best. Du bør vedta praksis som fungerer best for deg personlig, eller velge å adoptere de som jobber best for laget ditt profesjonelt.

Vurder også å bruke Gulp eller Grunt for prosjektautomatisering og redusere koden din. Dette vil spare mye manuelt arbeid og automatiseringsverktøy er nå utvilsomt en del av de beste metodene for moderne frontendutvikling.

Skim gjennom åpen kildebibliotek som Foundation's SCSS på GitHub for å lære mer om beste praksis som brukes av andre biblioteker.

Tingen om beste praksis er at de virkelig forbedrer arbeidet ditt mesteparten av tiden, men det er mange alternativer. Bare prøv ting og se hvordan de føler. Du vil alltid lære, slik at din beste praksis kan endres raskt i løpet av 5 år.

Et siste forslag jeg har for hele Sass-prosessen er å ta beslutninger med klarhet i tankene. Skriv kode som gjør jobben enklere. Ikke overkompliser et prosjekt hvis det er enklere å gjøre det.

Sass er ment å forbedre CSS utviklingsopplevelsen, så arbeid med klarhet og beste praksis for å få den beste opplevelsen mulig.

Wrap-Up

Congestion i en Sass-arbeidsflyt kan korrigeres ved å tilpasse kodestiler og følge gode fremgangsmåter. Jeg har skissert en håndfull forslag i dette innlegget fra Sass blogger og profesjonelle utviklere.

Den beste måten å lære mer på er å bruke disse rutene i arbeidsflyten din og se hva som fungerer. Over tid vil du oppdage at noen aktiviteter er mer fordelaktige enn andre, i så fall bør du holde det som fungerer og slipp det som ikke gjør det.

Ta en titt på disse linkene for å finne flere tips og gode fremgangsmåter for Sass utvikling:

• Sass Retningslinjer
• Et visjon for vår Sass
• 8 tips for å hjelpe deg med å få det beste ut av Sass
• Utvide i Sass uten å skape et mord
• Sass Best Practices - Nesting mer enn 3 nivåer dypt