Przewodnik po stylu Sass: samouczek Sass na temat pisania lepszego kodu CSS

Pisanie spójnego i czytelnego CSS, który będzie się dobrze skalował, jest trudnym procesem. Zwłaszcza, gdy arkusze stylów stają się coraz większe, bardziej złożone i trudniejsze w utrzymaniu. Jednym z narzędzi dostępnych programistom do pisania lepszego CSS są preprocesory. Preprocesor to program, który pobiera jeden rodzaj danych i konwertuje je na inny rodzaj danych, aw naszym przypadku preprocesory CSS to języki preprocesora skompilowane do CSS. Istnieje wiele preprocesorów CSS, które polecają i używają programiści front-end, ale w tym artykule skupimy się na Sassie. Zobaczmy, co Sass ma do zaoferowania, dlaczego jest lepszym wyborem od innych preprocesorów CSS i jak najlepiej zacząć z niego korzystać.

Co to jest Sass i dlaczego warto go używać?

Dla tych z Was, którzy nie wiedzą, czym jest Sass, najlepszym punktem wyjścia jest odwiedzenie oficjalnej strony Sass. Sass to skrót od Syntactically Awesome StyleSheets i jest rozszerzeniem CSS, które dodaje mocy i elegancji do podstawowego języka.

Sass to preprocesor CSS z wieloma potężnymi funkcjami. Najbardziej godnymi uwagi funkcjami są zmienne, rozszerzenia i domieszki.

Zmienne przechowują informacje, które można ponownie wykorzystać później, takie jak kolory lub inne często używane wartości. Rozszerzenia pomagają tworzyć „klasy”, które umożliwiają dziedziczenie reguł. Mixiny, możesz myśleć jak „funkcja”. Sass ma również kilka innych niesamowitych funkcji w porównaniu z innymi preprocesorami, takich jak użycie instrukcji logicznych (warunki i pętle), niestandardowe funkcje, integracja z innymi bibliotekami, takimi jak Compas i wiele innych. Same te funkcje mogą pomóc Tobie i Twojemu zespołowi być bardziej produktywnym i ostatecznie napisać lepszy CSS.

Dlaczego potrzebujesz przewodnika po stylach CSS

Niestety, nawet preprocesory nie są w stanie naprawić wszystkiego i pomóc w pisaniu dobrego kodu CSS. Problem, z którym boryka się każdy programista, polega na tym, że obecne aplikacje internetowe stają się coraz większe. Dlatego kod musi być skalowalny i czytelny oraz musi unikać kodu spaghetti i nieużywanych jego linii. Aby uniknąć wspomnianych problemów, potrzebny jest jakiś standard dla Twojego zespołu w codziennej pracy. Co to jest kod spaghetti i jak to się dzieje? Kod spaghetti to nazwa złego, wolnego, powtarzalnego i nieczytelnego kodu. Kiedy zespół pisze duże aplikacje bez określonych wytycznych lub standardów, każdy programista pisze, czego potrzebuje i jak chce. Również, gdy programiści piszą dużo poprawek błędów, poprawek i łat, mają tendencję do pisania kodu, który rozwiąże problem, ale nie mają czasu na napisanie kodu w najlepszy sposób. W takich sytuacjach bardzo często kończy się to wieloma wierszami CSS, które nie są już używane w żadnym sektorze aplikacji. Deweloperzy nie mają wystarczająco dużo czasu na wyczyszczenie kodu i są zmuszeni opublikować poprawkę tak szybko, jak to możliwe. Inną powtarzającą się sytuacją jest to, że aby szybko naprawić zepsute rzeczy, programiści używają wielu !important , co skutkuje bardzo zręcznym kodem, który jest trudny do utrzymania, skutkuje wieloma nieoczekiwanymi zachowaniami i musi zostać później zrefaktoryzowany. Jak już wspomniano, w miarę rozwoju kodu sytuacja staje się tylko gorsza.

Ideą tego artykułu jest podzielenie się zasadami, wskazówkami i najlepszymi praktykami, aby napisać lepszego Sassa. Zebranie tych wskazówek i najlepszych praktyk Sassa może posłużyć jako przewodnik po stylu Sassa. Ten przewodnik po stylu powinien pomóc programistom uniknąć sytuacji wymienionych powyżej. Reguły są pogrupowane w logiczne segmenty w celu łatwiejszego odwoływania się do nich, ale ostatecznie należy je wszystkie przyjąć i przestrzegać. A przynajmniej większość z nich.

Przewodnik po stylach

Zestaw zasad i najlepszych praktyk w tym przewodniku stylu został przyjęty w oparciu o doświadczenie w pracy z wieloma zespołami. Niektóre z nich pochodzą z metody prób po błędzie, a inne są inspirowane popularnymi podejściami, takimi jak BEM. W przypadku niektórych zasad nie ma konkretnego powodu, dlaczego iw jaki sposób zostały ustalone. Czasami wystarczy mieć doświadczenie z przeszłości jako jedyny powód. Na przykład, aby upewnić się, że kod jest czytelny, ważne jest, aby wszyscy programiści pisali kod w ten sam sposób, dlatego obowiązuje zasada, aby nie umieszczać spacji między nawiasami. Możemy się spierać, czy lepiej jest umieścić spację między nawiasami, czy nie. Jeśli uważasz, że lepiej wygląda, gdy między nawiasami są spacje, dostosuj ten przewodnik po stylu i zasady według własnych preferencji. Ostatecznie głównym celem przewodnika stylu jest zdefiniowanie zasad i ujednolicenie procesu tworzenia.

Ogólne zasady CSS

Należy zawsze przestrzegać ogólnych zasad. Skupiają się głównie na tym, jak należy sformatować kod Sass, aby zapewnić spójność i czytelność kodu:

• Do wcięć używaj spacji zamiast tabulatorów. Najlepszą praktyką jest użycie 2 spacji. Dzięki tej opcji możesz prowadzić własną świętą wojnę i możesz zdefiniować własne zasady i użyć tabulatorów, spacji lub tego, co najbardziej Ci odpowiada. Ważne jest tylko zdefiniowanie reguły i przestrzeganie jej, będąc konsekwentnym.
• Między każdą instrukcją umieść pustą linię. To sprawia, że ​​kod jest bardziej czytelny dla człowieka, a kod jest pisany przez ludzi, prawda?
• Użyj jednego selektora na linię, w ten sposób:

 selector1, selector2 { }

• Nie umieszczaj spacji między nawiasami.

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

• Użyj pojedynczych cudzysłowów, aby zawrzeć ciągi i adresy URL:

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

• Zakończ wszystkie reguły średnikiem bez spacji przed:

 selector { margin: 10px; }

Zasady dla selektorów

Następnie przedstawiamy zestaw reguł, których należy używać podczas pracy z selektorami:

• Unikaj używania selektorów identyfikatorów. Identyfikatory są zbyt szczegółowe i używane głównie do działań JavaScript.
• Unikaj !important . Jeśli musisz użyć tej reguły, oznacza to, że coś jest nie tak z Twoimi regułami CSS, a Twój CSS nie jest dobrze zorganizowany. CSS z wieloma !important regułami może być łatwo nadużywany i kończy się bałaganem i trudnym do utrzymania kodem CSS.
• Nie używaj selektora podrzędnego. Ta zasada ma to samo rozumowanie, co zasada ID. Selektory podrzędne są zbyt szczegółowe i ściśle powiązane ze strukturą HTML.

Utrzymuj swoje zasady Sass w porządku

Ważne jest, aby zachować spójność kodu. Jedną z zasad jest to, że musisz zachować porządek reguł. W ten sposób inni programiści mogą czytać kod ze znacznie większym zrozumieniem i spędzać mniej czasu na szukaniu drogi. Oto proponowana kolejność:

1. Najpierw użyj @extend . Dzięki temu najpierw wiesz, że ta klasa dziedziczy reguły z innych miejsc.
2. Użyj @include dalej. Dobrze jest mieć swoje mixiny i funkcje na górze, a także pozwala wiedzieć, co będziesz nadpisywać (w razie potrzeby).
3. Teraz możesz napisać swoje zwykłe reguły CSS lub elementy.
4. Umieść zagnieżdżone pseudoklasy i pseudoelementy przed jakimkolwiek innym elementem.
5. Na koniec napisz inne zagnieżdżone selektory, jak w poniższym przykładzie:

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

Niektóre konwencje nazewnictwa

Konwencje nazewnictwa Część podręcznika stylów opiera się na dwóch istniejących konwencjach nazewnictwa BEM i SMACSS, które stały się popularne wśród programistów. BEM oznacza blok, element, modyfikator. Został opracowany przez zespół YANDEX, a ideą stojącą za BEM było pomóc programistom zrozumieć związek między HTML i CSS w projekcie. Z drugiej strony SMACSS oznacza Scalable and Modular Architecture for CSS. Jest to przewodnik po strukturze CSS, aby umożliwić utrzymanie.

Zainspirowane nimi, nasze zasady nazewnictwa są następujące:

• Użyj prefiksu dla każdego typu elementu. Poprzedź swoje bloki, takie jak: układy ( l- ), moduły ( m- ) i stany ( is- ).
• Użyj dwóch znaków podkreślenia dla elementów podrzędnych dla każdego bloku:

 .m-tab__icon {}

• Użyj dwóch myślników dla modyfikatorów dla każdego bloku:

 .m-tab--borderless {}

Zmienne

Użyj zmiennych. Zacznij od bardziej ogólnych i globalnych zmiennych, takich jak kolory, i utwórz dla nich osobny plik _colors.scss . Jeśli zauważysz, że wielokrotnie powtarzasz jakąś wartość w arkuszu stylów, idź i utwórz nową zmienną dla tej wartości. Proszę wysuszyć. Będziesz wdzięczny, gdy będziesz chciał zmienić tę wartość i gdy będziesz musiał ją zmienić tylko w jednym miejscu.

Użyj myślnika, aby nazwać zmienne:

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

Zapytania dotyczące mediów

Dzięki Sass możesz pisać zapytania o media jako zapytania elementowe. Większość programistów zapisuje zapytania o media w osobnym pliku lub na dole naszych reguł, ale nie jest to zalecane. Dzięki Sassowi możesz pisać takie rzeczy jak poniższy przykład, zagnieżdżając zapytania o media:

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

To generuje CSS taki jak ten:

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

Te zagnieżdżone reguły zapytań o media pozwalają bardzo wyraźnie wiedzieć, jakie reguły zastępujesz, jak widać we fragmencie Sass, w którym używane są nazwane zapytania o media.

Aby utworzyć nazwane zapytania o media, utwórz swój mixin w następujący sposób:

 @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; } } }

Więcej informacji na temat nazewnictwa zapytań o media można znaleźć w następujących artykułach: Nazywanie zapytań o media i Pisanie lepszych zapytań o media za pomocą Sass.

Inne rozważania

Na koniec oto kilka innych kwestii, o których powinieneś pamiętać i przestrzegać:

• Nigdy nie pisz przedrostków dostawcy. Zamiast tego użyj autoprefiksu.
• Użyj maksymalnie trzech poziomów zagnieżdżonych reguł. Mając więcej niż trzy zagnieżdżone poziomy, kod będzie trudny do odczytania i być może piszesz gówniany selektor. W końcu piszesz kod CSS, który łączy się z kodem HTML.

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

• Nie pisz więcej niż 50 linii kodu zagnieżdżonego: Albo lepiej, nie pisz więcej niż X linii kodu zagnieżdżonego. Ustaw własne X, ale 50 wygląda na dobry limit. Jeśli przekroczysz ten limit, być może blok kodu nie zmieści się w oknie edytora tekstu.
• Napisz główny plik, w którym będziesz importować wszystkie swoje bloki, części i konfiguracje.
• Najpierw importuj zależności od dostawcy i globalne, następnie utworzone zależności, następnie układy, wzorce, a na końcu części i bloki. Jest to ważne, aby uniknąć mieszanych importów i nadpisywania reguł, ponieważ nie możemy zarządzać dostawcami i regułami globalnymi.
• Nie wstydź się i łam kod w jak największej liczbie plików.

Wniosek

Ideą tego przewodnika po stylu jest udzielenie wskazówek, jak ulepszyć sposób pisania kodu Sass. Pamiętaj, że nawet jeśli nie korzystasz z Sassa, wskazówki i zasady przedstawione w tym przewodniku po stylu również mają zastosowanie i zaleca się ich przestrzeganie, jeśli używasz Vanilla CSS lub innego preprocesora. Ponownie, jeśli nie zgadzasz się z żadną z zasad, zmień zasadę, aby pasowała do Twojego sposobu myślenia. Ostatecznie to do Ciebie i Twojego zespołu należy dostosowanie tego przewodnika stylu, skorzystanie z innego przewodnika stylu lub stworzenie zupełnie nowego. Po prostu zdefiniuj przewodnik i zacznij pisać niesamowity kod.