Sass Best Practices Nasveti in orodja za razvijalce

Podobno kot je jQuery revolucioniral vanilji JavaScript, Sass je revolucioniral vanilin CSS. Večina razvijalcev, ki se naučijo Sassa, se strinja, da se nikoli ne želijo vrniti. Mnogi se tudi strinjajo, da je največji problem z novimi razvijalci poti uporabljajo Sass, ne Sass.

Preiskal sem splet in sestavil ta članek najboljše prakse za pisanje razširljive in ponovno uporabljive kode Sass. Predlogi izhajajo iz lastnih mnenj in zaupanja vrednih spletnih mest, kot so smernice Sass.

Vsekakor vam ni treba izvajati vseh teh funkcij v svojem delovnem procesu. Vendar je vredno vsaj razmisliti o teh zamislih in razmišljati o možnih koristih.

Organizacija datoteke

Najboljše mesto za začetek razvoja Sassa je organizacija datotek. Če ste že v modularni kodi, morate razumeti vrednost uvoza in delcev (več o tem kasneje).

Ampak za zdaj samo poglejte na to strukturo datotek primer iz DoCSSa. Ustvaril sem to strukturo datotek, ki jo lahko vidite spodaj:

To je samo predlog in je eden od mnogih načinov za organiziranje datotek. Najdete lahko druge metode, ki uporabljajo različne strukture map “globali” za celotno območje SCSS in “strani” za SCSS za posamezne strani.

Sprehodimo se skozi ta predlagani slog organizacije in preučimo namen vsake mape:

• / globals - vsebuje datoteke Sass, ki se uporabljajo za celotno spletno mesto, kot so tipografija, barve in omrežja
• / komponente - vsebuje datoteke Sass s slogi komponent, kot so gumbi, tabele ali vnosna polja
• / odseki - vsebuje datoteke Sass, ki so namenjene določenim stranem ali območjem na strani (morda bo bolje združena v mapo / components /)
• / utils - vsebuje pripomočke tretjih oseb, kot je Normalize, ki jih je mogoče dinamično posodabljati z orodji, kot je Bower.
• main.scss - primarna datoteka Sass v korenski mapi, ki uvaža vse ostale.

To je samo osnovna izhodiščna točka in veliko prostora za razširitev s svojimi idejami.

Ampak ne glede na to, kako se odločite za organizacijo vašega SCSS, je ključnega pomena, da ste imajo neko organizacijo z ločeno datoteko (ali mapo) za knjižnice, kot je Normalize, ki jo je treba posodobiti, ter komponente v delih Sass za vaš projekt.

Sas parcials so bistvenega pomena za moderne najboljše prakse. To so zelo priporočljivi Zurbovi oblikovalski ekipi in številni drugi profesionalni razvijalci.

Tukaj je citat s spletnega mesta Sass, ki pojasnjuje delce:

“Ustvarite lahko delne datoteke Sass, ki vsebujejo majhne odrezke CSS, ki jih lahko vključite v druge datoteke Sass. To je odličen način modularizirajte CSS in pomagajte ohranjati stvari lažje. Delni je preprosto datoteka Sass, imenovana z vodilno spodnjo črko. Lahko bi ga poimenoval nekaj podobnega _partial.scss. Podčrtaj omogoča Sassu vedeti, da je datoteka le delna datoteka in da ne sme biti ustvarjena v datoteki CSS. Sas parcials se uporabljajo z @import direktive.”

Oglejte si tudi te druge objave o strukturi datoteke Sass:

• Kako strukturiram moje Sass projekte
• Estetska Sass: Organizacija arhitekture in stila
• Strukture imenika, ki vam pomagajo ohraniti kodo

Uvozne strategije

Za vrednost uvoza in delcev Sass ni dovolj. Organizacija kode je ključna za vzpostavitev strukture uvoza in poteka dela, ki deluje.

Najboljše mesto za začetek je globals list, ki vsebuje uvoz, spremenljivke in kombinacije. Mnogi razvijalci raje ločijo spremenljivke in kombinacije, vendar se to nanaša na semantiko.

Ne pozabite, da so miksini način uvoza ali bolj podvajanja kode Sass. Neverjetno so močni, vendar jih ne bi smeli uporabljati “statično” Koda. Ne pozabite, da obstaja razlika med mixins, extends in ogradami, ki se uporabljajo v razvoju Sassa.

Mixins se najbolje uporabljajo z dinamičnimi vrednostmi, ki se prenesejo v mixin za spremembe kode. Oglejte si na primer Sass mixin, ki ustvarja gradient ozadja med dvema barvama.

@mixin linearGradient ($ top, $ bottom) ozadje: $ top; / * Stari brskalniki * / ozadje: -moz-linear-gradient (top, $ top 0%, $ bottom 100%); / * FF3.6 + * / ozadje: -webkit-gradient (linearno, levo zgoraj, levo spodaj, barvno stop (0%, $ top), barvno stop (100%, $ bottom)); / * Chrome, Safari4 + * / ozadje: -webkit-linear-gradient (vrh, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / ozadje: -o-linearno-gradient (top, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / ozadje: -ms-linear-gradient (vrh, $ top 0%, $ bottom 100%); / * IE10 + * / ozadje: linearno gradient (do dna, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin ima dve vrednosti: zgornjo barvo in spodnjo barvo. Za različne tipe gradientov, ki vsebujejo 3 ali 4 različne barve, lahko napišete različne mešanice. To vam omogoča uvoz in kloniranje mixin kode, medtem ko spreminjate parametre za možnosti po meri.

Primer iz kodeksa odgovarja izgleda takole:

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

V zvezi z mixin je Sassova rezerva, ki je primarno uporabna z direktivo za razširitev. Res je bolj zapleten kot mešanice, vendar je to lahko način Združite selektorje skupaj, ne da bi ponovno zapisovali odvečno kodo.

Medtem ko ima Sass samo eno @import metodo, sem vključil mixins in placeholder, da prikažem prilagodljivost kode, ki jo lahko zapišemo v eni datoteki, vendar jo vključimo kjerkoli.

Ko gradite strukturo uvoza, ne pozabite slediti konceptom kodiranja DRY (Ne ponavljajte se).

Konvencije o poimenovanju

Splošna pravila za konvencije poimenovanja veljajo za spremenljivke, funkcije in kombinacije. Pri imenovanju ničesar v Sassu je priporočljivo uporabite vse male črke z črtami za ločevanje.

Sintaksa kode Sass dejansko temelji na pravilniku za smernice CSS. Nekaj ​​priporočenih najboljših praks, ki jih morate upoštevati:

• dve (2) presledki, brez zavihkov
• idealno, 80-mestne široke črte ali manj
• smiselna uporaba presledka
• uporabite komentarje, da pojasnite CSS operacije

To niso zahtevani elementi za veljavno kodo Sass. Toda ti predlogi prihajajo od profesionalnih razvijalcev, ki ugotovili, da ta nabor pravil zagotavlja najbolj enotno izkušnjo kodiranja.

Toda v zvezi s konvencijami poimenovanja lahko končate z dvema različnima strukturama: eno za imena Sass in drugo za imena razredov CSS. Nekateri razvijalci se raje odločajo za BEM nad predlogi Sassa. Niti ena ni več ali manj pravilna; različni operativni postopki.

Problem je v tem, da BEM ne prenaša dobro na Sass spremenljivke ali mixins, ker nimajo strukture block / element / modifier (BEM). Osebno raje uporabljam konvencije o poimenovanju Sass, vendar lahko poskusite vse od camelCase do lastne interne skladnje.

Pri organiziranju vaših spremenljivk in kombinacij priporočamo razdelite jih po kategorijah, nato pa jih navedite po abecednem vrstnem redu. Zaradi tega je urejanje veliko lažje, ker natančno veste, kje najti nekaj.

Če želite na primer spremeniti barvo povezave, lahko odprete datoteko spremenljivk (morda _variables.scss) in poiščite razdelek za barvne spremenljivke. Nato poiščite povezavo po imenu (povezava glave, besedilna povezava itd.) In posodobite barvo. Enostavno!

Da bi dobili idejo o tem, kako lahko strukturirate kazalo vsebine za vaše datoteke Sass, si oglejte datoteko za nastavitve Fundacije.

 // Fundacija za nastavitve mest // ----------------------------- // // Vsebina: // // 1 Globalna // 2. točke prekinitve // ​​3. Mreža // 4. Osnovna tipografija // 5. Pomočniki tipografije… // 1. Globalna // --------- $ globalna velikost pisave: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // itd

Druga praksa poimenovanja se nanaša na odzivne meje. Ko imenujete točke prekinitve Sass, se izogibajte imenam, ki so specifična za napravo. Bolje je napisati imena, kot so mala, med, lg in xlg, ker so med seboj.

To je bolje za notranje odnose med prekinitvenimi točkami, ampak tudi za ekipe, kjer razvijalci morda ne vedo, katere naprave so med seboj povezane.

Kar se dejansko nanaša na imena, je priporočljivo, da vas biti čim bolj specifični brez izjemno dolgih spremenljivk. Moral bi sprejmejo konvencije poimenovanja na ravni spletnega mesta, ki jih je enostavno zapomniti med kodiranjem.

Podajte posebne konvencije za poimenovanje za vse, kot so barve, robovi, nizi pisav in višine črte. Ne samo, da se lahko imena hitro spomnijo, ampak tudi omogoča lažje delo pri pisanju novih imen spremenljivk, ki se morajo ujemati z obstoječo skladnjo.

Ampak tam je meja med specifičnostjo in konvolucijo. Praksa vam bo pomagala pri iskanju te vrstice, pisanje imen, ki si jih zapomnite, pa bo olajšalo kopiranje kode v druge projekte.

Gnezda in zanke

Ti dve Sassovi tehniki sta zelo različni v delovanju, vendar imata obe sposobnost zlorabe, če se ne uporabljajo preudarno.

Gnezdenje je proces dodajanje selektorjev, ugnezdenih skupaj, z ustvarjanjem več specifičnosti z manj kode. Sass ima gnezditveni vodnik, ki ponazarja primere gnezdenja kode v akciji. Toda z gnezdenjem se lahko enostavno odnesete. Če ste preobčutljivi, lahko dobite kodo, ki izgleda takole:

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

Ta vrsta kode je preveč specifična in skoraj nemogoče prepisati, ker ne uspe nameniti kaskadnih slogovnih slogov.

Če si ogledate ta SitePointov vodnik, boste našli tri zlata pravila za gnezdenje:

• Nikoli ne gredo več kot 3 ravni globoko.
• Zagotovite, da je izhod CSS čist in ponovno uporabljiv.
• Uporabite gnezdenje, kadar je to smiselno, ne kot privzeto možnost.

Razvijalec Josh Broton predlaga, da se gnezdenje po potrebi izvede, da se ostalo umakne kot splošno pravilo skladnje.

Zamikanje izbirnikov ne bo povzročilo kaskadnih učinkov CSS. Toda lažje boste posneli datoteko Sass, ki bo natančno določila, kateri razredi se med seboj nanašajo.

Zanke lahko tudi če se ne uporablja pravilno. Tri Sass zanke so @for, @medtem, in @each. Ne bom se spuščal v podrobnosti o tem, kako vsi delujejo, ampak če vas zanima, si oglejte to delovno mesto.

Namesto tega bi rad pokril namen uporabe zank in kako delujejo v Sassu. Te je treba uporabiti za prihranek časa pri pisanju kode, ki jo je mogoče avtomatizirati. Tukaj je na primer odrezek kode iz sporočila Clubmate, ki prikazuje nekaj kode Sass, ki ji sledi izhod:

/ * Sass koda * / @ za $ i od 1 do 8 $ width: percent (1 / $ i) .col - # $ i width: $ width;  / * izhod * / .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%;

Ti razredi stolpcev se lahko uporabljajo v povezavi z omrežnim sistemom. Lahko bi celo dodali več stolpcev ali odstranili nekaj samo z urejanjem kode zanke.

Zanke treba ne uporablja se za podvajanje selektorjev ali lastnosti izbirnika; za to so miksini.

Tudi pri zankanju obstaja nekaj, kar se imenuje Sass maps, ki shranjujejo pare podatkov: vrednost. Napredni uporabniki bi jih morali izkoristiti, kadar koli je to mogoče.

Toda navadne zanke Sass so preproste in učinkovite pri zagotavljanju kode brez ponovitve. Najboljši razlog za uporabo zank je z Lastnosti CSS, ki spreminjajo izhodne podatke.

Tukaj je dober način, da preverite, ali je vaša zanka v pomoč: vprašajte se če obstaja kakšen drug način za izpis CSS, ki ga potrebujete, z manj vrsticami kode. Če ne, potem je sintaksa zanke verjetno odlična ideja.

Če ste kdaj zmedeni ali želite povratne informacije o gnezdenju ali Sass zankami, morate objaviti vprašanje v / r / sass / ali / r / css /, aktivnih redditskih skupnostih z zelo razvitimi razvijalci Sassa.

Modularizacija

Praksa pisanja modularnih Sass je absolutna nujnost za večino projektov (trdim, vsak projekt). Modularizacija je proces razčlenitev projekta na manjše module. To lahko dosežete z uporabo Sassa delni.

Ideja modularnega Sassa je pisanje posameznih datotek SCSS s posebnim namenom, ki cilja na globalno vsebino (tipografija, omrežja) ali elemente strani (zavihki, obrazci)..

Definicija modula Sass je precej jasna in daje zelo specifičen predlog: uvoz modula ne sme nikoli izpisati kode.

Zamisel o obveznih rezultatih za vse module bi bila nočna mora za optimizacijo. Namesto tega morate izdelati module posamično in pokličite samo tiste, ki jih potrebujete. Module je mogoče definirati z mešanicami ali funkcijami, možno pa je izdelati tudi module, ki vsebujejo selektorje.

Vendar pa članek Sass Way predlaga pisanje vseh selektorjev kot mešanic in samo klicanje po potrebi. Ali boste to sprejeli ali ne, je na koncu vaša izbira. Mislim, da je odvisno od velikosti projekta in vašega udobja pri ravnanju z mešanicami.

Citiram Johna Longa iz njegovega mesta na The Sass Way:

“Zame so moduli postali osnovne enote ali gradniki mojih projektov Sass.”

Če res iščete rutino Sass, vam priporočam, da ste popolnoma modularni. Poskusite zgraditi skoraj vse kot modularni del, ki se vključi v primarno datoteko CSS. Sprva se lahko ta potek dela zdi zastrašujoč, vendar je smiseln v obsežnejšem obsegu - zlasti pri velikih projektih.

Poleg tega je veliko lažje kopirati module iz enega projekta v drugega, če se nahajajo v ločenih datotekah. Prožnost in kodo za večkratno uporabo modularni razvoj.

Če želite izvedeti več o modulih Sass in tehnikah modularnosti, si oglejte te objave:

• CSS moduli: Dobrodošli v prihodnost
• Za in proti Modular Sass
• Modularna organizacija CSS s SMACSS in SASS

Poiščite svoj popoln delovni tok

Vsaka ekipa in posamezni razvijalec imata svoje lastne prakse, ki najbolje delujejo. Sprejeti bi morali prakse, ki najbolje delujejo za vas osebno, ali se odločite, da boste sprejeli tiste, ki so profesionalno najboljši za vašo ekipo.

Prav tako razmislite o uporabi Gulp ali Grunt za avtomatizacijo projekta in zmanjšanje kode. To bo prihranilo veliko ročnega dela, orodja za avtomatizacijo pa so nedvomno del najboljših praks za sodoben razvoj frontendov.

Preskočite po odprtokodnih knjižnicah, kot je SCSS Fundacije na GitHubu, da izveste več o najboljših praksah drugih knjižnic.

Najboljša praksa je, da večino časa resnično izboljšajo vaše delo, vendar obstaja veliko možnosti. Preizkusite stvari in poglejte, kako se počutijo. Vedno se boste učili, da se bodo vaše najboljše prakse hitro spremenile v obdobju 5 let.

Končni predlog, ki ga imam za celoten proces Sass je, da sprejemati odločitve z jasnostjo v mislih. Napišite kodo, ki vam olajša delo. Ne pretiravajte s projektom, če obstaja enostavnejši način.

Sass je namenjen izboljšanju izkušenj CSS razvoja delo z jasnostjo in najboljšimi praksami da bi dobili najboljšo možno izkušnjo.

Zaviti

Preobremenjenost v delovnem procesu Sass se lahko popravi s spreminjanjem slogov kode in upoštevanjem najboljših praks. V tem prispevku sem navedel nekaj predlogov, ki so jih poslali Sassovi blogi in profesionalni razvijalci.

Najboljši način, da se naučite več, je uporaba teh praks v delovnem procesu in glej, kaj deluje. Sčasoma boste ugotovili, da so nekatere dejavnosti bolj koristne od drugih, in v tem primeru morate obdržite vse, kar deluje in pustite, kar ne.

Oglejte si te povezave, da najdete več nasvetov in najboljših praks za razvoj Sassa:

• Smernice Sass
• Vizija za naše Sass
• 8 nasvetov, ki vam bodo v pomoč pri Sassu
• Razširitev v Sassu brez ustvarjanja nereda
• Sass Best Practices - Gnezdenje več kot 3 ravni globoko