Sass Best Practices tippek és eszközök a fejlesztők számára

Olyan, mint a jQuery forradalmasította a vanília JavaScript-et, Sass forradalmasította a vanília CSS-t. A legtöbb Sass-ot tanuló fejlesztő egyetért abban, hogy soha nem akarnak visszamenni. Sokan egyetértenek abban is, hogy az új fejlesztők legnagyobb problémája a út Sassot használják, nem maga Sass.

Kihajtottam az internetet, és összeállítottam ezt a cikket legjobb gyakorlatok a bővíthető és újrafelhasználható Sass kód írására. A javaslatok a saját véleményeimből és a megbízható weboldalakról, mint a Sass irányelvek.

Nem feltétlenül kell ezeket a funkciókat végrehajtani a munkafolyamatba. De érdemes legalább ezeket az ötleteket szórakoztatni és a lehetséges előnyöket megfontolni.

Fájlszervezés

A Sass fejlesztésével a legjobb hely a fájlszervezés. Ha már be van állítva a moduláris kódba, akkor meg kell értenie az import értékét és a részleges értékeket (ezek közül többet később).

De most csak nézd meg ezt a fájlszerkezeti példát a DoCSSáról. Újra létrehoztam ezt a fájlstruktúrát, amelyet az alábbiakban láthat:

Ez csak egy javaslat, és ez az egyik módja a fájlok rendezésének. Más módszereket is találhat, amelyek különböző mappa struktúrákat használnak “globals” az egész webhelyre kiterjedő SCSS és “oldalak” oldalspecifikus SCSS-hez.

Nézzük át ezt a javasolt szervezeti stílust, hogy megvizsgáljuk az egyes mappák célját:

• / globals - tartalmaz olyan Sass fájlokat, amelyek az egész területre kiterjednek, mint a tipográfia, a színek és a rácsok
• /alkatrészek - tartalmazza a Sass-fájlokat összetevőstílusokkal, például gombokkal, táblázatokkal vagy beviteli mezőkkel
• / részt - tartalmaz egy adott oldalra vagy területre szánt Sass-fájlokat (lehet, hogy jobban egyesülnek a / komponensek / mappák között)
• / utils - tartalmaz harmadik féltől származó segédprogramokat, például a Normalizálást, amely dinamikusan frissíthető olyan eszközökkel, mint a Bower.
• main.scss - az elsődleges Sass-fájlt az összes többi importáló gyökérmappájában.

Ez csak egy alapvető kiindulópont, és rengeteg hely van a saját ötleteivel bővíteni.

De függetlenül attól, hogy hogyan kívánja megszervezni a SCSS-t, elengedhetetlen, hogy Ön van valamilyen szervezet egy külön fájl (vagy mappa) számára olyan könyvtárakhoz, mint a Normalizálás, amelyet frissíteni kell, valamint a Sass részleges részeit a projekthez.

A Sass részleges részei elengedhetetlenek a modern legjobb gyakorlatokhoz. Ezeket a Zurb tervezőcsoportja és számos más professzionális frontend fejlesztő ajánlja.

Íme egy idézet a Sass weboldalról, amely magyarázza a részlegeseket:

“Létrehozhat részleges Sass-fájlokat, amelyek kis CSS-részleteket tartalmaznak, amelyeket más Sass-fájlokba is be lehet illeszteni. Ez egy nagyszerű módja modulálja a CSS-t, és segítse a dolgok könnyebb karbantartását. A részleges egyszerűen egy Sass-fájl, amelyet egy vezető aláhúzással neveztek el. Lehet, hogy megnevezed valamit _partial.scss. Az aláhúzás lehetővé teszi, hogy Sass tudja, hogy a fájl csak részleges fájl, és nem kell CSS fájlba generálni. A Sass részleges részeket használják a @import irányelv.”

Tekintse meg ezeket a többi hozzászólást a Sass fájlszerkezetével kapcsolatban:

• Hogyan strukturálom a Sass projektjeimet
• Esztétikus Sass: Építészet és stílusszervezés
• A kódok karbantartását segítő könyvtárszerkezetek

Import stratégiák

A Sass behozatalának és részleges értékeinek értékéről nem mondható elég. A kódrendszer kulcsfontosságú ahhoz, hogy egy importstruktúrát és munkafolyamatot kapjunk, ami csak működik.

A legjobb hely az induláshoz, ha importálunk, változókat és mixeket tartalmazó globális lapokat. Számos fejlesztő inkább a változókat és a mixineket választja, de ez a szemantikához vezet.

Ne feledje, hogy a mixins a Sass-kód importálásának vagy megismétlésének módja. Hihetetlenül erősek, de nem használhatók “statikus” kód. Ne feledje, hogy különbség van a mixins, kiterjesztések és helyőrzők között, amelyek mindegyiküket a Sass fejlesztésében használják.

A Mixins a legjobban használható a dinamikus értékek átadására a mixinben a kódváltozásokhoz. Például nézd meg ezt a Sass mixint, amely két szín közötti gradienst hoz létre.

@mixin lineárisGradient ($ top, $ bottom) háttér: $ top; / * Régi böngészők * / háttér: -moz-lineáris gradiens (top, $ top 0%, $ bottom 100%); / * FF3.6 + * / háttér: -webkit-gradiens (lineáris, bal felső, bal alsó, szín-stop (0%, $ top), szín-stop (100%, $ bottom)); / * Chrome, Safari4 + * / háttér: -webkit-lineáris gradiens (top, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / háttér: -o-lineáris gradiens (top, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / háttér: -ms-lineáris gradiens (top, $ top 0%, $ bottom 100%); / * IE10 + * / háttér: lineáris gradiens (alul, $ top 0%, $ alsó 100%); / * W3C * / szűrő: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

A mixin két értéket vesz fel: a felső színt és az alsó színt. Különböző keverékeket írhat a különböző színátmenetekre, amelyek 3 vagy 4+ különböző színt tartalmaznak. Ez lehetővé teszi, hogy importálja és klónozza a mixin kódot, miközben megváltoztatja az egyéni beállítások paramétereit.

A Code Responsible példája így néz ki:

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

A mixinhez kapcsolódik a Sass helyőrző, amely elsősorban a kiterjesztési irányelvben hasznos. Valószínűleg bonyolultabb, mint a mixins, de ez lehet egy módja annak kombinálja a szelektorokat, anélkül, hogy a felesleges kódot újraírná.

Míg a Sassnak csak egy @import módja van, a mixins és helyőrzőket is beillesztettem, hogy bemutassam a kód rugalmasságát, amely egy fájlban írható, de bárhol szerepel..

Egy importszerkezet építésekor ne felejtse el követni a DRY kódolás fogalmát (ne ismételje meg magát).

Megnevezési egyezmények

Az egyezmények elnevezésére vonatkozó általános szabályok a változókra, a funkciókra és a keverékekre vonatkoznak. Amikor Sass-ban bármit megneveznek, ajánlott használjon minden kisbetűt elválasztójelekkel.

A Sass-kód szintaxis valójában a CSS-irányelvszabályokra épül. Íme néhány ajánlott legjobb gyakorlat, melyet szem előtt kell tartani:

• két (2) szóköz, nincs lap
• ideális esetben 80 karakter hosszú vagy kevesebb vonalak
• a szóköz hasznos felhasználása
• a CSS műveletek magyarázatához használja a megjegyzéseket

Ezek nem szükségesek az érvényes Sass kódhoz. De ezek a javaslatok szakmai fejlesztőktől származnak találták, hogy ezek a szabályok a legegységesebb kódolási élményt nyújtják.

Az elnevezési egyezmények tekintetében azonban két különböző struktúrával lehet végezni: egyet a Sass nevekre, a másik pedig a CSS osztályneveket. Néhány fejlesztő a BEM-t a Sass-javaslatok felett ajánlja. Egyikük sem több, sem kevésbé helyes; különbözik a különböző működési eljárásoktól.

A probléma az, hogy a BEM nem továbbítja jól a Sass változókat vagy keverékeket, mert nincsenek blokk / elem / módosító (BEM) struktúrájuk. Én személy szerint szívesebben használom a Sass elnevezési konvenciókat, de bármit megpróbálhatsz a camelCase-ből a saját belső szintaxisodra.

A változók és keverékek szervezésénél ajánlott osztja fel őket kategóriák szerint, majd jegyezze fel őket ábécé sorrendben. Ez sokkal egyszerűbbé teszi a szerkesztést, mert pontosan tudja, hol talál valamit.

Például egy hivatkozás színének megváltoztatásához nyissa meg a változófájlt (talán _variables.scss) és keresse meg a színváltozók szekcióját. Ezután keresse meg a nevet (fejléc, szöveges hivatkozás, stb.) És frissítse a színt. Egyszerű!

Ha meg szeretné tudni, hogyan strukturálhatja a Sass fájlok tartalmi táblázatait, nézze meg az Alapítvány beállításfájlját.

 // A webhelyek beállításának alapja // ----------------------------- // Tartalomjegyzék // // 1 Globális // 2. Töréspontok // 3. A rács // 4. Alap tipográfia // 5. Tipográfiai segítők… // 1. Globális // --------- $ globális-betűméret: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // stb

Egy másik elnevezési gyakorlat vonatkozik reagálási pontok. A Sass töréspontok megnevezésekor próbálja meg elkerülni az eszközspecifikus neveket. Jobb, ha olyan neveket írunk, mint a kis, a med, az lg és az xlg egymáshoz képest.

Ez jobb a töréspontok közötti belső kapcsolatok esetében, de nagyszerű azoknak a csapatoknak is, ahol a fejlesztők nem tudják, hogy mely eszközök kapcsolódnak egymáshoz.

Ami a nevek tényleges elhelyezését illeti, akkor ajánlott minél pontosabbnak kell lennie extra hosszú változók nélkül. Neked kellene fogadjon el az egész területre kiterjedő, könnyen emlékezhető elnevezési konvenciókat kódolás közben.

Adjon meg konkrét elnevezési szabályokat mindent, mint a színek, a margók, a betűkészletek és a vonalmagasságok. Nem csak a neveket lehet gyorsan visszahívni, hanem az is megkönnyíti a munkát, ha új változóneveket ír be, amelyeknek meg kell egyezniük egy meglévő szintaxissal.

De van egy finom vonal a specifitás és a konvolúció között. A gyakorlat segít megtalálni ezt a sort, és több emlékezetes név írása megkönnyíti a kód más más projektekbe történő másolását.

Fészkelés és hurok

Ezek a két Sass technika nagyon különböznek egymástól, de mindkettőnek van a visszaélés képességét, ha nem használják őket figyelmesen.

fészekrakó a folyamat a bemélyedésekkel együtt beágyazott szelektorok hozzáadásával kevesebb kóddal több specifitás jön létre. Sassnak van egy fészkelő útmutatója, amely a példakénti példákat szemlélteti az akcióban. De könnyű eljutni a fészkeléssel. Ha túlságosan elbűvöl, akkor a következő kódot kaphatja:

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

Túl specifikus és szinte lehetetlen felülírni ezt a típusú kódot, ami a kaszkád stílusú stíluslapok célját elveszi.

A SitePoint útmutató áthidalása három arany szabályt tartalmaz a fészkelésre:

• Soha ne menjen több mint 3 szintre.
• Győződjön meg róla, hogy a CSS kimenet tiszta és újrafelhasználható.
• Használja a fészkelést, ha értelme van, nem pedig alapértelmezett beállításnak.

A Josh Broton fejlesztő szükség esetén fészkelést javasol, a többit általános szintaxis szabályként adja be.

A szelektorok behelyezése nem okoz CSS-effektusokat. De könnyebb lesz a Sass-fájlod korlátlan leírása, hogy mely osztályok kapcsolódnak egymáshoz.

A hurkok is túlzottan használható, ha nem megfelelően alkalmazzák. A három Sass hurok @for, @míg, és @minden egyes. Nem fogok részletesen elmagyarázni, hogyan működnek, de ha érdekel, nézd meg ezt a hozzászólást.

Ehelyett szeretném lefedni a a hurkok használatának célja és hogyan működnek Sassban. Ezeket az idő automatizálható időírási kódok mentésére kell használni. Például itt van egy kódrészlet a Clubmate-hozzászólásból, amely bemutat néhány Sass-kódot, amelyet a kimenet követ:

/ * Sass kód * / @ for $ i 1-től 8-ig $ szélesség: százalék (1 / $ i) .col - # $ i szélesség: $ szélesség;  / * kimenet * / .col-1 szélesség: 100%;.-2 szélesség: 50%;.-3 szélesség: 33,333%;.-4 szélesség: 25%;  .col-5 szélesség: 20%;. -6 szélesség: 16,666%;.-7 szélesség: 14,285%;.-8 szélesség: 12,5%;

Ezek az oszloposztályok rácsrendszerrel együtt használhatók. Még több oszlopot is hozzáadhat, vagy néhányat csak a hurokkód szerkesztésével távolíthat el.

Loops kellene nem a szelektorok vagy a szelektor tulajdonságainak megkettőzéséhez; ez az, amire a mixins.

Szintén, amikor hurok van, van valami Sass térkép, amely a kulcsot tárolja: az adatpárok értéke. A fejlett felhasználóknak lehetőség szerint ki kell használniuk ezeket.

De a rendszeres Sass hurkok egyszerűek és hatékonyak a kódkimenet ismétlés nélkül történő biztosításához. A hurkok használatának legjobb oka a Az adatok kimenetét módosító CSS ​​tulajdonságok.

Itt van egy jó mód annak ellenőrzésére, hogy a hurok hasznos-e: kérdezd meg magad ha van más módja annak, hogy a szükséges CSS-t kevesebb sorral adja ki. Ha nem, akkor a hurokszintaxis valószínűleg nagyszerű ötlet.

Ha valaha összetévesztett vagy visszajelzést szeretne a fészkelő vagy a Sass hurkokról, akkor a / r / sass / vagy a / r / css /, aktív Reddit közösségekben egy nagyon jól ismerős Sass fejlesztővel kell egy kérdést feltenni.

modularizáció

A moduláris Sass írásának gyakorlata abszolút szükséges a legtöbb projekthez (azt állítom, minden projekt). A modularizáció a folyamat egy projekt kisebb modulokra bontása. Ezt Sass segítségével lehet elvégezni felhangok.

A moduláris Sass mögött álló ötlet az, hogy egyedi SCSS-fájlokat írjon be egy speciális célú globális tartalommal (tipográfia, rácsok) vagy oldalelemekkel (lapok, űrlapok).

A Sass modul definíciója meglehetősen világos, és nagyon konkrét javaslatot tesz: a modul importálása soha nem adja ki a kódot.

A modulok kötelező kimenetének ötlete az optimalizálás rémálma lenne. Ehelyett modulokat kell létrehozni egyénileg és csak a szükségeseket hívja. A modulokat mixinek vagy funkciók határozzák meg, de lehet olyan modulokat is létrehozni, amelyek szelektort is tartalmaznak.

Azonban a Sass Way cikk azt javasolja, hogy minden szelektorot mixinnek írjanak, és csak szükség szerint hívják őket. Akár ezt elfogadja, akár nem, végső soron a választás. Azt hiszem, ez a projekt nagyságától és a mixin kezelése kényelmétől függ.

Idézve John Long-t a The Sass Way-ről szóló hozzászólásából:

“Számomra a modulok a Sass projektjeim alapegységei vagy építőkövei lettek.”

Ha tényleg egy Sass-rutint keres, azt javaslom, hogy teljes mértékben moduláris legyen. Próbálj meg szinte mindent építeni, mint egy moduláris részleges részt, amely egy elsődleges CSS fájlba kerül. Először ez a munkafolyamat ijesztőnek tűnhet, de komolyabb értelemben - különösen nagy projekteknél - érthető.

Ráadásul sokkal könnyebb másolni a modulokat egy projektből a másikba, ha külön fájlokban találhatók. Rugalmasság és újrafelhasználható kód a moduláris fejlesztés sarokkövei.

Ha többet szeretne megtudni a Sass modulokról és a modularizációs technikákról, nézze meg ezeket a bejegyzéseket:

• CSS modulok: Üdvözöljük a jövőben
• A moduláris Sass előnyei és hátrányai
• Moduláris CSS szervezet SMACSS & SASS rendszerrel

Keresse meg a tökéletes munkafolyamatot

Minden csapatnak és egyéni fejlesztőnek van saját gyakorlata, amely a legjobban működik. El kell fogadnia a legjobban az Ön számára legmegfelelőbb gyakorlatokat, vagy úgy dönt, hogy elfogadja azokat, amelyek szakemberei számára a legjobban megfelelnek.

A projektautomatizáláshoz és a kód tömörítéséhez vegye figyelembe a Gulp vagy a Grunt használatát is. Ezzel sok kézi munka és az automatizálási eszközök kétségtelenül részét képezik a modern frontend fejlesztés legjobb gyakorlatainak.

Nézze át a nyílt forráskódú könyvtárakat, mint például az Alapítvány SCSS a GitHub-on, hogy többet megtudjon a más könyvtárak által alkalmazott legjobb gyakorlatokról.

A legjobb gyakorlatokban az a tény, hogy a legtöbb esetben valóban javítják a munkát, de sok alternatíva van. Csak próbálja meg a dolgokat, és nézze meg, hogyan érzik magukat. Mindig tanulni fog, így a legjobb gyakorlata gyorsan változhat 5 év alatt.

Egy végső javaslat, amit az egész Sass-folyamathoz tartok, az a döntéseket egyértelművé kell tenni. Írjon kódot, amely megkönnyíti a munkát. Ne bonyolítson túl egy projektet, ha egyszerűbb módja van ennek.

A Sass célja, hogy fokozza a CSS fejlesztési tapasztalatait tisztán és a legjobb gyakorlatokkal hogy a lehető legjobb élményt kapja.

Wrap-Up

A Sass munkafolyamatban a forgalmi torlódások korrigálhatók a kódstílusok és a legjobb gyakorlatok követésével. A Sass blogok és a professzionális fejlesztők által készített hozzászólásban néhány javaslatot vázoltam fel.

A legjobb módja annak, hogy többet megtudjunk, hogy ezeket a gyakorlatokat alkalmazzuk a munkafolyamatba és nézze meg, mi működik. Idővel meg fogod találni, hogy néhány tevékenység előnyösebb, mint mások, és ebben az esetben tartsd meg a dolgokat, és dobd le, ami nem.

Tekintse meg ezeket a linkeket, hogy további tippeket és legjobb gyakorlatokat találjon a Sass fejlesztéshez:

• Sass irányelvek
• A látás a mi Sassunkról
• 8 Tippek a Sass-tól a legjobb megoldáshoz
• A Sass-ban való kibontás anélkül, hogy hozza létre a rendetlenséget
• Sass Best Practices - Több mint 3 szint mélysége