Ghid de stil Sass: Un tutorial Sass despre cum să scrieți un cod CSS mai bun

Scrierea unui CSS coerent și lizibil, care se va scala bine, este un proces provocator. Mai ales când foile de stil devin mai mari, mai complexe și mai greu de întreținut. Unul dintre instrumentele disponibile dezvoltatorilor pentru a scrie CSS mai bun sunt preprocesoarele. Un preprocesor este un program care preia un tip de date și îl convertește în alt tip de date, iar în cazul nostru preprocesoarele CSS sunt limbaje de preprocesare care sunt compilate în CSS. Există multe preprocesoare CSS pe care dezvoltatorii front-end le recomandă și le folosesc, dar în acest articol ne vom concentra pe Sass. Să vedem ce are de oferit Sass, de ce este o alegere preferabilă față de alte preprocesoare CSS și cum să începeți să îl utilizați în cel mai bun mod.

Ce este Sass și de ce ar trebui să-l folosești?

Pentru cei dintre voi care nu știu ce este Sass, cel mai bun punct de plecare este să vizitați pagina oficială a Sass. Sass este un acronim pentru Syntactically Awesome StyleSheets și este o extensie a CSS care adaugă putere și eleganță limbajului de bază.

Sass este un preprocesor CSS cu o mulțime de funcții puternice. Cele mai notabile caracteristici sunt variabilele, extinderile și mixurile.

Variabilele stochează informații care pot fi reutilizate ulterior, cum ar fi culorile sau alte valori utilizate în mod obișnuit. Extinderile vă ajută să creați „clase” care permit moștenirea regulilor. Mixins, vă puteți gândi la „funcție”. Sass are și alte caracteristici uimitoare în comparație cu alte preprocesoare, cum ar fi utilizarea instrucțiunilor logice (condiționale și bucle), funcții personalizate, integrarea cu alte biblioteci precum Compas și multe altele. Numai aceste funcții vă pot ajuta pe dvs. și echipa dvs. să fiți mai productivi și să scrieți CSS mai bun în final.

De ce aveți nevoie de un ghid de stil CSS

Din păcate, nici măcar preprocesoarele nu pot repara totul și nu vă pot ajuta să scrieți cod CSS bun. Problema cu care se confruntă fiecare dezvoltator este că aplicațiile web actuale devin din ce în ce mai mari. De aceea, codul trebuie să fie scalabil și lizibil și trebuie să evite codul spaghetti și liniile neutilizate ale acestuia. Pentru a evita problemele menționate, este nevoie de un fel de standard pentru echipa ta în munca de zi cu zi. Ce este codul spaghetelor și cum se întâmplă? Codul spaghete este un nume pentru codul rău, lent, repetitiv și ilizibil. Când o echipă scrie aplicații mari fără linii directoare sau standarde definite, fiecare dezvoltator scrie ceea ce are nevoie și cum își dorește. De asemenea, atunci când dezvoltatorii scriu o mulțime de remedieri de erori, remedieri rapide și patch-uri, ei tind să scrie cod care va rezolva problema, dar nu au timp să scrie codul în cel mai bun mod. În aceste situații, este foarte obișnuit să ajungeți cu o mulțime de linii de CSS care nu mai sunt folosite în niciun sector al aplicației. Dezvoltatorii nu au timp suficient pentru a curăța codul și sunt forțați să publice remedierea cât mai repede posibil. O altă situație recurentă este aceea că pentru a remedia rapid lucrurile stricate, dezvoltatorii folosesc o mulțime de !important , care rezultă cu un cod foarte hacky, care este greu de întreținut, rezultă cu multe comportamente neașteptate și trebuie refactorizat mai târziu. După cum am menționat deja, pe măsură ce codul crește, situația se înrăutățește.

Ideea acestui articol este de a împărtăși reguli, sfaturi și cele mai bune practici pentru a scrie un Sass mai bun. Gruparea acestor sfaturi și bune practici Sass poate fi folosită ca ghid de stil Sass. Acest ghid de stil ar trebui să ajute dezvoltatorii să evite situațiile menționate mai sus. Regulile sunt grupate în segmente logice pentru o referire mai ușoară, dar în final ar trebui să le adoptați și să le urmați pe toate. Sau cel puțin, majoritatea.

Ghid stilistic

Setul de reguli și cele mai bune practici din acest ghid de stil sunt adoptate pe baza experienței de lucru cu o mulțime de echipe. Unele dintre ele provin din încercare prin eroare, iar altele sunt inspirate de unele abordări populare precum BEM. Pentru unele reguli nu există un motiv specific pentru care și cum au fost stabilite. Uneori este suficient să ai experiența trecută ca singur motiv. De exemplu, pentru a vă asigura că codul este lizibil, este important ca toți dezvoltatorii să scrie codul în același mod, astfel că există regula de a nu include spații între paranteze. Putem argumenta dacă este mai bine să includem spațiul dintre paranteze sau nu. Dacă credeți că arată mai bine când există spații între paranteze, ajustați acest ghid de stil și regulile după preferințe. În cele din urmă, scopul principal al ghidului de stil este de a defini reguli și de a face procesul de dezvoltare mai standard.

Reguli generale CSS

Regulile generale trebuie respectate întotdeauna. Acestea se concentrează în principal pe modul în care codul Sass ar trebui să fie formatat pentru a aduce coerență și lizibilitate codului:

• Pentru indentare, utilizați spații în loc de file. Cea mai bună practică este să folosiți 2 spații. Puteți conduce propriul război sacru cu această opțiune și vă puteți defini propria regulă și puteți utiliza fie file, fie spații, sau orice vi se potrivește cel mai bine. Este important doar să definiți o regulă și să urmați acea regulă în timp ce fiți consecvenți.
• Includeți o linie goală între fiecare declarație. Acest lucru face codul mai ușor de citit de om, iar codul este scris de oameni, nu?
• Utilizați un selector pe linie, astfel:

 selector1, selector2 { }

• Nu includeți un spațiu între paranteze.

 selector { @include mixin1($size: 4, $color: red); }

• Folosiți ghilimele simple pentru a include șiruri și adrese URL:

 selector { font-family: 'Roboto', serif; }

• Încheiați toate regulile cu punct și virgulă fără spații înainte:

 selector { margin: 10px; }

Reguli pentru selectori

În continuare, urmăm un set de reguli de utilizat atunci când avem de-a face cu selectori:

• Evitați utilizarea selectoarelor ID. ID-urile sunt prea specifice și sunt folosite mai ales pentru acțiuni JavaScript.
• Evitați !important . Dacă trebuie să utilizați această regulă, înseamnă că ceva nu este în regulă cu regulile dvs. CSS în general și că CSS-ul dvs. nu este bine structurat. CSS cu multe reguli !important poate fi ușor abuzat și se termină cu cod CSS dezordonat și greu de întreținut.
• Nu utilizați selectorul pentru copii. Această regulă împărtășește același raționament ca și cel ID. Selectoarele de copii sunt prea specifice și sunt strâns legate cu structura dvs. HTML.

Păstrează-ți regulile Sass în ordine

Este important să păstrați coerența în cod. Una dintre reguli este că trebuie să păstrați ordinea regulilor. În acest fel, alți dezvoltatori pot citi codul cu mult mai multă înțelegere și vor petrece mai puțin timp pentru a-și găsi drumul. Iată comanda propusă:

1. Utilizați mai întâi @extend . Acest lucru vă permite să știți la început că această clasă moștenește reguli din altă parte.
2. Utilizați @include next. Este plăcut să aveți mixurile și funcțiile incluse în partea de sus și, de asemenea, vă permite să știți ce veți suprascrie (dacă este necesar).
3. Acum puteți scrie regulile obișnuite ale clasei sau ale elementelor CSS.
4. Plasați pseudoclase imbricate și pseudo elemente înaintea oricărui alt element.
5. În cele din urmă, scrieți alți selectori imbricați ca în exemplul următor:

 .homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }

Unele convenții de denumire

Partea convențiilor de denumire a cărții de stil se bazează pe cele două convenții de denumire existente BEM și SMACSS care au devenit populare în rândul dezvoltatorilor. BEM înseamnă Block, Element, Modifier. A fost dezvoltat de echipa YANDEX, iar ideea din spatele BEM a fost de a ajuta dezvoltatorii să înțeleagă relația dintre HTML și CSS în proiect. SMACSS, pe de altă parte, înseamnă Arhitectură scalabilă și modulară pentru CSS. Este un ghid pentru structurarea CSS pentru a permite mentenabilitatea.

Inspirat de ele, regulile convențiilor noastre de denumire sunt următoarele:

• Utilizați prefix pentru fiecare tip de element. Prefixați blocurile dvs., cum ar fi: machete ( l- ), module ( m- ) și state ( is- ).
• Utilizați două caractere de subliniere pentru elementele copil pentru fiecare bloc:

 .m-tab__icon {}

• Utilizați două liniuțe pentru modificatori pentru fiecare bloc:

 .m-tab--borderless {}

Variabile

Folosiți variabile. Începeți cu variabilele mai generale și globale, cum ar fi culorile, și creați un fișier separat pentru ele _colors.scss . Dacă observați că repetați o anumită valoare peste foaia de stil de mai multe ori, mergeți și creați o nouă variabilă pentru acea valoare. Te rog USCĂ. Veți fi recunoscător când doriți să schimbați acea valoare și când va trebui să o schimbați într-un singur loc.

De asemenea, utilizați o cratimă pentru a denumi variabilele:

 $red : #f44336; $secondary-red :#ebccd1;

Interogări media

Cu Sass vă puteți scrie interogările media ca interogări de elemente. Majoritatea dezvoltatorilor scriu interogări media într-un fișier separat sau în partea de jos a regulilor noastre, dar acest lucru nu este recomandat. Cu Sass puteți scrie lucruri precum următorul exemplu prin imbricarea interogărilor media:

 // ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

Aceasta generează un CSS ca acesta:

 // Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

Aceste reguli de interogări media imbricate vă permit să știți foarte clar ce reguli suprascrieți, așa cum puteți vedea în fragmentul Sass în care sunt utilizate interogări media numite.

Pentru a crea interogări media denumite, creați mix-ul astfel:

 @mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

Puteți citi mai multe despre denumirea interogărilor media în următoarele articole: Denumirea interogărilor media și Scrieți interogări media mai bune cu Sass.

Alte considerații

În cele din urmă, iată câteva alte considerente pe care ar trebui să le ții cont și să le urmezi:

• Nu scrieți niciodată prefixele de furnizor. Folosiți în schimb autoprefixerul.
• Utilizați maximum trei niveluri de adâncime în regulile imbricate. Cu mai mult de trei niveluri imbricate, codul va fi greu de citit și poate scrieți un selector prost. În cele din urmă, scrieți cod CSS pentru a se cupla cu HTML.

 .class1 { .class2 { li { //last rules } } }

• Nu scrieți mai mult de 50 de linii de cod imbricat: sau mai bine, nu scrieți mai mult de X linii de cod imbricat. Configurați-vă propriul X, dar 50 pare o limită bună. Dacă depășiți această limită, poate că blocul de cod nu va încadra în fereastra editorului dvs. de text.
• Scrieți un fișier principal în care veți importa toate blocurile, parțialele și configurațiile.
• Importați mai întâi dependențele furnizorilor și globale, apoi dependențele de autor, apoi machetele, modelele și, în final, părțile și blocurile. Acest lucru este important pentru a evita importurile mixte și suprascrierea regulilor, deoarece regulile vânzătorului și globale nu pot fi gestionate de noi.
• Nu fi timid și sparge-ți codul în cât mai multe fișiere posibil.

Concluzie

Ideea din spatele acestui ghid de stil este de a vă oferi câteva sfaturi despre cum să îmbunătățiți modul în care scrieți codul Sass. Vă rugăm să rețineți că, chiar dacă nu utilizați Sass, sfaturile și regulile furnizate în acest ghid de stil sunt, de asemenea, aplicabile și recomandate de urmat dacă utilizați Vanilla CSS sau un alt preprocesor. Din nou, dacă nu sunteți de acord cu niciuna dintre reguli, schimbați regula pentru a se potrivi cu modul dvs. de gândire. În cele din urmă, depinde de tine și de echipa ta fie să adaptezi acest ghid de stil, fie să folosești alt ghid de stil, fie să creezi unul complet nou. Doar definiți ghidul și începeți să scrieți un cod minunat.