Sass Best Practices Vihjeitä ja työkaluja kehittäjille

Paljon kuin kuinka jQuery mullisti vanilja-JavaScriptin, Sass on mullistanut vanilja CSS: n. Useimmat kehittäjät, jotka oppivat Sassia, ovat samaa mieltä siitä, että he eivät koskaan halua palata takaisin. Monet ovat myös yhtä mieltä siitä, että suurin ongelma uusien kehittäjien kanssa on tapa he käyttävät Sassia, ei itse Sassia.

Olen pesemässä verkkoa ja koonnut tämän artikkelin parhaat käytännöt laajennettavan ja uudelleenkäytettävän Sass-koodin kirjoittamiseen. Ehdotukset ovat omilta mielipiteiltäni ja luotetuilta sivustoilta, kuten Sassin ohjeilta.

Sinun ei tarvitse toteuttaa kaikkia näitä ominaisuuksia työnkulkuun. Mutta kannattaa ainakin viihdyttää näitä ajatuksia ja harkita mahdollisia etuja.

Tiedoston organisaatio

Paras paikka aloittaa Sass-kehityksellä on tiedostojärjestely. Jos olet jo modulaarinen koodi, sinun on ymmärrettävä tuonnin arvo ja ositukset (lisää näistä myöhemmin).

Katsokaa nyt vain tätä tiedostorakenteen esimerkkiä DoCSSasta. Olen luonut uudelleen tämän tiedostorakenteen, jonka näet alla:

Tämä on vain ehdotus, ja se on yksi monista tavoista, joilla voit järjestää tiedostoja. Löydät muita menetelmiä, jotka käyttävät erilaisia ​​kansiorakenteita “global” koko SCSS: lle ja “sivut” sivuspesifiselle SCSS: lle.

Käy läpi tämän ehdotetun organisaatiotyypin tarkastelemalla kunkin kansion tarkoitusta:

• / global - sisältää Sass-tiedostoja, joihin sovelletaan koko sivustoa, kuten typografiaa, värejä ja verkkoja
• / komponentit - sisältää Sass-tiedostoja, joissa on komponenttityylejä, kuten painikkeet, taulukot tai syöttökentät
• / kohdat - sisältää Sass-tiedostoja, jotka on omistettu tietyille sivuille tai alueille (saattavat toimia paremmin yhdistettynä / osiin / kansioon)
• / utils - sisältää kolmannen osapuolen apuohjelmia, kuten Normalize, joka voidaan päivittää dynaamisesti työkaluilla, kuten Bower.
• main.scss - ensisijainen Sass-tiedosto juurikansiossa, joka tuo kaikki muut.

Tämä on vain peruslähtökohta ja runsaasti tilaa laajentaa omilla ajatuksillasi.

Mutta riippumatta siitä, miten haluat järjestää SCSS: n, on tärkeää, että te sinulla on jonkinlainen organisaatio jossa on erillinen tiedosto (tai kansio) kirjastoille, kuten Normalize, jotka on päivitettävä, sekä Sass-osien osia projektisi.

Sass-osit ovat elintärkeitä nykyaikaisille parhaille käytännöille. Näitä suosittelevat Zurbin suunnittelutiimi ja monet muut ammattikäyttöön suunnatut kehittäjät.

Tässä on lainaus Sassin verkkosivustosta, jossa selitetään osituksia:

“Voit luoda osittaisia ​​Sass-tiedostoja, jotka sisältävät vähän katkelmia CSS: stä, joita voit lisätä muihin Sass-tiedostoihin. Tämä on hyvä tapa muokkaa CSS: ää ja auta pitämään asiat helpommin ylläpidettävissä. Osittainen on yksinkertaisesti Sass-tiedosto, jonka nimi on johtava alaviiva. Voit nimetä sen jotain _partial.scss. Alleviivaus sallii Sassin tietävän, että tiedosto on vain ositiedosto ja että sitä ei pitäisi luoda CSS-tiedostoon. Sass-osioita käytetään @tuonti direktiivi.”

Tutustu myös muihin Sass-tiedoston rakennetta koskeviin viesteihin:

• Miten rakennan Sass-projektini
• Esteettinen Sass: arkkitehtuuri ja tyyliorganisaatio
• Hakemistorakenteet, jotka auttavat sinua ylläpitämään koodia

Tuo strategioita

Sass-tuonnin arvosta ja partikkeleista ei voida sanoa tarpeeksi. Koodijärjestely on avain, kun haluat tuoda maahan vain tuontirakenteen ja työnkulun.

Paras paikka aloittaa on globaalilevy, joka sisältää tuontia, muuttujia ja sekoituksia. Monet kehittäjät haluavat erottaa muuttujat ja sekoittimet, mutta tämä tulee alas semantiikkaan.

Muista, että mixins ovat Sass-koodin tuonti tai melko monistaminen. He ovat uskomattoman voimakkaita, mutta niitä ei pitäisi käyttää “staattinen” koodi. Muista, että mixins, extends ja paikkamerkit eroavat toisistaan, jotka kaikki käyttävät Sass-kehitystä.

Sekoituksia käytetään parhaiten, kun dynaamiset arvot siirretään sekoituslaitteeseen koodimuutoksia varten. Tarkista esimerkiksi tämä Sass-sekoitus, joka luo taustavälin kahden värin välillä.

@mixin linearGradient ($ top, $ bottom) tausta: $ top; / * Vanhat selaimet * / tausta: -moz-lineaarinen gradientti (alkuun, $ top 0%, $ bottom 100%); / * FF3.6 + * / tausta: -webkit-gradientti (lineaarinen, vasen yläosa, vasen pohja, värin pysäytys (0%, $ top), värin pysäytys (100%, $ bottom)); / * Chrome, Safari4 + * / tausta: -webkit-lineaarinen gradientti (alkuun, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / tausta: -o-lineaarinen gradientti (alkuun, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / tausta: -ms-lineaarinen gradientti (alkuun, $ top 0%, $ bottom 100%); / * IE10 + * / tausta: lineaarinen gradientti (pohjaan, $ top 0%, $ bottom 100%); / * W3C * / suodatin: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Sekoituksessa on kaksi arvoa: alkuun väri ja pohjaväri. Voit kirjoittaa erilaisia ​​sekoituksia eri tyyppisille kaltevuuksille, jotka sisältävät 3 tai 4 + eri väriä. Tämän avulla voit tuoda ja kloonata sekoituskoodin samalla kun muutat mukautettujen asetusten parametreja.

Code Responsiblein esimerkki näyttää tältä:

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

Mixiniin liittyy Sassin paikkamerkki, joka on ensisijaisesti hyödyllinen laajennusdirektiivin kanssa. Se on tosin monimutkaisempi kuin mixins, mutta tämä voi olla keino yhdistää valintalaitteet yhdessä ilman ylimääräisen koodin kirjoittamista uudelleen.

Vaikka Sassilla on vain yksi @import-menetelmä, olen lisännyt miksit ja paikkamerkit osoittamaan koodin joustavuutta, joka voidaan kirjoittaa yhteen tiedostoon, mutta joka on mukana missä tahansa.

Kun rakennat tuontirakennetta, muista vain noudattaa DRY-koodauksen käsitteitä (älä toista itseäsi).

Nimeämissopimukset

Yleisiä sääntöjä nimityskäytäntöjä varten sovelletaan muuttujiin, toimintoihin ja sekoittimiin. Kun nimeät mitään Sassissa, on suositeltavaa käytä kaikkia pieniä kirjaimia erotuskohdilla.

Sass-koodin syntaksi perustuu itse asiassa CSS-ohjeiden sääntöön. Seuraavassa on muutamia suositeltuja parhaita käytäntöjä, jotka on pidettävä mielessä:

• kaksi (2) välilyöntiä, ei välilehtiä
• mieluiten 80 merkin leveät linjat tai vähemmän
• välilyönnin merkityksellistä käyttöä
• käytä kommentteja selittääksesi CSS-toimintaa

Nämä eivät ole kelvollisia Sass-koodin kohteita. Mutta nämä ehdotukset ovat peräisin ammattimaisilta kehittäjiltä ovat havainneet, että nämä säännöt tarjoavat yhtenäisimmän koodauskokemuksen.

Mutta nimityskäytäntöjen osalta saatat päätyä kahteen eri rakenteeseen: yksi Sass-nimiin ja toinen CSS-luokan nimiin. Jotkut kehittäjät valitsevat BEM: n yli Sassin ehdotukset. Kumpikaan ei ole enemmän tai vähemmän oikea; vain erilaiset eri toimintamenettelyillä.

Ongelmana on, että BEM ei siirry hyvin Sass-muuttujiin tai sekoittimiin, koska niillä ei ole lohko / elementti / modifikaattorirakennetta (BEM). Haluaisin henkilökohtaisesti käyttää Sassin nimeämissopimuksia, mutta voit kokeilla jotain camelCasesta omaan sisäiseen syntaksiin.

Suosittelemme, että järjestät muuttujia ja sekoituksia jaa ne luokkien mukaan ja laita ne sitten aakkosjärjestykseen. Tämä tekee muokkaamisesta paljon helpompaa, koska tiedät tarkalleen, mistä löytää jotain.

Jos haluat esimerkiksi muuttaa linkin väriä, voit avata muuttujatiedoston (ehkä _variables.scss) ja etsi värimuuttujien osa. Etsi sitten linkki nimen mukaan (otsikkolinkki, tekstilinkki jne.) Ja päivitä väri. Yksinkertainen!

Jos haluat saada käsityksen siitä, miten voit rakentaa Sass-tiedostojen sisällön, tutustu säätiön asetustiedostoon.

 // Sivustojen asetusten säätiö // ----------------------------- // // Sisällysluettelo: // // 1 Global // 2. Rikkopisteet // 3. Ruudukko // 4. Peruskirjoitus // 5. Typografian avustajat… // 1. Yleinen // --------- $ globaali-fonttikoko: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // jne

Toinen nimeämiskäytäntö koskee reagoivat katkaisupisteet. Kun nimität Sass-katkoviivoja, yritä välttää laitekohtaisia ​​nimiä. On parempi kirjoittaa pieniä, med, lg ja xlg nimiä, koska ne ovat suhteessa toisiinsa.

Tämä on parempi rajapisteiden välisissä sisäisissä suhteissa, mutta myös hienoissa ryhmissä, joissa kehittäjät eivät ehkä tiedä, mitkä laitteet liittyvät toisiinsa.

Nimien nimittämistä varten on suositeltavaa oltava mahdollisimman yksityiskohtaisia ​​ilman ylimääräisiä pitkiä muuttujia. Sinun pitäisi hyväksyä sivustonlaajuiset nimityssopimukset, jotka on helppo muistaa koodauksen aikana.

Anna nimenomaiset nimityskäytännöt kaikelle, kuten väreille, reunuksille, kirjasimille ja rivikorkeuksille. Nimiä ei voi vain muistaa nopeasti, vaan se helpottaa työtäsi, kun kirjoitat uusia muuttuja-nimiä, joiden on vastattava olemassa olevaa syntaksi.

Mutta siellä on hieno linja spesifisyyden ja konvoluution välillä. Käytäntö auttaa sinua löytämään tämän linjan, ja enemmän muistettavien nimien kirjoittaminen helpottaa koodin kopiointia muihin projekteihin.

Pesiminen ja silmukointi

Nämä kaksi Sass-tekniikkaa ovat hyvin erilaiset toiminnassa, mutta molemmilla on kykyä käyttää väärin, jos sitä ei käytetä harkiten.

Pesiä on prosessi lisäämällä yhteen syvennyksellä sisäkkäiset valittimet, jotta saadaan enemmän spesifisyyttä, jossa on vähemmän koodia. Sassilla on pesäopas, joka havainnollistaa esimerkkejä toimintakoodin pesimisestä. Mutta on helppo päästä pois pesimällä. Jos olet ylivoimainen, voit päätyä koodiin, joka näyttää tältä:

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

Tämäntyyppinen koodi on liian erikoinen ja lähes mahdoton korvata, ja se häviää kaskadityylien tarkoituksen.

Tämän SitePoint-oppaan ohittaminen sisältää kolme kultaista sääntöä:

• Älä koskaan mene yli 3 tasolle syvälle.
• Varmista, että CSS-lähtö on puhdas ja uudelleenkäytettävä.
• Käytä pesimistä, kun se on järkevää, ei oletusasetuksena.

Kehittäjä Josh Broton ehdottaa, että pesä voidaan sijoittaa tarvittaessa.

Valintasi sulkeminen ei aiheuta CSS-vaikutuksia. Mutta sinun on helpompi ajaa Sass-tiedostoasi kuriin, jossa määritellään, mitkä luokat liittyvät toisiinsa.

Silmukat voivat myös jos niitä ei käytetä oikein,. Kolme Sass-silmukkaa ovat @for, @sillä aikaa, ja @each. En mene yksityiskohtiin siitä, miten he kaikki toimivat, mutta jos olet kiinnostunut, lue tämä viesti.

Sen sijaan haluaisin kattaa silmukoiden käyttötarkoitus ja miten ne toimivat Sassissa. Näitä tulisi käyttää automatisoitavan ajan kirjoituskoodin säästämiseen. Esimerkiksi tässä on koodinpätkä Clubmate-viestistä, jossa näkyy joitakin Sass-koodia, jota seuraa tuotos:

/ * Sass-koodi * / @ for $ i 1 - 8 $ leveys: prosentti (1 / $ i) .col - # $ i leveys: $ leveys;  / * ulostulo * / .col-1 leveys: 100%; .col-2 leveys: 50%; .col-3 leveys: 33,333%; .col-4 leveys: 25%;  .col-5 leveys: 20%; .col-6 leveys: 16,666%; .col-7 leveys: 14,285%; .col-8 leveys: 12,5%;

Näitä sarakelajeja voidaan käyttää ruudukon kanssa. Voit jopa lisätä sarakkeita tai poistaa joitakin vain muokkaamalla silmukakoodia.

silmukat pitäisi ei käytetään valitsimien tai ominaisuuksien kopioimiseen valitsimelle; se on mitä sekoittimet ovat.

Myös silmukoitaessa on jotain Sass-karttoja, jotka tallentavat avaimen: arvoparit. Kehittyneiden käyttäjien tulisi hyödyntää näitä mahdollisuuksien mukaan.

Mutta säännölliset Sass-silmukat ovat yksinkertaisia ​​ja tehokkaita antamaan koodilähdettä toistamatta. Paras syy käyttää silmukoita on CSS-ominaisuudet, jotka vaihtelevat dataa.

Tässä on hyvä tapa tarkistaa, onko silmukka hyödyllinen: kysy itseltäsi jos on olemassa jokin muu tapa tuottaa tarvitsemasi CSS: ää vähemmän riviä koodia. Jos ei, silmukan syntaksi on luultavasti loistava idea.

Jos olet koskaan hämmentynyt tai haluat palautetta pesimis- tai Sass-silmukoista, sinun on lähetettävä kysymys joko / r / sass / tai / r / css /, aktiivisissa Reddit-yhteisöissä, joilla on erittäin asiantunteva Sass-kehittäjä.

modularisointi

Modulaarisen Sassin kirjoittaminen on ehdottoman välttämätöntä useimmille hankkeille (väitän, jokainen projekti). Modulaatio on prosessi hankkeen hajottaminen pienemmiksi moduuleiksi. Tämä voidaan toteuttaa Sassissa käyttämällä partials.

Modulaarisen Sassin ajatuksena on kirjoittaa yksittäisiä SCSS-tiedostoja, joilla on tietty käyttötarkoitus, joka kohdistuu maailmanlaajuiseen sisältöön (typografia, ruudukot) tai sivun elementteihin (välilehdet, lomakkeet).

Sass-moduulin määrittely on melko selkeä ja tekee hyvin tarkan ehdotuksen: moduulin tuominen ei koskaan tulosta koodia.

Idea kaikkien moduulien pakollisesta tuotoksesta olisi optimoinnin painajainen. Sen sijaan sinun pitäisi luoda moduuleja erikseen ja soita vain niihin, joita tarvitset. Moduuleja voidaan määritellä sekoittimilla tai toiminnoilla, mutta on mahdollista luoda myös moduuleja, jotka sisältävät myös valittimia.

Kuitenkin Sass Way -artikkelissa ehdotetaan kaikkien selektorien kirjoittamista sekoittimiksi ja vain kutsumalla niitä tarvittaessa. Riippumatta siitä, hyväksyykö tämä vai ei, on lopulta valinta. Mielestäni se riippuu projektin koosta ja mukavuudesta sekoitusten käsittelyssä.

Sanoten John Longia Sass Wayn postitse:

“Minulle moduulit ovat tulleet Sass-hankkeiden perusyksiköiksi tai rakennuspalikoiksi.”

Jos etsit Sass-rutiinia, suosittelen menemään täysin modulaarisen. Yritä rakentaa lähes kaiken modulaarisena osituksena, joka sisällytetään ensisijaiseen CSS-tiedostoon. Aluksi tämä työnkulku voi tuntua pelottavalta, mutta se on järkevämpää - etenkin suurissa projekteissa.

Lisäksi on paljon helpompaa kopioida moduuleja yhdestä projektista toiseen, kun ne sijaitsevat erillisissä tiedostoissa. Joustavuus ja uudelleenkäytettävä koodi ovat modulaarisen kehityksen kulmakiviä.

Saat lisätietoja Sass-moduuleista ja modulaatiotekniikoista tutustumalla näihin viesteihin:

• CSS-moduulit: Tervetuloa tulevaisuuteen
• Modulaarisen Sassin edut ja haitat
• Modulaarinen CSS-organisaatio ja SMACSS & SASS

Etsi täydellinen työnkulku

Jokaisella tiimillä ja yksittäisellä kehittäjällä on omat käytännöt, jotka toimivat parhaiten. Sinun tulisi ottaa käyttöön käytäntöjä, jotka toimivat parhaiten sinulle henkilökohtaisesti, tai valitset sellaiset käytännöt, jotka toimivat parhaiten tiimillesi ammattimaisesti.

Harkitse myös Gulpin tai Gruntin käyttöä projektin automatisointiin ja koodin minimointiin. Tämä säästää paljon manuaalista työvoimaa ja automaatiotyökalut ovat nyt epäilemättä osa nykyaikaisen frontend-kehityksen parasta käytäntöä.

Skim kautta avoimen lähdekoodin kirjastoja, kuten säätiön SCSS GitHubissa, jotta saat lisätietoja muiden kirjastojen käyttämistä käytännöistä.

Parhaisiin käytäntöihin liittyy se, että he todella parantavat työsi suurimman osan ajasta, mutta on monia vaihtoehtoja. Kokeile asioita ja katso, miten he tuntevat. Opit aina niin, että parhaat toimintatavat voivat muuttua nopeasti 5 vuoden aikana.

Yksi lopullinen ehdotus koko Sass-prosessille on tehdä päätöksiä selkeästi. Kirjoita koodi, joka helpottaa työtäsi. Älä monimutkaise hanketta, jos se on yksinkertaisempi.

Sass on tarkoitettu parantamaan CSS-kehityskokemusta toimivat selkeästi ja parhaiden käytäntöjen mukaisesti saada paras mahdollinen kokemus.

Paketoida

Sass-työnkulun ruuhkautumista voidaan korjata säätämällä koodityylejä ja noudattamalla parhaita käytäntöjä. Olen esittänyt kourallisen ehdotuksen Sassin blogeista ja ammattilaisten kehittäjistä.

Paras tapa oppia lisää on soveltaa näitä käytäntöjä työnkulkuun ja katso, mikä toimii. Ajan myötä huomaat, että jotkin toiminnot ovat edullisempia kuin toiset, jolloin sinun pitäisi pidä mitä tahansa toimii ja pudota mitä ei.

Tutustu näihin linkkeihin saadaksesi lisää vinkkejä ja parhaita käytäntöjä Sassin kehittämiseen:

• Sassin suuntaviivat
• Visio Sassistamme
• 8 Vinkkejä, jotka auttavat sinua saamaan parhaan hyödyn Sassista
• Laajentaminen Sassissa luomatta Messia
• Sassin parhaat käytännöt - Yli kolme tasoa syvälle