Sass Best Practices Savjeti i alati za programere

Slično kao što je jQuery napravio revoluciju u JavaScriptu, Sass je napravio revoluciju u vanilijskom CSS-u. Većina developera koji uče Sassa slažu se da se nikada ne žele vratiti. Mnogi se također slažu da je najveći problem kod novih programera put koriste Sass, a ne Sass.

Pregledao sam web i sastavio ovaj članak najbolje prakse za pisanje proširivog i ponovljivog Sass koda. Prijedlozi su iz mog vlastitog mišljenja i pouzdanih web-lokacija kao što su Smjernice za Sass.

Svakako ne morate implementirati sve ove značajke u svoj tijek rada. Ali vrijedi barem zabavljati ove ideje i razmatrati potencijalne koristi.

Organizacija datoteke

Najbolje mjesto za početak razvoja Sassa je organizacija datoteka. Ako ste već u modularnom kodu, trebali biste razumjeti vrijednost uvoza i parcijala (više o njima kasnije).

Ali za sada samo pogledajte ovaj primjer strukture datoteka iz DoCSSa. Ponovno sam stvorio strukturu datoteke koju možete vidjeti u nastavku:

Ovo je samo prijedlog i jedan je od mnogih načina na koji možete organizirati svoje datoteke. Možete pronaći i druge metode koje koriste različite strukture mapa “globals” za SCSS za cijelu web-lokaciju i “stranica” za SCSS specifičan za stranicu.

Prođimo kroz predloženi stil organizacije da bismo ispitali svrhu svake mape:

• / globals - sadrži datoteke Sass koje se primjenjuju na razini web-lokacije poput tipografije, boja i rešetki
• / komponente - sadrži Sass datoteke s stilovima komponenti kao što su gumbi, tablice ili polja za unos
• / dijelovi - sadrži Sass datoteke posvećene određenim stranicama ili područjima na stranici (možda će se bolje kombinirati u mapu / components /
• / utils - sadrži alate treće strane kao što je Normalize koji se mogu dinamički ažurirati alatima kao što je Bower.
• main.scss - primarna Sass datoteka u korijenskoj mapi koja uvozi sve ostale.

Ovo je samo osnovna polazna točka i postoji mnogo prostora za proširenje vlastitim idejama.

No, bez obzira kako odlučite organizirati svoj SCSS, ključno je da vi imati neku organizaciju s posebnom datotekom (ili mapom) za knjižnice kao što je Normalize koju je potrebno ažurirati, kao i komponente u Sass parcijali za vaš projekt.

Sass parcijali su od vitalnog značaja za moderne najbolje prakse. To su visoko preporučeni od strane Zurbovog dizajnerskog tima i mnogih drugih profesionalnih programera.

Evo citata s web-mjesta Sass s objašnjenjem parcijala:

“Možete stvoriti djelomične Sass datoteke koje sadrže male isječke CSS-a koje možete uključiti u druge Sass datoteke. Ovo je sjajan način modularizirajte svoj CSS i pomognite da se stvari lakše održavaju. Djelomična je jednostavno Sass datoteka s imenom vodeće donje crte. Možete ga nazvati nešto slično _partial.scss. Donja crta omogućuje Sassu da zna da je datoteka samo djelomična datoteka i da ne bi trebala biti generirana u CSS datoteci. Sass parcijali se koriste s @uvoz direktiva.”

Pogledajte i druge postove u vezi sa Sass strukturom datoteka:

• Kako strukturiram svoje Sass projekte
• Estetska Sass: Organizacija arhitekture i stila
• Strukture direktorija koje vam pomažu u održavanju vašeg koda

Strategije uvoza

Nedovoljno se može reći o vrijednosti Sassovog uvoza i parcijala. Organizacija koda je ključna za dobivanje strukture uvoza i tijeka rada koji funkcioniraju.

Najbolje mjesto za početak je globals list koji sadrži uvoz, varijable i mixins zajedno. Mnogi programeri preferiraju odvojiti varijable i mixine, ali to se svodi na semantiku.

Imajte na umu da su miksini način uvoza, odnosno umnožavanje Sass koda. Nevjerojatno su snažni, ali ne bi ih trebali koristiti “statički” kodirati. Imajte na umu da postoji razlika između kombinacija, proširenja i rezerviranih mjesta, od kojih se svi koriste u razvoju Sassa.

Mixins se najbolje koriste s dinamičkim vrijednostima koje se prenose u mixin za promjene koda. Na primjer, pogledajte ovaj Sass mixin koji stvara pozadinski gradijent između dvije boje.

@mixin linearGradient ($ top, $ bottom) pozadina: $ top; / * Stari preglednici * / background: -moz-linear-gradient (vrh, $ top 0%, $ bottom 100%); / * FF3.6 + * / pozadina: -webkit-gradijent (linearni, lijevi vrh, lijevo dno, boja-stop (0%, $ top), boja-stop (100%, $ bottom)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (vrh, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / pozadina: -o-linearni gradijent (vrh, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (vrh, $ top 0%, $ bottom 100%); / * IE10 + * / pozadina: linearno-gradijent (do dna, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin ima dvije vrijednosti: gornju i donju. Možete pisati različite mixine za različite vrste gradijenta koji uključuju 3 ili 4 različite boje. To vam omogućuje uvoz i kloniranje mixin koda dok mijenjate parametre prilagođenih opcija.

Primjer iz koda odgovoran izgleda ovako:

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

Vezano uz mixin je Sassova oznaka mjesta koja je primarno korisna s direktivom za proširenje. Doduše, to je složenije od miješanja, ali to može biti način da se to postigne Kombinirajte selektore zajedno bez prepisivanja viška koda.

Iako Sass ima samo jednu @import metodu, uključio sam miksine i rezervirana mjesta kako bih pokazao fleksibilnost koda koji se može napisati u jednoj datoteci, ali je uključen bilo gdje.

Prilikom izrade strukture uvoza ne zaboravite slijediti koncepte DRY kodiranja (Nemojte se ponavljati).

Konvencije imenovanja

Opća pravila za imenovanje konvencija primjenjuju se na varijable, funkcije i mješavine. Pri imenovanju bilo čega u Sassu preporučuje se koristiti sva mala slova s ​​crtama za razdvajanje.

Sintaksa Sass koda zapravo se temelji na skupu pravila za CSS smjernice. Evo nekoliko preporučenih najboljih postupaka koje trebate imati na umu:

• dva (2) razmaka razmaka, bez kartica
• idealno, široke linije od 80 znakova ili manje
• smisleno korištenje razmaka
• koristite komentare kako biste objasnili CSS operacije

To nisu potrebne stavke za valjanu Sass kod. Ali ti prijedlozi dolaze od profesionalnih programera koji otkrili su da ti skupovi pravila pružaju najjednakije iskustvo kodiranja.

Ali što se tiče konvencija imenovanja, možete završiti s dvije različite strukture: jednu za Sass imena i drugu za CSS nazive klasa. Neki programeri preferiraju BEM u odnosu na Sassove prijedloge. Niti jedna nije više, ili manje, ispravna; drugačije s različitim operacijskim postupcima.

Problem je u tome što se BEM ne prenosi dobro na Sass varijable ili mješavine jer nemaju strukturu blok / element / modifikator (BEM). Ja osobno radije koristiti Sass imenovanje konvencije, ali možete pokušati bilo što od camelCase na svoj interni sintaksu.

Prilikom organiziranja varijabli i miksina preporučuje se podijelite ih prema kategoriji, a zatim ih navedite abecednim redom. To čini uređivanje mnogo lakšim jer točno znate gdje pronaći nešto.

Na primjer, da biste promijenili boju veze, otvorili biste datoteku varijabli (možda _variables.scss) i pronađite odjeljak za varijable boja. Zatim pronađite vezu po imenu (poveznica zaglavlja, tekstualna veza, itd.) I ažurirajte boju. Jednostavan!

Da biste dobili ideju o tome kako možete strukturirati tablicu sadržaja za svoje Sass datoteke, provjerite datoteku s postavkama Zaklade.

 // Zaklada za postavke web-mjesta // ----------------------------- // // Sadržaj: // // 1 Globalna // 2. Točke prekida // 3. Mreža // 4. Osnovna tipografija // 5. Pomoćnik tipografije… // 1. Globalna // --------- $ globalna veličina fonta: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // itd

Postoji i druga praksa imenovanja odgovorne prijelomne točke. Kada imenujete Sass točke prekida, pokušajte izbjeći imena specifična za uređaj. Bolje je pisati imena kao što su mala, med, lg i xlg jer su oni međusobno.

To je bolje za interne odnose između točaka prekida, ali i za timove u kojima programeri možda ne znaju koji se uređaji međusobno odnose.

Što se zapravo tiče spuštanja imena, preporuča se da vi biti što specifičniji bez dugih varijabli. Trebao bi usvojiti konvencije imenovanja na razini cijelog mjesta koje je lako zapamtiti tijekom kodiranja.

Navedite posebne konvencije imenovanja za sve, kao što su boje, margine, slogovi fontova i visine retka. Ne samo da se imena mogu brzo prisjetiti, nego i to čini vaš posao lakšim pri pisanju novih naziva varijabli koje moraju odgovarati postojećoj sintaksi.

Ali postoji tanka linija između specifičnosti i konvolucije. Praksa će vam pomoći da pronađete tu liniju, a pisanje više nezaboravnih imena olakšava kopiranje koda u druge projekte.

Gniježđenje i petlje

Ove dvije Sass tehnike su vrlo različite u djelovanju, ali obje imaju sposobnost zlostavljanja ako se ne koristi pažljivo.

traženje gnijezda je proces od dodavanje selektora ugniježđenih zajedno kroz uvlačenje kako bi se stvorilo više specifičnosti s manje koda. Sass ima vodič za gniježđenje koji ilustrira primjere gniježđenja koda u akciji. Ali lako se može odnijeti s gniježđenjem. Ako pretjerujete, možete završiti s kodom koji izgleda ovako:

tijelo div.content div.container … tijelo div.content div.container div.articles … tijelo div.content div.container div.articles> div.post … 

Previše specifičan i gotovo nemoguć za prepisivanje, ova vrsta koda uništava svrhu kaskadnih stilova.

Skidanjem ovog vodiča za SitePoint naći ćete tri zlatna pravila za gniježđenje:

• Nikada ne idite dublje od 3 razine.
• Osigurajte da je CSS izlaz čist i ponovno upotrebljiv.
• Koristite gniježdenje kada to ima smisla, a ne kao zadanu opciju.

Razvojni programer Josh Broton predlaže gniježđenje kada je to potrebno, uvlačenje ostatka kao opće pravilo sintakse.

Uvlačenje selektora neće uzrokovati kaskadne CSS efekte. Ali, lakše ćete skliznuti Sass datoteku na mjesto koje klase su međusobno povezane.

Petlje također mogu ako se ne primjenjuje ispravno. Tri Sass petlje su @za, @dok, i @svaki. Neću ulaziti u detalje o tome kako svi oni rade, ali ako ste zainteresirani, provjerite ovaj post.

Umjesto toga, želio bih pokriti svrha uporabe petlji i kako funkcioniraju u Sassu. To bi trebalo koristiti za uštedu vremena kod pisanja koje se može automatizirati. Na primjer, ovdje je isječak koda iz posta Clubmatea koji pokazuje neki Sass kod iza kojeg slijedi izlaz:

/ * Sass kod * / @ za $ i od 1 do 8 $ width: postotak (1 / $ i) .col - # $ i width: $ width;  * / * izlaz * / .col-1 širina: 100%; .col-2 širina: 50%; .col-3 širina: 33.333%; .col-4 širina: 25%;  .col-5 širina: 20%; .col-6 širina: 16.666%; .col-7 širina: 14.285%; .col-8 širina: 12.5%;

Ove klase stupaca mogu se koristiti zajedno s mrežnim sustavom. Možete čak dodati više stupaca ili ukloniti neke samo uređivanjem koda petlje.

petlje treba ne koristiti za dupliciranje selektora ili svojstava selektora; za to su miksini.

Isto tako, kada je u pitanju petlja, postoji nešto što se zove Sass karte koje pohranjuju parove podataka: vrijednosti. Napredni korisnici trebali bi ih iskoristiti kad god je to moguće.

No, redovite Sass petlje su jednostavne i učinkovite u osiguravanju izlaznog koda bez ponavljanja. Najbolji razlog za korištenje petlje je s CSS svojstva koja mijenjaju izlazne podatke.

Evo dobrog načina da provjerite je li vaša petlja korisna: zapitajte se ako postoji neki drugi način za izlaz CSS-a koji vam je potreban s manje linija koda. Ako ne, onda je sintaksa petlje vjerojatno odlična ideja.

Ako ste ikada zbunjeni ili želite povratnu informaciju o gniježđenju ili Sass petlji, trebali biste postaviti pitanje u / r / sass / ili / r / css /, aktivnim zajednicama Reddit s vrlo razvijenim Sass programerima.

modulariziranje

Praksa pisanja modularnog Sassa apsolutno je nužna za većinu projekata (tvrdio bih, svaki projekt). Modularizacija je proces razbijanje projekta u manje module. To se može postići pomoću Sassa djelomični.

Ideja modularnog Sassa je pisanje pojedinačnih SCSS datoteka s određenom svrhom ciljanjem globalnog sadržaja (tipografija, rešetke) ili elemenata stranice (kartice, obrasci).

Definicija Sass modula je prilično jasna i daje vrlo specifičan prijedlog: uvoz modula ne smije nikada izlaziti kod.

Ideja obveznog izlaza za sve module bila bi noćna mora za optimizaciju. Umjesto toga trebate kreirati module pojedinačno i pozovite samo one koje trebate. Moduli se mogu definirati miksinima ili funkcijama, ali je moguće stvoriti i module koji sadrže selektore.

Međutim, članak Sass Way predlaže pisanje svih selektora kao mješavine i samo pozivanje prema potrebi. Bez obzira prihvaćate li to ili ne, u konačnici je vaš izbor. Mislim da to ovisi o veličini projekta i vašoj udobnosti pri rukovanju mješavinama.

Citirajući Johna Longa s njegovog mjesta na The Sass Way:

“Za mene, moduli su postali osnovne jedinice ili blokovi za moje Sass projekte.”

Ako zaista tražite Sass rutinu, preporučujem vam da budete potpuno modularni. Pokušajte izgraditi gotovo sve kao modularni dio koji se uključuje u primarnu CSS datoteku. Isprva se ovaj tijek rada može činiti zastrašujućim, ali ima smisla u većim razmjerima - posebno u velikim projektima.

Osim toga, mnogo je lakše kopirati module iz jednog projekta u drugi kada se nalaze u zasebnim datotekama. savitljivost i kod za višekratnu upotrebu temelj su modularnog razvoja.

Da biste saznali više o Sass modulima i tehnikama modularnosti, pogledajte ove postove:

• CSS moduli: Dobrodošli u budućnost
• Za i protiv Modularnog Sassa
• Modularna CSS organizacija sa SMACSS i SASS

Pronađite svoj savršeni tijek rada

Svaki tim i pojedinačni programer imaju svoje vlastite prakse koje najbolje funkcioniraju. Trebali biste usvojiti postupke koji najbolje funkcioniraju za vas osobno ili odlučiti usvojiti one koji najbolje rade za vaš tim profesionalno.

Također razmotriti korištenje Gulp ili Grunt za projekt automatizacije i minifying svoj kod. To će uštedjeti mnogo ručnog rada, a alati za automatizaciju sada su nesumnjivo dio najbolje prakse za suvremeni razvoj sučelja.

Kroz biblioteke otvorenog koda, kao što je SCSS Zaklade na GitHubu, pročitajte više o najboljim praksama drugih knjižnica.

Najbolja praksa je da oni većinu vremena stvarno poboljšavaju vaš rad, ali postoje mnoge alternative. Samo pokušajte stvari i vidite kako se osjećaju. Uvijek ćete učiti tako da se vaše najbolje prakse mogu brzo mijenjati tijekom 5 godina.

Jedan konačni prijedlog koji imam za cijeli Sass proces je da donositi odluke s jasnoćom na umu. Pišite kod koji olakšava vaš posao. Nemojte previše komplicirati projekt ako postoji jednostavniji način za to.

Sass je namijenjen poboljšanju iskustva u razvoju CSS-a raditi s jasnoćom i najboljim praksama da biste dobili najbolje moguće iskustvo.

Zamotati

Zagušenja u Sass tijeku rada mogu se ispraviti podešavanjem stilova koda i praćenjem najboljih praksi. U ovom sam postu naveo nekoliko prijedloga koje su dali Sassovi blogovi i profesionalni programeri.

Najbolji način da saznate više je primjena tih praksi na vaš radni proces i vidjeti što radi. S vremenom ćete otkriti da su neke aktivnosti korisnije od drugih, u tom slučaju trebate zadržati sve što radi i ispustiti ono što ne.

Pogledajte ove veze da biste pronašli više savjeta i najboljih praksi za razvoj Sassa:

• Smjernice Sassa
• Vizija za naše Sass
• 8 savjeta koji će vam pomoći da dobijete najbolje od Sassa
• Širenje u Sassu bez stvaranja nereda
• Sass Best Practices - Gniježđenje više od 3 razine duboko