Sass Best Practices padomi un rīki izstrādātājiem

Līdzīgi kā jQuery revolucionēja vaniļas JavaScript, Sass ir revolucionizējis vaniļas CSS. Lielākā daļa izstrādātāju, kas mācās Sass, piekrīt, ka viņi nekad nevēlas atgriezties. Daudzi arī piekrīt, ka lielākā problēma ar jaunajiem izstrādātājiem ir veidā viņi izmanto Sasu, nevis pats Sass.

Esmu mazgājis tīmekli un apkopojis šo rakstu labākās prakses izvēršamā un atkārtoti izmantojamā Sass koda rakstīšanai. Ieteikumi ir no maniem viedokļiem un uzticamām vietnēm, piemēram, Sass vadlīnijām.

Jums noteikti nav jāīsteno visas šīs funkcijas savā darbplūsmā. Bet ir vērts vismaz izklaidēt šīs idejas un apsvērt iespējamos ieguvumus.

Failu organizācija

Labākā vieta, kur sākt ar Sass attīstību, ir failu organizēšana. Ja jūs jau esat pievienojies modulārajam kodam, tad jums jāsaprot importa vērtība un daļēji (vairāk par tiem vēlāk).

Bet tagad apskatiet šo failu struktūras piemēru no DoCSSa. Esmu izveidojis šo faila struktūru, kuru varat redzēt tālāk:

Tas ir tikai ieteikums, un tas ir viens no daudzajiem veidiem, kā jūs varētu organizēt savus failus. Jūs varat atrast citas metodes, kas izmanto dažādas mapju struktūras “globāli” visai SCSS un “lapas” lappuses specifiskai SCSS.

Izskatīsim šo ieteikto organizācijas stilu, lai pārbaudītu katras mapes mērķi:

• / globāli - satur Sass failus, kuriem tiek piemērota visa vietne, piemēram, tipogrāfija, krāsas un režģi
• / komponenti - satur Sass failus ar komponentu stiliem, piemēram, pogām, tabulām vai ievades laukiem
• / sadaļas - satur Sass failus, kas paredzēti konkrētām lapām vai lapām (var darboties labāk apvienojumā ar / komponenti / mapi)
• / Utils - satur trešo pušu komunālos pakalpojumus, piemēram, normalizēt, ko var dinamiski atjaunināt ar tādiem instrumentiem kā Bower.
• main.scss - galvenais Sass fails saknes mapē, kas importē visus pārējos.

Tas ir tikai sākumpunkts, un ir daudz iespēju paplašināt savas idejas.

Bet neatkarīgi no tā, kā jūs izvēlaties organizēt savu SCSS, ir svarīgi, lai jūs ir kāda organizācija ar atsevišķu failu (vai mapi) bibliotēkām, piemēram, Normalizēt, kas ir jāatjaunina, kā arī Sass daļiņu komponenti jūsu projektam.

Sass partijas ir būtiskas mūsdienu labākajai praksei. Tie ir ļoti ieteicami Zurb dizaina komandā un daudzos citos profesionālos frontendu izstrādātājos.

Šeit ir citāts no Sass tīmekļa vietnes, kurā paskaidrots:

“Varat izveidot daļējus Sass failus, kas satur maz CSS fragmentus, kurus varat iekļaut citos Sass failos. Tas ir lielisks veids, kā modularizējiet savu CSS un palīdziet to uzturēt vieglāk. Daļējs ir vienkārši Sass fails ar galveno pasvītrojumu. Jūs to varat nosaukt par kaut ko līdzīgu _partial.scss. Pasvītrojums ļauj Sass zināt, ka fails ir tikai daļējs fails un ka to nevajadzētu ģenerēt CSS failā. Sas dalības tiek izmantotas kopā ar @import direktīvu.”

Apskatiet arī šīs citas ziņas par Sass failu struktūru:

• Kā es izveidoju savus Sass projektus
• Estētiskā Sass: arhitektūra un stila organizācija
• Direktoriju struktūras, kas palīdz uzturēt jūsu kodu

Importa stratēģijas

Nav pietiekami daudz par Sass importa vērtību un partijām. Kodu organizēšana ir galvenais faktors, lai iegūtu importa struktūru un darbplūsmu, kas tikai darbojas.

Labākā vieta, kur sākt, ir globāla loksne ar importu, mainīgajiem lielumiem un maisījumiem. Daudzi izstrādātāji izvēlas atdalīt mainīgos lielumus un maisījumus, bet tas nāk līdz semantikai.

Paturiet prātā, ka mixins ir veids, kā importēt vai drīzāk dublēt Sass kodu. Viņi ir neticami spēcīgi, taču tos nedrīkst lietot kopā ar “statisks” kodu. Paturiet prātā, ka ir atšķirība starp mixins, extends un vietniekiem, kuri visi izmanto Sass attīstību.

Mixins vislabāk izmanto ar dinamiskām vērtībām, kas ietvertas maisījumā, lai mainītu kodu. Piemēram, pārbaudiet šo Sass mixin, kas rada fona gradientu starp divām krāsām.

@mixin linearGradient ($ top, $ bottom) fons: $ top; / * Vecās pārlūkprogrammas * / fons: -moz-lineārs gradients (augšā, $ top 0%, $ bottom 100%); / * FF3.6 + * / fons: -webkit gradients (lineārs, kreisais augšējais, kreisais apakšējais, krāsu apstāšanās (0%, $ top), krāsu apstāšanās (100%, $ apakšā)); / * Chrome, Safari4 + * / fons: -webkit-lineārs gradients (augšā, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / fons: -o-lineārie gradienti (augšā, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / fons: -ms-lineārais gradients (augšā, $ top 0%, $ bottom 100%); / * IE10 + * / fons: lineārie gradienti (uz leju, $ top 0%, $ bottom 100%); / * W3C * / filtrs: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin ir divas vērtības: augšējā krāsa un apakšējā krāsa. Varat rakstīt dažādus maisījumus dažādiem gradientu veidiem, kas ietver 3 vai 4+ dažādas krāsas. Tas ļauj importēt un klonēt mixin kodu, mainot pielāgoto opciju parametrus.

Kods Atbildīgais piemērs izskatās šādi:

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

Saistībā ar mixin ir Sass vietnieks, kas galvenokārt ir noderīgs ar paplašināšanas direktīvu. Tas, protams, ir sarežģītāks nekā mixins, bet tas var būt veids, kā apvienot selektorus, nepārrakstot lieko kodu.

Lai gan Sass ir tikai viena @import metode, es esmu iekļāvis mixins un vietniekvārdus, lai parādītu koda elastību, ko var rakstīt vienā failā, bet iekļauj jebkurā vietā.

Veidojot importa struktūru, atcerieties ievērot DRY kodēšanas jēdzienus (neizmantojiet pats).

Nosaukuma konvencijas

Vispārīgie noteikumi par konvenciju nosaukumiem attiecas uz mainīgajiem, funkcijām un maisījumiem. Nosaukot kaut ko Sass, ieteicams atdalīšanai izmantojiet visus mazos burtus ar domuzīmēm.

Sass koda sintakse faktiski balstās uz CSS vadlīniju noteikumiem. Šeit ir daži ieteicamākie paraugprakses veidi, kas jāpatur prātā:

• divas (2) atstarpes, bez cilnēm
• ideālā gadījumā 80 vai vairāk rakstzīmju līnijas vai mazāk
• jēgpilnu kosmosa izmantošanu
• izmantot komentārus, lai izskaidrotu CSS operācijas

Tie nav obligāti derīga Sass koda elementi. Bet šie ieteikumi nāk no profesionāliem izstrādātājiem ir noskaidrojuši, ka šie noteikumi nodrošina visvienveidīgāko kodēšanas pieredzi.

Bet attiecībā uz nosaukuma konvencijām jūs varat nonākt pie divām dažādām struktūrām: viena Sass vārdiem un cits CSS klases nosaukumiem. Daži izstrādātāji dod priekšroku BEM pār Sass ieteikumiem. Neviens no tiem nav vairāk vai mazāk pareizi; atšķiras ar dažādām darbības procedūrām.

Problēma ir tā, ka BEM nav pārnesis uz Sass mainīgajiem lielumiem vai maisījumiem, jo ​​viņiem nav bloka / elementa / modifikatora (BEM) struktūras. Es personīgi dodu priekšroku Sass nosaukuma konvencijām, bet jūs varētu mēģināt kaut ko no camelCase uz savu iekšējo sintaksi.

Organizējot savus mainīgos un maisījumus, ieteicams sadaliet tos pa kategorijām, pēc tam uzskaitiet tos alfabētiskā secībā. Tas padara rediģēšanu daudz vieglāku, jo jūs precīzi zināt, kur kaut ko atrast.

Piemēram, lai mainītu saites krāsu, atveriet savu mainīgo failu (varbūt _variables.scss) un atrodiet krāsu mainīgo sadaļu. Tad atrodiet saiti pēc nosaukuma (galvenes saite, teksta saite utt.) Un atjauniniet krāsu. Vienkārša!

Lai iegūtu priekšstatu par to, kā jūs varētu veidot satura tabulu jūsu Sass failiem, pārbaudiet Fonda iestatījumu failu.

 // Vietņu iestatījumu fonds // ----------------------------- // Satura rādītājs // // 1 Globālais // 2. Pārtraukuma punkti // 3. Tīkls // 4. Bāzes tipogrāfija // 5. Tipogrāfijas palīgi… // 1. Globālā // --------- $ globālā fontu izmērs: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // utt

Vēl viena nosaukuma prakse attiecas uz atsaucīgi pārtraukumi. Nosakot Sass pārtraukuma punktus, mēģiniet izvairīties no ierīces nosaukumiem. Ir labāk rakstīt vārdus, piemēram, mazus, med, lg un xlg, jo viņi ir attiecībā pret otru.

Tas ir labāks iekšējām attiecībām starp pārtraukumiem, bet arī lieliskām komandām, kurās izstrādātāji var nezināt, kuras ierīces ir savstarpēji saistītas.

Runājot par vārdiem, jums ir ieteicams jābūt pēc iespējas specifiskākiem, ja nav mainīgi lielumi. Jums vajadzētu pieņemt vietnes nosaukuma konvencijas, kuras ir viegli atcerēties kodēšanas laikā.

Sniedziet īpašas nosaukuma konvencijas visam, piemēram, krāsām, margām, fontu kaudzēm un līnijas augstumiem. Vārdus var ne tikai ātri atcerēties, bet arī padara jūsu darbu vieglāku, rakstot jaunus mainīgos nosaukumus, kuriem jāatbilst esošajai sintaksei.

Bet tur ir precīza līnija starp specifiskumu un konvulciju. Prakse palīdzēs jums atrast šo līniju, un vairāk neaizmirstamu vārdu rakstīšana atvieglo koda kopēšanu citos projektos.

Ligzdošana un cilpošana

Šīs divas Sassas metodes darbībā ir ļoti atšķirīgas, tomēr abām ir spēja tikt ļaunprātīgi izmantota, ja to neizmanto uzmanīgi.

Ligzdošana ir process pievienojot selektorus, kas ligzdoti kopā ar ievilkumu, lai radītu lielāku specifiskumu ar mazāku kodu. Sassam ir ligzdošanas ceļvedis, kas ilustrē koda ligzdošanas piemērus. Bet tas ir viegli nokļūt ar ligzdošanu. Ja esat pārspīlēts, jūs varat nonākt pie koda, kas izskatās šādi:

body div.content div.container … body div.content div.container div.articles … ķermeņa div.content div.container div.articles> div.post … 

Pārāk specifiski un gandrīz neiespējami pārrakstīt, šāda veida kods pārspēj kaskādes stilu tabulu.

Novietojiet šo vietnes vietnes rokasgrāmatu, lai atrastu trīs zelta noteikumus ligzdošanai:

• Nekad nepārietiet vairāk nekā 3 līmeņus dziļi.
• Pārliecinieties, vai CSS izeja ir tīra un atkārtoti izmantojama.
• Izmantojiet ligzdošanu, ja tas ir jēga, nevis kā noklusējuma opcija.

Izstrādātājs Josh Broton ierosina ligzdošanu, kad tas nepieciešams, ievilkt pārējo kā vispārēju sintakses noteikumu.

Izvēloties jūsu atlasītājus, tas neradīs nekādus CSS efektus. Bet jums būs vieglāk aplaupīt Sass failu, nosakot, kuras klases ir savstarpēji saistītas.

Arī cilpas var būt ja tie netiek pareizi izmantoti. Trīs Sass cilpas ir @for, @ tikko, un @katrs. Es neiedziļināšos par to, kā viņi visi strādā, bet, ja jūs interesē, pārbaudiet šo ziņu.

Tā vietā es gribētu segt cilpu izmantošanas mērķis un kā viņi darbojas Sassā. Tie ir jāizmanto, lai ietaupītu laika rakstīšanas kodu, ko var automatizēt. Piemēram, šeit ir koda fragments no Clubmate ziņojuma, kurā redzams Sass kods, kam seko produkcija:

/ * Sass kods * / @ for $ i no 1 līdz 8 $ platums: procentu (1 / $ i) .col - # $ i platums: $ platums;  / * izeja * / .col-1 platums: 100%;.-2 platums: 50%;.-3 platums: 33,333%;.-4 platums: 25%;  .kol-5 platums: 20%;. -6 platums: 16,666%; .col-7 platums: 14,285%; .col-8 platums: 12,5%;

Šīs kolonnas klases var izmantot kopā ar režģa sistēmu. Jūs pat varat pievienot vairāk kolonnu vai noņemt dažas tikai, rediģējot cilpas kodu.

Cilpas vajadzētu ne izmanto, lai dublētu selektoru vai selektora īpašības; tas ir tas, kas ir mixins.

Arī tad, kad tiek apzīmēts, ka ir kaut kas saucas Sass kartes, kas glabā atslēgu: datu pāru vērtības. Uzlabotajiem lietotājiem, ja vien iespējams, jāizmanto tie.

Bet regulāri Sass cilpas ir vienkāršas un efektīvas, lai nodrošinātu koda izvadi bez atkārtošanās. Labākais iemesls cilpu izmantošanai ir ar CSS īpašības, kas atšķiras datu izvadi.

Lūk, labs veids, kā pārbaudīt, vai jūsu cilpa ir noderīga: jautājiet sev ja ir kāds cits veids, kā izvadīt vajadzīgo CSS ar mazāk kodu rindām. Ja tā nav, cilpas sintakse, iespējams, ir lieliska ideja.

Ja jūs kādreiz sajaukt vai vēlaties atgriezenisko saiti par ligzdošanas vai Sass cilpām, jums jāpievieno jautājums / r / sass / vai / r / css /, aktīvās Reddit kopienas ar ļoti zinošiem Sass izstrādātājiem.

Modularizācija

Moduļu Sass rakstīšanas prakse ir absolūti nepieciešama lielākajā daļā projektu (es apgalvoju, katrs projekts). Modularizācija ir projekta sadalīšana mazākos moduļos. To var paveikt Sassā, izmantojot daļēji.

Moduļa Sass ideja ir rakstīt individuālus SCSS failus ar konkrētu mērķi, kas vērsts uz globālo saturu (tipogrāfiju, tīklus) vai lapu elementiem (cilnes, veidlapas).

Sass moduļa definīcija ir diezgan skaidra un sniedz ļoti konkrētu ieteikumu: moduļa importēšana nekad nedrīkst izvadīt kodu.

Visu moduļu obligātās izlaides ideja būtu murgs optimizācijai. Tā vietā jums vajadzētu izveidot moduļus individuāli un zvaniet tikai tiem, kas jums ir vajadzīgi. Moduļus var definēt, izmantojot mixins vai funkcijas, bet ir iespējams izveidot arī moduļus, kas satur arī selektorus.

Tomēr Sass Way raksts iesaka rakstīt visus selektorus kā mixins un tikai tos izsaucot pēc vajadzības. Neatkarīgi no tā, vai jūs to pieņemat vai nē, tā ir jūsu izvēle. Es domāju, ka tas ir atkarīgs no projekta lieluma un jūsu komforta ar kombinācijām.

Citējot Džonu Longu no viņa amata The Sass Way:

“Manuprāt, moduļi ir kļuvuši par manu Sass projektu pamatvienībām vai blokiem.”

Ja jūs patiešām meklējat Sass rutīnas, es iesaku iet pilnībā moduļu. Mēģiniet veidot gandrīz visu kā moduļu daļēju daļu, kas tiek iekļauta primārā CSS failā. Sākotnēji šī darbplūsma var šķist biedējoša, bet tai ir jēga plašākā mērogā - īpaši ar lieliem projektiem.

Turklāt ir daudz vieglāk kopēt moduļus no viena projekta uz citu, ja tie atrodas atsevišķos failos. Elastīgums un atkārtoti izmantojamu kodu ir moduļu attīstības stūrakmeņi.

Lai uzzinātu vairāk par Sass moduļiem un modularizācijas metodēm, pārbaudiet šīs ziņas:

• CSS moduļi: Laipni lūdzam nākotnē
• Moduļa Sass plusi un mīnusi
• Moduļu CSS organizācija ar SMACSS & SASS

Atrodiet savu ideālo darbplūsmu

Katrai komandai un individuālajam attīstītājam ir sava prakse, kas vislabāk darbojas. Jums ir jāpieņem prakse, kas vislabāk atbilst jums personīgi, vai izvēlēties tos, kas vislabāk atbilst jūsu komandai profesionāli.

Apsveriet arī iespēju izmantot Gulp vai Grunt projektu automatizācijai un koda rediģēšanai. Tas ļaus ietaupīt daudz manuālo darbaspēku un automatizācijas rīki tagad neapšaubāmi ir daļa no labākās prakses mūsdienu frontendu attīstībai.

Mācieties caur atvērtā koda bibliotēkām, piemēram, fonda SCSS uz GitHub, lai uzzinātu vairāk par citu bibliotēku izmantoto labāko praksi.

Lieta par labāko praksi ir tāda, ka viņi lielākoties uzlabo jūsu darbu, bet ir daudz alternatīvu. Vienkārši mēģiniet lietas un redzēt, kā viņi jūtas. Jūs vienmēr mācīsieties, lai jūsu labākās prakses varētu strauji mainīties 5 gadu laikā.

Viens galīgais ieteikums, kas man ir visam Sass procesam, ir pieņemt lēmumus ar skaidrību. Rakstiet kodu, kas atvieglo jūsu darbu. Nelietojiet pārāk sarežģīt projektu, ja ir vienkāršāks veids, kā to izdarīt.

Sass ir domāts, lai uzlabotu CSS izstrādes pieredzi darbs ar skaidrību un labāko praksi iegūt vislabāko pieredzi.

Satīt

Sass darbplūsmas sastrēgumus var izlabot, mainot koda stilus un ievērojot labākās prakses. Es esmu izklāstījis nedaudzus ieteikumus šajā amatā, ko sniedza Sass blogi un profesionāli izstrādātāji.

Labākais veids, kā uzzināt vairāk, ir izmantot šīs prakses savā darbplūsmā un redzēt, kas darbojas. Laika gaitā jūs redzēsiet, ka dažas aktivitātes ir izdevīgākas nekā citas, tādā gadījumā jums vajadzētu paturiet to, kas darbojas un nometiet to, kas nav.

Apskatiet šīs saites, lai atrastu vairāk padomu un labāko praksi Sass izstrādei:

• Sass vadlīnijas
• Vīzija par mūsu Sassu
• 8 padomi, lai palīdzētu jums iegūt labāko no Sasas
• Paplašināšana Sassā bez radīšanas
• Sass labākās prakses - vairāk nekā 3 līmeņu dziļināšana