Sass Best Practices Suggerimenti e strumenti per sviluppatori

Molto simile a come jQuery ha rivoluzionato il JavaScript di vaniglia, Sass ha rivoluzionato il vanilla CSS. La maggior parte degli sviluppatori che apprendono Sass concordano sul fatto che non vorranno mai tornare indietro. Molti concordano anche sul fatto che il problema più grande con i nuovi sviluppatori è il modo usano Sass, non Sass stesso.

Ho setacciato il web e ho compilato questo articolo di migliori pratiche per scrivere codice Sass espandibile e riusabile. I suggerimenti provengono dalle mie opinioni personali e da siti Web affidabili come Sass Guidelines.

Sicuramente non è necessario implementare tutte queste funzionalità nel tuo flusso di lavoro. Ma vale la pena di almeno intrattenere queste idee e contemplare i potenziali benefici.

Organizzazione file

Il miglior punto di partenza per lo sviluppo di Sass è l'organizzazione dei file. Se si è già in codice modulare, è necessario comprendere il valore delle importazioni e dei partial (ulteriori informazioni in seguito).

Ma per ora basta dare un'occhiata a questo esempio di struttura di file di DoCSSa. Ho ricreato questa struttura di file che puoi vedere qui sotto:

Questo è solo un suggerimento ed è uno dei tanti modi in cui puoi organizzare i tuoi file. Puoi trovare altri metodi che utilizzano diverse strutture di cartelle come “globali” per SCSS a livello di sito e “pagine” per SCSS specifico per pagina.

Passiamo attraverso questo stile di organizzazione suggerito per esaminare lo scopo di ciascuna cartella:

• / globali - contiene file Sass che vengono applicati a livello di sito come la tipografia, i colori e le griglie
• / componenti - contiene file Sass con stili di componenti come pulsanti, tabelle o campi di input
• / sezioni - contiene file Sass dedicati a pagine o aree specifiche su una pagina (potrebbe funzionare meglio combinato nella cartella / components /)
• / utils - contiene utility di terze parti come Normalize che possono essere aggiornate dinamicamente con strumenti come Bower.
• main.scss - il file Sass principale nella cartella radice che importa tutti gli altri.

Questo è solo un punto di partenza di base e c'è molto spazio per espandersi con le proprie idee.

Ma non importa come tu scelga di organizzare il tuo SCSS, è fondamentale che tu avere qualche organizzazione con un file separato (o cartella) per le librerie come Normalize che devono essere aggiornate, più i componenti in partials di Sass per il tuo progetto.

I partial Sass sono essenziali per le migliori pratiche moderne. Questi sono altamente raccomandati dal team di progettazione di Zurb e da molti altri sviluppatori di frontend professionisti.

Ecco una citazione dal sito Web di Sass che spiega i parziali:

“Puoi creare file Sass parziali contenenti piccoli frammenti di CSS che puoi includere in altri file Sass. Questo è un ottimo modo per modularizza il tuo CSS e aiuta a mantenere le cose più facili da mantenere. Un partial è semplicemente un file Sass chiamato con un trattino basso principale. Potresti nominarlo qualcosa come _partial.scss. Il trattino basso consente a Sass di sapere che il file è solo un file parziale e che non dovrebbe essere generato in un file CSS. I partial Sass sono usati con @importare direttiva.”

Dai uno sguardo anche a questi altri post riguardanti la struttura del file Sass:

• Come strutturo i miei progetti Sass
• Sass Estetico: architettura e stile
• Strutture di directory che ti aiutano a mantenere il tuo codice

Strategie di importazione

Non si può dire abbastanza del valore dell'importazione Sass e dei partial. L'organizzazione del codice è fondamentale per ottenere una struttura di importazione e un flusso di lavoro che funziona correttamente.

Il miglior punto di partenza è un foglio globale contenente importazioni, variabili e mixaggi. Molti sviluppatori preferiscono separare variabili e mixin ma questo si riduce alla semantica.

Tieni presente che i mixin sono un modo per importare, o meglio duplicare, il codice Sass. Sono incredibilmente potenti ma non dovrebbero essere usati con “statico” codice. Tieni presente che c'è una differenza tra mixaggi, estensioni e segnaposti, che hanno tutti un loro utilizzo nello sviluppo di Sass.

Le mixine sono utilizzate al meglio con i valori dinamici passati nel mixin per le alterazioni del codice. Ad esempio, dai un'occhiata a questo mixin di Sass che crea un gradiente di sfondo tra due colori.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Vecchi browser * / background: -moz-linear-gradient (in alto, $ in alto 0%, $ in basso 100%); / * FF3.6 + * / background: -webkit-gradient (lineare, a sinistra in alto, a sinistra in basso, color-stop (0%, $ in alto), color-stop (100%, $ in basso)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (superiore, $ superiore 0%, $ inferiore 100%); / * Chrome10 +, Safari5.1 + * / background: -o-linear-gradient (superiore, $ superiore 0%, $ inferiore 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (superiore, $ superiore 0%, $ inferiore 100%); / * IE10 + * / background: linear-gradient (to bottom, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Il mixin prende due valori: un colore superiore e un colore inferiore. Puoi scrivere diversi mixin per diversi tipi di gradienti che includono 3 o 4+ colori diversi. Ciò consente di importare e clonare il codice mixin cambiando i parametri per le opzioni personalizzate.

L'esempio di Code Responsible assomiglia a questo:

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

Relativo al mixin è il segnaposto di Sass che è principalmente utile con la direttiva extend. È certamente più complesso dei mixin, ma questo può essere un modo per farlo combinare i selettori insieme senza riscrivere il codice in eccesso.

Mentre Sass ha un solo metodo @import, ho incluso mixin e segnaposto per dimostrare la flessibilità del codice che può essere scritto in un file ma incluso ovunque.

Quando si costruisce una struttura di importazione, è sufficiente ricordare i concetti di codifica DRY (Non ripeterti).

Convenzioni di denominazione

Le regole generali per le convenzioni di denominazione si applicano a variabili, funzioni e mixin. Quando si nomina qualcosa in Sass, si consiglia di farlo usa tutte le lettere minuscole con trattini per la separazione.

La sintassi del codice Sass si basa in realtà sul set di regole delle linee guida CSS. Ecco alcune best practice consigliate da tenere a mente:

• due (2) spazi di rientro, nessuna tabulazione
• idealmente, linee larghe 80 caratteri o meno
• uso significativo di spazi bianchi
• usa i commenti per spiegare le operazioni CSS

Questi non sono elementi richiesti per il codice Sass valido. Ma questi suggerimenti provengono da sviluppatori professionisti che hanno trovato che questi set di regole forniscono l'esperienza di codifica più uniforme.

Ma per quanto riguarda le convenzioni di denominazione si può finire con due strutture diverse: una per i nomi Sass e un'altra per i nomi di classi CSS. Alcuni sviluppatori preferiscono i suggerimenti BEM su Sass. Nessuno dei due è più o meno corretto; semplicemente diverso con diverse procedure operative.

Il problema è che BEM non regge bene alle variabili Sass o ai mixin perché non hanno la struttura di blocco / elemento / modificatore (BEM). Personalmente preferisco usare le convenzioni di denominazione Sass ma è possibile provare qualsiasi cosa, da camelCase alla propria sintassi interna.

Quando si organizzano le variabili e i mix sono consigliati dividerli per categoria, quindi elencarli in ordine alfabetico. Questo rende l'editing molto più semplice perché sai esattamente dove trovare qualcosa.

Ad esempio, per cambiare il colore di un collegamento devi aprire il file delle variabili (forse _variables.scss) e individuare la sezione per le variabili di colore. Quindi trova il link per nome (link dell'intestazione, link testuale, ecc.) E aggiorna il colore. Semplice!

Per avere un'idea di come potresti strutturare un sommario per i tuoi file Sass, consulta il file delle impostazioni di Foundation.

 // Foundation for Sites Settings // ----------------------------- // // Sommario: // // 1 Global // 2. Breakpoints // 3. Grid // 4. Typography di base // 5. Typography Helpers ... // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1.5; // eccetera

Un'altra pratica di denominazione riguarda punti di rottura reattivi. Quando si nominano i breakpoint di Sass, provare ad evitare nomi specifici del dispositivo. È meglio scrivere nomi come small, med, lg e xlg perché sono relativamente l'uno all'altro.

Questo è migliore per le relazioni interne tra i punti di interruzione, ma è ottimo anche per i team in cui gli sviluppatori potrebbero non sapere quali dispositivi si correlano tra loro.

Per quanto riguarda la soppressione dei nomi, è consigliabile che tu essere il più specifico possibile senza variabili extra lunghe. Dovresti adottare convenzioni di denominazione a livello di sito facili da ricordare durante la codifica.

Fornisci convenzioni di denominazione specifiche per tutto, ad esempio colori, margini, pile di caratteri e altezze delle linee. Non solo è possibile richiamare rapidamente i nomi, ma è possibile semplifica il tuo lavoro quando scrivi nuovi nomi di variabili che devono corrispondere a una sintassi esistente.

Ma c'è un linea sottile tra specificità e convoluzione. La pratica ti aiuterà a trovare quella linea, e scrivere più nomi memorabili rende più facile copiare il codice in altri progetti.

Nesting And Looping

Queste due tecniche di Sass sono molto diverse nell'azione, eppure entrambe hanno il possibilità di essere abusato se non utilizzato in modo adeguato.

annidamento è il processo di aggiungere selettori annidati insieme tramite indentazione per creare più specificità con meno codice. Sass ha una guida per il nesting che illustra esempi di nesting del codice in azione. Ma è facile lasciarsi trasportare dalla nidificazione. Se sei troppo zelante puoi finire con un codice che assomiglia a questo:

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

Fin troppo specifico e quasi impossibile da sovrascrivere, questo tipo di codice sconfigge lo scopo dei fogli di stile a cascata.

Sfiorando questa guida SitePoint troverai tre regole d'oro per la nidificazione:

• Non superare mai più di 3 livelli.
• Assicurati che l'output CSS sia pulito e riutilizzabile.
• Usa l'annidamento quando ha senso, non come opzione predefinita.

Lo sviluppatore Josh Broton suggerisce di annidare quando necessario, indentare il resto come regola generale di sintassi.

L'indentazione dei selettori non causerà alcun effetto CSS a cascata. Ma avrai un tempo più facile sfogliando il tuo file Sass individuando le classi correlate tra loro.

Loops può anche essere abusato se non applicato correttamente. I tre loop di Sass sono @per, @mentre, e @ogni. Non entrerò nei dettagli su come funzionano tutti, ma se sei interessato dai un'occhiata a questo post.

Invece mi piacerebbe coprire il scopo per l'utilizzo di loop e come funzionano in Sass. Questi dovrebbero essere usati per risparmiare tempo scrivendo codice che può essere automatizzato. Ad esempio, ecco uno snippet di codice dal post di Clubmate che mostra un codice Sass seguito dall'output:

/ * Codice Sass * / @for $ i da 1 a 8 $ larghezza: percentuale (1 / $ i) .col - # $ i larghezza: $ larghezza;  / * output * / .col-1 width: 100%; .col-2 width: 50%; .col-3 width: 33.333%; .col-4 width: 25%;  .col-5 width: 20%; .col-6 width: 16,666%; .col-7 width: 14,285%; .col-8 larghezza: 12,5%;

Queste classi di colonne possono essere utilizzate in combinazione con un sistema di griglia. Potresti anche aggiungere più colonne o rimuoverne alcune semplicemente modificando il codice loop.

Loops dovrebbero non essere utilizzato per duplicare selettori o proprietà per un selettore; ecco a cosa servono i mixin.

Inoltre, durante il ciclo, c'è qualcosa chiamato mappe Sass che memorizza la chiave: coppie di dati di valore. Gli utenti esperti dovrebbero approfittarne quando possibile.

Ma i normali loop di Sass sono semplici ed efficaci nel fornire output di codice senza ripetizioni. La migliore ragione per usare i loop è con Proprietà CSS che variano l'output dei dati.

Ecco un buon modo per verificare se il tuo ciclo è utile: chiediti se c'è un altro modo di produrre il CSS che ti serve con meno linee di codice. In caso contrario, la sintassi del loop è probabilmente una grande idea.

Se sei sempre confuso o vuoi un feedback su nidificazione o loop di Sass, devi pubblicare una domanda in / r / sass / o / r / css /, comunità Reddit attive con sviluppatori Sass ben informati.

La modularizzazione

La pratica di scrivere Sass modulare è una necessità assoluta per la maggior parte dei progetti (direi, ogni progetto). La modularizzazione è il processo di abbattere un progetto in moduli più piccoli. Questo può essere fatto usando Sass parziali.

L'idea alla base di Sass modulare è quella di scrivere singoli file SCSS con uno scopo specifico di targeting del contenuto globale (tipografia, griglie) o elementi di pagina (schede, moduli).

La definizione del modulo Sass è abbastanza chiara e fornisce un suggerimento molto specifico: l'importazione di un modulo non dovrebbe mai generare un codice.

L'idea di output obbligatorio per tutti i moduli sarebbe un incubo per l'ottimizzazione. Invece dovresti creare i moduli individualmente e chiama solo quelli di cui hai bisogno. I moduli possono essere definiti da mixin o funzioni, ma è possibile creare moduli che contengono anche selettori.

Tuttavia un articolo di Sass Way suggerisce di scrivere tutti i selettori come mixin e li chiama solo se necessario. Che tu lo adotti o meno è in definitiva la tua scelta. Penso che dipenda dalle dimensioni del progetto e dal tuo comfort con la gestione dei mix.

Citando John Long dal suo post su The Sass Way:

“Per me, i moduli sono diventati le unità di base o gli elementi costitutivi dei miei progetti Sass.”

Se stai davvero cercando una routine Sass, ti consiglio di andare completamente modulare. Prova a creare quasi tutto come parziale modulare che viene incluso in un file CSS primario. All'inizio questo flusso di lavoro può sembrare scoraggiante, ma ha un senso su una scala più grande, specialmente con i grandi progetti.

Inoltre, è molto più semplice copiare i moduli da un progetto a un altro quando si trovano in file separati. Flessibilità e codice riutilizzabile sono i capisaldi dello sviluppo modulare.

Per saperne di più sui moduli Sass e sulle tecniche di modularizzazione, controlla questi post:

• Moduli CSS: Welcome to the Future
• I pro e i contro di Modular Sass
• Organizzazione CSS modulare con SMACSS e SASS

Trova il tuo flusso di lavoro perfetto

Ogni team e singolo sviluppatore ha le proprie pratiche che funzionano meglio. Dovresti adottare le pratiche che funzionano meglio per te personalmente o scegliere di adottare quelle che funzionano meglio per la tua squadra professionalmente.

Considerare inoltre l'utilizzo di Gulp o Grunt per l'automazione del progetto e la minimizzazione del codice. Ciò farà risparmiare un sacco di lavoro manuale e gli strumenti di automazione sono ora senza dubbio parte delle migliori pratiche per lo sviluppo del frontend moderno.

Scorri le librerie open source come SCSS di Foundation su GitHub per saperne di più sulle best practice utilizzate da altre biblioteche.

La cosa sulle migliori pratiche è che migliorano davvero il tuo lavoro la maggior parte del tempo, ma ci sono molte alternative. Basta provare le cose e vedere come si sentono. Imparerai sempre così le tue migliori pratiche potrebbero cambiare rapidamente nel corso di 5 anni.

Un ultimo suggerimento che ho per l'intero processo di Sass è quello di prendere decisioni con chiarezza in mente. Scrivi un codice che faciliti il ​​tuo lavoro. Non complicare eccessivamente un progetto se esiste un modo più semplice per farlo.

Sass ha lo scopo di migliorare l'esperienza di sviluppo CSS, quindi lavorare con chiarezza e buone pratiche per ottenere la migliore esperienza possibile.

Incartare

La congestione in un flusso di lavoro Sass può essere corretta modificando gli stili del codice e seguendo le migliori pratiche. Ho delineato una manciata di suggerimenti in questo post forniti dai blog di Sass e dagli sviluppatori professionisti.

Il modo migliore per saperne di più è applicare queste pratiche nel tuo flusso di lavoro e guarda cosa funziona. Nel corso del tempo scoprirai che alcune attività sono più vantaggiose di altre, nel qual caso dovresti mantieni ciò che funziona e lascia perdere ciò che non funziona.

Dai un'occhiata a questi link per trovare altri suggerimenti e best practice per lo sviluppo di Sass:

• Linee guida Sass
• Una visione per il nostro Sass
• 8 consigli per aiutarti a ottenere il meglio da Sass
• Estendere in Sass senza creare un disordine
• Best practice di Sass: nidificazione di più di 3 livelli