Sass Best Practices Nõuanded ja vahendid arendajatele

Sarnaselt sellele, kuidas jQuery murrangutas vanilli JavaScript, Sass on muutnud vanilje CSS-i. Enamik arendajaid, kes õpivad Sassi, nõustuvad, et nad ei taha kunagi tagasi minna. Paljud nõustuvad ka sellega, et suurim probleem uute arendajatega on tee nad kasutavad Sassit, mitte Sassit.

Ma olen pesnud veebi ja koostasin selle artikli parimad tavad laiendatava ja korduvkasutatava Sass-koodi kirjutamiseks. Ettepanekud on minu enda arvamustest ja usaldusväärsetest veebisaitidest nagu Sassi juhised.

Te ei pea kindlasti kõiki neid funktsioone oma töövoogu rakendama. Kuid tasub mõelda vähemalt nendele ideedele ja kaaluda võimalikke eeliseid.

Faili organisatsioon

Parim koht alustamiseks Sassiga on failide korraldamine. Kui olete juba moodulikoodiks, siis peaksite mõistma impordi väärtust ja osalisi (rohkem neid hiljem).

Aga nüüd vaadake seda faili struktuuri näidet DoCSSa-st. Olen selle failistruktuuri uuesti loonud:

See on vaid soovitus ja see on üks paljudest viisidest, kuidas faile korraldada. Te võite leida teisi meetodeid, mis kasutavad erinevaid kataloogistruktuure “globaalsed” kogu SCSS ja “lehekülgi” lehekülje spetsiifilise SCSS jaoks.

Läbime selle soovitatud organisatsiooni stiili läbi, et uurida iga kausta eesmärki:

• / globaalid - sisaldab Sass-faile, mida rakendatakse kogu saidi ulatuses nagu tüpograafia, värvid ja võrgud
• / komponendid - sisaldab Sass-faile komponentide stiilis nagu nupud, tabelid või sisestusväljad
• / sektsioonid - sisaldab Sass-faile, mis on mõeldud teatud lehekülgedele või lehekülgedele (võivad töötada paremini / komponente / kausta)
• / utils - sisaldab kolmanda osapoole kommunaalteenuseid nagu Normaliseerimine, mida saab dünaamiliselt värskendada selliste tööriistadega nagu Bower.
• main.scss - peamine Sass-fail, mis impordib kõik teised.

See on lihtsalt alguspunkt ja seal on piisavalt ruumi oma ideedega laiendamiseks.

Kuid olenemata sellest, kuidas soovite oma SCSS-i korraldada, on oluline omage mingit organisatsiooni eraldi faili (või kausta) jaoks sellistele raamatukogudele nagu Normalize, mida tuleb uuendada, ja Sass'i osaliste komponentide jaoks teie projekti jaoks.

Sassi osalised on kaasaegsete parimate tavade jaoks väga olulised. Neid on väga soovitanud Zurbi disainimeeskond ja paljud teised professionaalsed frontendiarendajad.

Siin on tsitaat Sass'i veebisaidilt, kus selgitatakse osalisi:

“Saate luua osalisi Sass-faile, mis sisaldavad vähe CSS-fragmente, mida saate lisada teistesse Sass-failidesse. See on suurepärane võimalus modifitseerige oma CSS ja aidake hoida asju kergemini hooldatavana. Osaline on lihtsalt Sass-fail, mille nimeks on juhtiv allakriips. Sa võid seda nimetada _partial.scss. Allakriips võimaldab Sassil teada, et fail on ainult osaline fail ja seda ei tohiks genereerida CSS-failina. Sass'i osalisi kasutatakse koos @import direktiivi.”

Vaadake ka neid teisi postitusi seoses Sass-failistruktuuriga:

• Kuidas ma oma Sass projektid üles ehitatakse
• Esteetiline Sass: arhitektuur ja stiili organisatsioon
• Kataloogistruktuurid, mis aitavad teil koodi säilitada

Impordi strateegiad

Sassi impordi ja osaliste väärtuse kohta ei saa öelda piisavalt. Koodikorraldus on võtmeks just töötava impordistruktuuri ja töövoo saamiseks.

Parim koht alustamiseks on ülemaailmne leht, mis sisaldab impordi, muutujaid ja segusid. Paljud arendajad eelistavad eraldada muutujad ja segunemised, kuid see läheb semantiliseks.

Pea meeles, et mixins on Sass-koodi importimise või pigem paljundamise viis. Nad on uskumatult võimas, kuid neid ei tohiks kasutada “staatiline” kood. Pidage meeles, et mikside, laienduste ja kohanäitajate vahel on erinevused, mis kõik kasutavad Sassi arendamisel.

Segusid kasutatakse kõige paremini koos dünaamiliste väärtustega, mis kantakse koodimuutustesse. Näiteks vaadake seda Sass mixinit, mis loob taustavärvi kahe värvi vahel.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Vana brauserid * / taust: -moz-lineaarne gradient (ülemine, $ top 0%, $ bottom 100%); / * FF3.6 + * / taust: -webkit-gradient (lineaarne, vasakul üleval, vasakul all, värvipeatus (0%, $ top), värvipeatus (100%, $ alt)); / * Chrome, Safari4 + * / taust: -webkit-lineaarne gradient (ülemine, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / taust: -o-lineaarne gradient (ülemine, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / taust: -ms-lineaarne gradient (ülemine, $ top 0%, $ bottom 100%); / * IE10 + * / taust: lineaarne gradient (alumisse, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin võtab kaks väärtust: ülemine värv ja alumine värv. Sa võid kirjutada erinevaid segusid erinevat tüüpi gradientide jaoks, mis sisaldavad 3 või 4 + erinevat värvi. See võimaldab importida ja kloonida segamiskoodi, muutes kohandatud valikute parameetreid.

Code Responsiblei näide näeb välja selline:

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

Seoses seguga on Sass'i kohatäitja, mis on peamiselt kasulik laiendusdirektiiviga. See on küll keerulisem kui mixins, kuid see võib olla võimalus kombineerige selektorid ilma liigse koodi ümberkirjutamiseta.

Kuigi Sassil on ainult üks @import-meetod, olen lisanud mixins'i ja kohahoidjad, et näidata koodi, mida saab kirjutada ühes failis, kuid mis on kõikjal.

Impordistruktuuri ehitamisel pidage meeles, et järgite DRY kodeerimise kontseptsioone (ärge kordage ennast).

Nimetavad konventsioonid

Konventsioonide nimetamise üldeeskirjad kehtivad muutujate, funktsioonide ja segude kohta. Kui Sassis midagi nimetatakse, on soovitatav eraldamiseks kasutage kõiki väiketähti kriipsudega.

Sass-koodi süntaks põhineb tegelikult CSS-i juhiste reeglitel. Siin on mõned soovitatavad parimad tavad, mida meeles pidada:

• kaks (2) tühikut, vahekaardid puuduvad
• ideaaljuhul 80-kohalised suured jooned või vähem
• ruumi sisukas kasutamine
• CSS-operatsioonide selgitamiseks kasutage kommentaare

Need pole kehtiva Sass-koodi jaoks vajalikud elemendid. Kuid need soovitused pärinevad professionaalsetest arendajatest on leidnud, et need reeglid pakuvad kõige ühtlasemat kodeerimiskogemust.

Kuid seoses tavade nimetamisega võib teil olla kaks erinevat struktuuri: üks Sass nimedele ja teine ​​CSS klassi nimede jaoks. Mõned arendajad eelistavad BEM-i üle Sassi soovituste üle. Kumbki neist ei ole enam või vähem õige; lihtsalt erinevad erinevate toimimisviisidega.

Probleem seisneb selles, et BEM ei kanna hästi Sassi muutujaid või segunemisi, sest neil ei ole ploki / elemendi / modifikaatori (BEM) struktuuri. Mina isiklikult eelistan kasutada Sass'i nimetuskonventsioone, kuid sa võid proovida midagi CamelCase'ist oma sisemisele süntaksile.

Muutujate ja segude korraldamisel on soovitatav jagada need kategooriate kaupa, seejärel loetleda need tähestikulises järjekorras. See muudab redigeerimise palju lihtsamaks, sest tead täpselt, kust midagi leida.

Näiteks linki värvi muutmiseks avage oma muutujafail (võib-olla _variables.scss) ja leidke värvmuutujate osa. Seejärel leidke link nime järgi (päise link, tekstilink jne) ja värvi värskendage. Lihtne!

Et saada ideed, kuidas Sass-failide sisukorda saaks struktureerida, vaadake fondi seadistustefaili.

 // Saitide seadete sihtasutus // ----------------------------- // Sisukord: // // 1 Globaalne // 2. Puhkepunktid // 3. Võrgustik // 4. Baaskirjeldus // 5. Tüpograafia abilised… // 1. Globaalne // --------- $ globaalne-font-suurus: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // jne

Teine nimetuspraktika puudutab reageerivad punktid. Sassi murdepunktide nimetamisel proovige vältida seadmepõhiseid nimesid. On parem kirjutada selliseid nimesid nagu väike, med, lg ja xlg, sest nad on üksteise suhtes.

See on parem katkiste punktide vaheliste sisemiste suhete jaoks, aga ka suurte meeskondade jaoks, kus arendajad ei pruugi teada, millised seadmed omavahel seotud.

Nagu nimede tegelik allalaadimine, soovitame teil olema võimalikult spetsiifilised ilma pikemate muutujateta. Sa peaksid vastu võtta veebilehe nimesid, mida on lihtne meeles pidada kodeerimise ajal.

Andke spetsiifilised nimetusviisid kõikidele värvidele, marginaalidele, fondi korstnatele ja joonekõrgustele. Mitte ainult ei saa nimesid kiiresti meelde tuletada, vaid seda muudab teie töö lihtsamaks, kui kirjutate uusi muutujaid, mis peavad vastama olemasolevale süntaksile.

Aga seal on trahvi joon spetsiifilisuse ja konvolutsiooni vahel. Praktika aitab teil seda rida leida ja rohkem meeldejäävate nimede kirjutamine lihtsustab koodi kopeerimist teistesse projektidesse.

Nesting ja silmus

Need kaks Sassi tehnikat on tegevuses väga erinevad, kuid mõlemal on võimet kuritarvitada, kui seda ei kasutata hoolikalt.

Pesitsemine on protsess lisades selektiivid, mis on üksteise peale sisestatud, et luua rohkem spetsiifilisust vähem koodiga. Sassil on pesitsemise juhend, mis illustreerib näpunäiteid tegevuses olevate koodide kohta. Aga pesitsemisega on lihtne kaasa võtta. Kui te olete ülearune, võite lõpetada koodi, mis näeb välja selline:

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

Liiga spetsiifiline ja peaaegu võimatu ülekirjutada seda tüüpi kood kaotab kaskaaditabelite eesmärgi.

Selle SitePointi juhendi koorimine sisaldab kolme kuldset reeglit pesitsemiseks:

• Mitte kunagi minna rohkem kui 3 taset sügavale.
• Veenduge, et CSS-väljund on puhas ja korduvkasutatav.
• Kasutage pesitsemist, kui see on mõistlik, mitte vaikimisi.

Arendaja Josh Broton soovitab pesitseda, kui see on vajalik, taandage ülejäänud kui üldine süntaksireegel.

Valijate taandamine ei põhjusta CSS-efekte. Aga teil on lihtsam aeg oma Sass-faili nülgida, märkides, millised klassid on üksteisega seotud.

Samuti võivad olla silmused kui neid ei rakendata korralikult, tuleb neid üle kasutada. Kolm Sass-silmust on @for, @vahe, ja @iga. Ma ei lähe üksikasjalikult teada, kuidas nad kõik töötavad, aga kui olete huvitatud, vaadake seda postitust.

Selle asemel tahaksin katta silmuste kasutamise eesmärk ja kuidas nad Sassis toimivad. Neid tuleks kasutada automatiseeritava aja kirjutamise koodi salvestamiseks. Näiteks siin on Clubmate'i postituse koodilõik, mis näitab mõningat Sass-koodi, millele järgneb väljund:

/ * Sassi kood * / @ for $ i 1 kuni 8 $ laius: protsent (1 / $ i) .col - # $ i laius: $ laius;  / * väljund * / .col-1 laius: 100%; .col-2 laius: 50%;.-3 laius: 33,333%;.-4 laius: 25%;  .kol-5 laius: 20%;. -6 laius: 16,666%; .col-7 laius: 14,285%; .col-8 laius: 12,5%;

Neid veeruklasse saab kasutada koos võrgusüsteemiga. Võite isegi lisada rohkem veerge või eemaldada mõned lihtsalt silmuskoodi redigeerimise teel.

Silmus peaks mitte kasutada selektorite valikute või omaduste dubleerimiseks; see on see, mida mixins on mõeldud.

Ka siis, kui loendate, on midagi, mida nimetatakse Sass-kaardideks, mis salvestavad võtme: andmete paarid. Täiustatud kasutajad peaksid neid võimaluste piires ära kasutama.

Kuid regulaarsed Sass-lingid on lihtsad ja tõhusad, et pakkuda koodi väljundit ilma korduseta. Silmade kasutamise parim põhjus on CSS-i omadused, mis muudavad andmeedastust.

Siin on hea võimalus kontrollida, kas teie silmus on kasulik: küsi endalt kui teil on mõni muu võimalus, et CSS-i väljastada vähem koodiridadega. Kui mitte, siis on silmuse süntaks ilmselt suurepärane idee.

Kui sa oled kunagi segaduses või soovivad tagasiside pesitsus- või Sass-ahelate kohta, peaksite postitama küsimuse kas / r / sass / või / r / css /, aktiivsete Reddit-kogukondadega väga teadlike Sass-arendajatega.

Modulariseerimine

Modulaarse Sassi kirjutamise praktika on enamiku projektide jaoks absoluutselt vajalik (ma väidan, et iga projekt). Modulariseerimine on projekti hajutamine väiksemateks mooduliteks. Seda saab teha Sassis kasutades osalised.

Modulaarse Sass'i idee on kirjutada individuaalsed SCSS-failid kindla eesmärgiga, mis on suunatud globaalsele sisule (tüpograafia, võrgud) või leheküljeelementidele (vahekaardid, vormid).

Sassi mooduli määratlus on üsna selge ja teeb väga konkreetse soovituse: mooduli importimine ei tohiks kunagi väljastada koodi.

Kõikide moodulite kohustusliku väljundi idee oleks optimeerimiseks õudusunenägu. Selle asemel peaksite mooduleid eraldi looma helistage ainult neile, keda vajate. Mooduleid saab defineerida segude või funktsioonide abil, kuid on võimalik luua ka mooduleid, mis sisaldavad ka selektorit.

Sass Way artiklis aga soovitatakse kirjutada kõik valijad segudeks ja kutsuda neid ainult vastavalt vajadusele. Kas olete selle vastu võtnud või mitte, on lõppkokkuvõttes teie valik. Ma arvan, et see sõltub projekti suurusest ja teie mugavusest segude käitlemisel.

John Longi tsitaat oma Sass Way'i postitusest:

“Minu jaoks on moodulid muutunud minu Sass projektide peamisteks üksusteks või plokkideks.”

Kui otsite Sass'i rutiini, siis soovitan minna täielikult moodulisse. Proovige ehitada peaaegu kõike modulaarseks osaliseks, mis kuulub esmase CSS-faili hulka. Algul võib see tööprotsess tunduda hirmuäratav, kuid see on mõttekam, eriti suurte projektide puhul.

Lisaks on palju lihtsam kopeerida mooduleid ühest projektist teise, kui nad asuvad eraldi failides. Paindlikkus ja korduvkasutatav kood moodulite arendamise nurgakivid.

Lisateabe saamiseks Sass moodulite ja modulariseerimistehnikate kohta vaadake need postitused:

• CSS-moodulid: Tere tulemast tulevikku
• Modulaarse Sassi plussid ja miinused
• Modulaarne CSS organisatsioon koos SMACSS & SASSiga

Leia oma täiuslik töövoog

Igal meeskonnal ja individuaalsel arendajal on oma tavad, mis töötavad kõige paremini. Peaksite kasutama oma isiklikult parimaid tavasid või valima need, mis teie meeskonnale kõige paremini sobivad professionaalselt.

Samuti kaaluge Gulp'i või Grunt'i kasutamist projekti automatiseerimiseks ja koodi minigeerimiseks. See säästab palju tööjõudu ja automaatika tööriistad on nüüd kahtlemata osa kaasaegse esiplaani arendamise parimatest tavadest.

Skimige läbi avatud lähtekoodiga raamatukogud nagu fondi SCSS GitHubis, et saada rohkem teavet teiste raamatukogude parimate tavade kohta.

Parimate tavade puhul on see, et nad tõesti parandavad teie tööd enamasti, kuid on palju alternatiive. Lihtsalt proovige asju ja vaadake, kuidas nad tunnevad. Õpid alati, et teie parimad tavad viie aasta jooksul kiiresti muutuda.

Üks lõplik ettepanek kogu Sassi protsessi jaoks on teha otsuseid selgelt. Kirjutage kood, mis muudab teie töö lihtsamaks. Ärge keerake projekti liiga keeruliseks, kui seda on lihtsam teha.

Sass on mõeldud CSS-i arenduskogemuse parandamiseks töötada selguse ja parimate tavade abil saada parim võimalik kogemus.

Tõmba otsad kokku

Sassi töövoo ülekoormust saab korrigeerida koodi stiilide ja parimate tavade järgimise teel. Ma olen kirjeldanud Sass'i blogide ja professionaalsete arendajate antud postituses käputäis ettepanekuid.

Parim viis, kuidas rohkem teada saada, on rakendada neid tavasid oma töövoo ja vaata, mis toimib. Aja jooksul leiad, et mõned tegevused on kasulikumad kui teised, millisel juhul peaksite seda tegema hoidke mis tahes tööd ja laske see, mis ei ole.

Vaadake neid linke, et leida rohkem nõuandeid ja parimaid tavasid Sassi arendamiseks:

• Sassi suunised
• Visioon meie Sassile
• 8 Näpunäiteid, mis aitavad teil Sassilt parimaid tulemusi saada
• Laiendamine Sassis ilma segaduseta
• Sass Best Practices - rohkem kui 3 taseme sügavale pesemine