„Sass Best Practices“ patarimai ir įrankiai programuotojams

Panašiai kaip jQuery sukėlė revoliuciją vanilės JavaScript, Sass sukėlė revoliuciją vanilės CSS. Dauguma kūrėjų, kurie mokosi „Sass“, sutinka, kad jie niekada nenorės grįžti. Daugelis taip pat sutinka, kad didžiausia su naujomis kūrėjais susijusi problema yra taip jie naudoja Sassą, o ne pats Sassas.

Aš šveitiau internetą ir sudariau šį straipsnį geriausios praktikos išplėsti ir pakartotinai naudoti Sass kodą rašyti. Pasiūlymai yra iš mano pačių nuomonių ir patikimų svetainių, tokių kaip „Sass“ gairės.

Jums tikrai nereikia įdiegti visų šių funkcijų į savo darbo eigą. Tačiau verta paminėti šias idėjas ir apsvarstyti galimą naudą.

Failų organizavimas

Geriausia vieta pradėti „Sass“ kūrimą yra failų organizavimas. Jei jau esate į modulinį kodą, tuomet turėtumėte suprasti importo vertę ir dalinius (daugiau apie juos vėliau).

Tačiau šiuo metu tiesiog peržiūrėkite šį failų struktūros pavyzdį iš „DoCSSa“. Aš sukūriau šią failo struktūrą, kurią galite pamatyti toliau:

Tai tik pasiūlymas ir tai vienas iš daugelio būdų, kaip galite tvarkyti failus. Galite rasti kitus metodus, kurie naudoja skirtingas aplankų struktūras “globaliai” visai SCSS ir “puslapius” konkrečiam puslapiui pritaikytam SCSS.

Eikite per šį siūlomą organizacijos stilių, kad ištirtume kiekvieno aplanko paskirtį:

• / globalai - Jame yra „Sass“ failų, kurie yra taikomi visoje svetainėje, pavyzdžiui, tipografija, spalvos ir tinklai
• komponentai - yra „Sass“ failai su komponentų stiliais, pvz., mygtukais, lentelėmis ar įvesties laukais
• / skyriai - yra „Sass“ failai, skirti tam tikriems puslapiams ar sritims (gali būti geriau sujungti į / komponentus / aplanką)
• / utils - yra trečiųjų šalių komunalinės paslaugos, pvz., normalizuoti, kurias galima atnaujinti dinamiškai su tokiais įrankiais kaip Bower.
• main.scss - pirminis Sass failas šakniniame aplanke, kuris importuoja visus kitus.

Tai tik pagrindinis pradžios taškas ir daug galimybių išplėsti savo idėjomis.

Bet nesvarbu, kaip nuspręsite organizuoti savo SCSS, labai svarbu, kad jūs turėti tam tikrą organizaciją su atskiru failu (arba aplanku) bibliotekoms, pvz., Normalizuoti, kuri turi būti atnaujinta, ir „Sass“ dalinių jūsų projekto komponentams.

„Sass“ daliniai yra gyvybiškai svarbūs šiuolaikinei gerajai praktikai. Tai labai rekomenduoja „Zurb“ dizaino komanda ir daugelis kitų profesionalių „frontend“ kūrėjų.

Čia yra citata iš „Sass“ svetainės, kurioje paaiškinami daliniai:

“Galite sukurti dalinius Sass failus, kuriuose yra mažai CSS fragmentų, kuriuos galite įtraukti į kitus „Sass“ failus. Tai puikus būdas moduliuoti savo CSS ir padėti išlaikyti dalykus lengviau prižiūrėti. Dalinis yra tiesiog „Sass“ failas, pavadintas pagrindiniu pabraukimu. Galite pavadinti jį panašiu _partial.scss. Paryškinimas leidžia „Sass“ žinoti, kad failas yra tik dalinis failas ir kad jis neturėtų būti generuojamas į CSS failą. Sass daliniai yra naudojami su @import direktyva.”

Taip pat žiūrėkite šiuos kitus įrašus apie „Sass“ failų struktūrą:

• Kaip struktūrizuoti savo „Sass“ projektus
• Estetinė Sass: architektūra ir stiliaus organizavimas
• Rodyklės struktūros, kurios padeda išlaikyti jūsų kodą

Importavimo strategijos

Neįmanoma pasakyti apie „Sass“ importo ir dalinių dalių vertę. Kodo organizavimas yra raktas į importo struktūrą ir darbo eigą, kuri tik veikia.

Geriausia vieta pradėti yra pasaulinis lapas, kuriame yra importas, kintamieji ir mišiniai. Daugelis kūrėjų nori atskirti kintamuosius ir mišinius, tačiau tai atsitinka semantikai.

Atminkite, kad mišiniai yra „Sass“ kodo importavimo arba kartojimo būdas. Jie yra neįtikėtinai galingi, bet neturėtų būti naudojami “statinis” kodą. Turėkite omenyje, kad yra skirtumai tarp mixins, extends ir placeholder, kurie visi naudojasi „Sass“ kūrime.

„Mixins“ geriausia naudoti su dinaminėmis reikšmėmis, kurios perduodamos kodo pakeitimams. Pavyzdžiui, patikrinkite šį „Sass“ mišinį, kuris sukuria fono gradientą tarp dviejų spalvų.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Senosios naršyklės * / fonas: -moz-linijinis gradientas (viršutinis, $ top 0%, $ bottom 100%); / * FF3.6 + * / fonas: -webkit-gradientas (tiesinis, kairysis viršuje, kairėje apačioje, spalvų sustojimas (0%, $ top), spalvų stabdymas (100%, $ apačioje)); / * „Chrome“, Safari4 + * / fonas: -webkit-linijinis gradientas (viršutinis, $ top 0%, $ bottom 100%); / * „Chrome10 +“, „Safari5.1 + * / fonas: -o-linijinis gradientas (viršutinis, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / fonas: -ms-linijinis gradientas (viršutinis, $ top 0%, $ bottom 100%); / * IE10 + * / fonas: tiesinis gradientas (į apačią, $ top 0%, $ bottom 100%); / * W3C * / filtras: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

„Mixin“ turi dvi reikšmes: viršutinę spalvą ir apatinę spalvą. Galite parašyti skirtingus mišinius skirtingų tipų gradientams, kuriuose yra 3 arba 4+ skirtingos spalvos. Tai leidžia importuoti ir klonuoti „mixin“ kodą keičiant pasirinktinių parinkčių parametrus.

Pavyzdys iš atsakingo kodo atrodo taip:

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

Su „mixin“ susijusi „Sass“ vietos lankytoja, kuri pirmiausia naudinga su išplėstine direktyva. Tai, žinoma, yra sudėtingesnė nei mixins, tačiau tai gali būti būdas sujungti selektorius kartu be perrašymo per didelio kodo.

Nors „Sass“ turi tik vieną „@import“ metodą, aš pridėjau „mixins“ ir vietos žymenis, kad parodytumėte kodo lankstumą, kuris gali būti parašytas viename faile, bet bet kurioje vietoje.

Statydami importo struktūrą nepamirškite laikytis DRY kodavimo sąvokų (nesikartokite sau).

Pavadinimo konvencijos

Bendrosios taisyklės, susijusios su konvencijų pavadinimu, taikomos kintamiesiems, funkcijoms ir mišiniams. Pavadinant ką nors Sass, rekomenduojama atskyrimui naudokite visas raides su brūkšneliais.

Sass kodo sintaksė faktiškai grindžiama CSS gairių taisyklėmis. Štai keletas rekomenduojamų geriausios praktikos pavyzdžių:

• dvi (2) tarpai įtrauktos, nėra skirtukų
• idealiu atveju, 80 ar daugiau simbolių
• prasmingas erdvės naudojimas
• CSS operacijoms paaiškinti naudokite komentarus

Tai nėra reikalingo Sass kodo elementai. Tačiau šie pasiūlymai yra iš profesionalių kūrėjų, kurie nustatė, kad šios taisyklės suteikia vienodiausią kodavimo patirtį.

Bet kalbant apie paskyrimo konvencijas, jūs galite baigtis dviem skirtingomis struktūromis: viena Sass pavadinimais ir kita - CSS klasės pavadinimais. Kai kurie kūrėjai pageidauja BEM per Sass pasiūlymus. Nė vienas iš jų nėra daugiau ar mažiau teisingas; skiriasi nuo skirtingų veiklos procedūrų.

Problema ta, kad „BEM“ neperkelia „Sass“ kintamųjų ar mišinių, nes jie neturi bloko / elemento / modifikatoriaus (BEM) struktūros. Aš asmeniškai norėčiau naudoti „Sass“ pavadinimo konvencijas, bet jūs galite pabandyti ką nors iš „camelCase“ į savo vidinę sintaksę.

Organizuojant kintamuosius ir mišinius rekomenduojama suskirstykite juos pagal kategorijas, tada išvardykite juos abėcėlės tvarka. Tai leidžia redaguoti daug lengviau, nes tiksliai žinote, kur ką nors rasti.

Pavyzdžiui, norėdami pakeisti nuorodos spalvą, atidarykite savo kintamųjų failą (galbūt _variables.scss) ir suraskite spalvų kintamųjų sekciją. Tada suraskite nuorodą pagal pavadinimą (antraštės nuoroda, teksto nuoroda ir tt) ir atnaujinkite spalvą. Paprasta!

Norėdami sužinoti, kaip susisteminti Sass failų turinį, patikrinkite Fondo nustatymų failą.

 // Sklypų nustatymo fondas // ----------------------------- // Turinys: // // 1 Pasaulinis // 2. Lūžio taškai // 3. Tinklelis // 4. Pagrindinė tipografija // 5. Tipografijos pagalbininkai… // 1. Pasaulinis // --------- $ globalinis šrifto dydis: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // tt

Kita pavadinimo praktika yra susijusi su reaguojantys taškai. Pavadindami „Sass“ taškinius taškus, pabandykite vengti įrenginiams būdingų pavadinimų. Geriau rašyti pavadinimus, pvz., Mažus, med, lg ir xlg, nes jie yra vienas kito atžvilgiu.

Tai geriau vidaus ryšiams tarp lūžio taškų, bet taip pat puikiai tinka komandoms, kuriose kūrėjai gali nežinoti, kurie įrenginiai yra susiję vienas su kitu.

Kalbant apie vardus, jums rekomenduojama būti kuo konkretesni be papildomų ilgų kintamųjų. Tu turėtum priimti svetainių pavadinimus, kuriuos lengva prisiminti koduojant.

Pateikite konkrečias pavadinimų konvencijas, pvz., Spalvas, paraštes, šriftų rinkinius ir linijų aukščius. Ne tik galima greitai priminti vardus, bet ir tai palengvina darbą, kai rašote naujus kintamųjų pavadinimus, kurie turi atitikti esamą sintaksę.

Bet yra bauda tarp specifiškumo ir konvoliucijos. Praktika padės jums rasti tą liniją, o daugiau įsimintinų pavadinimų rašymas palengvins kodo kopijavimą į kitus projektus.

Lizdas ir kilimas

Šie du Sass metodai yra labai skirtingi, tačiau abu yra sugebėjimas būti piktnaudžiaujama, jei jis nėra naudojamas \ t.

Lizdavimas yra procesas pridedami selektoriai, įdėti kartu su įdėjimu, siekiant sukurti daugiau specifiškumo su mažiau kodų. „Sass“ turi lizdų vedlį, kuris iliustruoja kodavimo veiksmo pavyzdžius. Bet lengva nuvykti su lizdais. Jei esate pernelyg didelis, galite baigti kodą, kuris atrodo taip:

body div.content div.container … kūnas div.content div.container div.articles … kūnas div.content div.container div.articles> div.post … 

Pernelyg specifinis ir beveik neįmanoma perrašyti šio tipo kodo, kuris nulemia kaskadinių stilių lapų paskirtį.

Apsukite šį „SitePoint“ vadovą, kuriame rasite tris auksines lizdus:

• Niekada neviršykite daugiau nei 3 lygių.
• Įsitikinkite, kad CSS išvestis yra švari ir pakartotinai naudojama.
• Naudokite lizdą, kai tai yra prasminga, o ne kaip numatytoji parinktis.

Kūrėjas Josh Broton siūlo lizduoti, kai reikia, įtraukite likusį kaip bendrą sintaksės taisyklę.

Pasirinktuvo atkirpimas nesukels jokių CSS efektų. Bet jums bus lengviau nuvalyti Sass failą, nurodant, kurios klasės yra susijusios viena su kita.

Taip pat gali būti kilpos būti pernelyg daug, jei jis tinkamai netaikomas. Trys Sass kilpos yra @dėl, @ viskas, ir @each. Nenoriu eiti į išsamią informaciją apie tai, kaip jie visi dirba, bet jei jus domina, patikrinkite šį įrašą.

Vietoj to norėčiau padengti naudoti kilpas ir kaip jie veikia Sasse. Tai turėtų būti naudojama taupant laiko rašymo kodą, kuris gali būti automatizuotas. Pavyzdžiui, čia yra kodo fragmentas iš „Clubmate“ įrašo, kuriame rodomas „Sass“ kodas, po kurio nurodomas išvestis:

/ * Sass kodas * / @ for $ i nuo 1 iki 8 $ plotis: procentas (1 / $ i) .col - # $ i plotis: $ plotis;  / * išėjimas * / .col-1 plotis: 100%;.-2 plotis: 50%;.-3 plotis: 33,333%;.-4 plotis: 25%;  .col-5 plotis: 20%;. -6 plotis: 16,666%; .col-7 plotis: 14,285%; .col-8 plotis: 12,5%;

Šios stulpelių klasės gali būti naudojamos kartu su tinklelio sistema. Jūs netgi galite pridėti daugiau stulpelių arba pašalinti kai kuriuos tiesiog redaguodami kilpos kodą.

Kilpos turėtų ne Naudojamas selektoriaus parinktims arba savybėms kopijuoti; būtent tai yra mixins.

Be to, kai užklijuojate kažką, vadinamą „Sass“ žemėlapiais, kuriuose saugomi raktai: duomenų poros. Pažangūs naudotojai turėtų tai išnaudoti, kai tik įmanoma.

Tačiau reguliarios „Sass“ kilpos yra paprastos ir veiksmingos, kai kodo išvestis teikiama be pakartojimo. Geriausia priežastis naudoti kilpas yra su CSS savybės, kurios keičia duomenų išvestį.

Štai geras būdas patikrinti, ar jūsų kilpa yra naudinga: paklauskite savęs jei yra kokiu nors kitu būdu, norint išleisti reikiamą CSS, su mažiau kodų. Jei ne, kilpos sintaksė tikriausiai yra puiki idėja.

Jei kada nors supainiotumėte ar norite atsiliepti apie lizdus ar „Sass“ kilpas, turėtumėte rašyti klausimą į / r / sass / arba / r / css /, aktyvias Reddit bendruomenes su labai gerai žinomais „Sass“ kūrėjais.

Moduliavimas

Modulinio „Sass“ rašymo praktika yra absoliučiai būtina daugumai projektų (manau, kiekvienas projektas). Modulizacija yra procesas projekto suskirstymas į mažesnius modulius. Tai galima pasiekti Sass'e daliniai.

Modulinio „Sass“ idėja yra parašyti atskirus SCSS failus su konkrečiu tikslu, nukreipiančiu pasaulinį turinį (tipografiją, tinklus) arba puslapio elementus (skirtukus, formas).

„Sass“ modulio apibrėžimas yra gana aiškus ir pateikia labai konkretų pasiūlymą: modulio importavimas niekada neturi būti išvestas.

Visų modulių privalomo išėjimo idėja būtų optimizavimas. Vietoj to turėtumėte sukurti modulius atskirai ir skambinkite tik tiems, kuriems reikia. Modulius galima apibrėžti mišiniais arba funkcijomis, tačiau galima sukurti modulius, kuriuose yra ir selektorių.

Tačiau „Sass Way“ straipsnyje siūloma rašyti visus selektorius kaip „mixins“ ir juos skambinti tik kaip reikia. Nesvarbu, ar tai priimate, ar ne, yra jūsų pasirinkimas. Manau, kad tai priklauso nuo projekto dydžio ir patogumo tvarkant mišinius.

Cituodamas John Long'ą iš savo pareigų „The Sass Way“:

“Man, moduliai tapo pagrindiniais „Sass“ projektų vienetais arba pagrindiniais elementais.”

Jei tikrai ieškote „Sass“ rutinos, aš rekomenduoju eiti visiškai moduliniu. Pabandykite pastatyti beveik viską, kaip modulinę dalį, kuri bus įtraukta į pirminį CSS failą. Iš pradžių ši darbo eiga gali atrodyti bauginanti, tačiau ji yra prasmingesnė, ypač didelių projektų atveju.

Be to, daug lengviau kopijuoti modulius iš vieno projekto į kitą, kai jie yra atskiruose failuose. Lankstumas ir pakartotinai naudojamas kodas yra modulinės plėtros pagrindas.

Jei norite sužinoti daugiau apie „Sass“ modulius ir moduliavimo metodus, patikrinkite šiuos įrašus:

• CSS moduliai: Sveiki atvykę į ateitį
• Modulinio Sass privalumai ir trūkumai
• Modulinė CSS organizacija su SMACSS & SASS

Raskite savo tobulą darbo eigą

Kiekviena komanda ir individualus kūrėjas turi savo praktiką, kuri geriausiai veikia. Jūs turėtumėte priimti jums geriausiai tinkančią praktiką arba pasirinkti, kas geriausiai tinka jūsų komandai profesionaliai.

Taip pat apsvarstykite galimybę naudoti „Gulp“ arba „Grunt“ projektams automatizuoti ir koduoti savo kodą. Tai padės sutaupyti daug rankinio darbo, o automatikos įrankiai dabar neabejotinai yra gerosios patirties pavyzdys šiuolaikiniam frontendui.

Išsiaiškinkite atviro kodo bibliotekas, pvz., Fondo SCSS „GitHub“, kad sužinotumėte daugiau apie kitų bibliotekų naudojamą geriausią praktiką.

Geriausios praktikos dalykas yra tai, kad jie iš tikrųjų patobulina jūsų darbą, tačiau yra daug alternatyvų. Tiesiog pabandykite ir pažiūrėkite, kaip jie jaučiasi. Jūs visada mokotės, kad jūsų geriausia praktika per 5 metus galėtų sparčiai keistis.

Vienas galutinis pasiūlymas, kurį turiu pateikti visam Sass procesui, yra priimti aiškius sprendimus. Parašykite kodą, kuris palengvina jūsų darbą. Negalima pernelyg apsunkinti projekto, jei yra paprastesnis būdas tai padaryti.

Sass yra skirtas CSS tobulinimo patirties stiprinimui dirbti su aiškia ir geriausia praktika gauti geriausią patirtį.

Apvyniojimas

Sass darbo eigos perkrovos gali būti ištaisytos kodavimo stilių ir geriausios praktikos. Aš apibūdinau kelis pasiūlymus dėl šio pranešimo, kurį pateikė „Sass“ tinklaraščiai ir profesionalūs kūrėjai.

Geriausias būdas sužinoti daugiau yra taikyti šias praktikas į savo darbo eigą ir pamatyti, kas veikia. Laikui bėgant pamatysite, kad kai kurios veiklos yra naudingesnės nei kitos, tokiu atveju turėtumėte laikykitės bet kokių darbų ir palaukite, kas ne.

Peržiūrėkite šias nuorodas, kad sužinotumėte daugiau patarimų ir geriausios praktikos „Sass“ kūrimui:

• Sasso gairės
• Mūsų Sass vizija
• 8 patarimai, kurie padės jums gauti geriausią iš Sass
• Išplėtimas „Sass“ be kūrimo
• „Sass“ geriausios praktikos pavyzdžiai - daugiau nei 3 lygių sodinimas