Sass Best Practices Wskazówki i narzędzia dla programistów

Podobnie jak jQuery zrewolucjonizował waniliowy JavaScript, Sass zrewolucjonizował waniliowy CSS. Większość programistów, którzy uczą się Sassa, zgadza się, że nigdy nie chcą wrócić. Wielu zgadza się również, że największym problemem nowych deweloperów jest sposób używają Sassa, a nie samego Sassa.

Przeszukałem sieć i skompilowałem ten artykuł sprawdzone metody pisania rozszerzalnego i wielokrotnego użytku kodu Sass. Sugestie pochodzą z moich własnych opinii i zaufanych stron internetowych, takich jak Sass Guidelines.

Z pewnością nie musisz wdrażać wszystkich tych funkcji w swoim obiegu pracy. Ale warto przynajmniej zabawiać się tymi pomysłami i rozważać potencjalne korzyści.

Organizacja plików

Najlepszym miejscem do rozpoczęcia rozwoju Sass jest organizacja plików. Jeśli masz już kod modułowy, powinieneś zrozumieć wartość importu i części (więcej na ten temat później).

Ale na razie spójrz na przykład struktury plików z DoCSSa. Odtworzyłem tę strukturę plików, którą możesz zobaczyć poniżej:

To tylko sugestia i jest to jeden z wielu sposobów organizacji plików. Możesz znaleźć inne metody, które używają różnych struktur folderów, takich jak “globals” dla SCSS w całej witrynie i “stron” dla SCSS specyficznego dla strony.

Przejdźmy przez ten sugerowany styl organizacji, aby zbadać cel każdego folderu:

• / globals - zawiera pliki Sass, które są stosowane w całym serwisie, takie jak typografia, kolory i siatki
• /składniki - zawiera pliki Sass ze stylami komponentów, takimi jak przyciski, tabele lub pola wejściowe
• /Sekcje - zawiera pliki Sass dedykowane określonym stronom lub obszarom na stronie (może działać lepiej w połączeniu z folderem / components /)
• / utils - zawiera narzędzia innych firm, takie jak Normalize, które można dynamicznie aktualizować za pomocą narzędzi takich jak Bower.
• main.scss - podstawowy plik Sass w folderze głównym, który importuje wszystkie inne.

To tylko podstawowy punkt wyjścia i jest mnóstwo miejsca na rozbudowę dzięki własnym pomysłom.

Ale bez względu na to, jak zdecydujesz się zorganizować swój SCSS, ważne jest, abyś mieć jakąś organizację z oddzielnym plikiem (lub folderem) dla bibliotek takich jak Normalize, które wymagają aktualizacji, plus elementy w częściach Sass dla twojego projektu.

Częściowe części Sass są niezbędne dla nowoczesnych najlepszych praktyk. Są one bardzo zalecane przez zespół projektowy Zurb i wielu innych profesjonalnych programistów frontendowych.

Oto cytat ze strony internetowej Sass wyjaśniający częściowe:

“Możesz tworzyć częściowe pliki Sass, które zawierają małe fragmenty CSS, które możesz dołączyć do innych plików Sass. To świetny sposób na zmodularyzuj swój CSS i pomóż utrzymywać rzeczy w łatwiejszym stanie. Częściowy to po prostu plik Sass o nazwie z wiodącym podkreśleniem. Możesz nazwać to jakoś _partial.scss. Podkreślenie pozwala Sassowi wiedzieć, że plik jest tylko częściowym plikiem i nie powinien być generowany w pliku CSS. Części cząstkowe Sass są używane z @import dyrektywa.”

Zobacz także inne posty dotyczące struktury plików Sass:

• Jak konstruuję moje projekty Sass
• Aesthetic Sass: Organizacja architektury i stylu
• Struktury katalogów, które pomagają w utrzymaniu kodu

Strategie importu

Nie można powiedzieć wystarczająco dużo o wartości importu Sass i jego części. Organizacja kodu jest kluczem do uzyskania struktury importu i przepływu pracy, który po prostu działa.

Najlepiej zacząć od arkusza globals zawierającego import, zmienne i miksy razem. Wielu programistów woli oddzielać zmienne i miksy, ale sprowadza się to do semantyki.

Pamiętaj, że miksy są sposób importowania, a raczej duplikowania kodu Sass. Są niesamowicie potężne, ale nie powinny być używane “statyczny” kod. Należy pamiętać, że istnieje różnica między miksami, rozszerzeniami i symbolami zastępczymi, z których wszystkie mają zastosowanie w rozwoju Sass.

Miksy są najlepiej używane z dynamicznymi wartościami przekazywanymi do miksu w celu zmiany kodu. Na przykład sprawdź ten miks Sass, który tworzy gradient tła między dwoma kolorami.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Stare przeglądarki * / tło: -moz-linear-gradient (góra, $ top 0%, $ dół 100%); / * FF3.6 + * / background: -webkit-gradient (liniowy, lewy górny, lewy dolny, zatrzymanie koloru (0%, $ górny), zatrzymanie koloru (100%, $ dół)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (góra, $ top 0%, $ dół 100%); / * Chrome10 +, Safari5.1 + * / background: -o-linear-gradient (góra, $ top 0%, $ dół 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (góra, $ top 0%, $ dół 100%); / * IE10 + * / background: gradient liniowy (do dołu, $ top 0%, $ dół 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin ma dwie wartości: kolor górny i kolor dolny. Możesz pisać różne miksy dla różnych typów gradientów, które zawierają 3 lub 4 różne kolory. Pozwala to na importowanie i klonowanie kodu mixin podczas zmiany parametrów opcji niestandardowych.

Przykład z Code Responsible wygląda tak:

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

Powiązany z mikserem jest symbol zastępczy Sassa, który jest przede wszystkim przydatny w dyrektywie rozszerzenia. Jest to wprawdzie bardziej złożone niż mieszanie, ale może to być sposób na łącz selektory razem bez przepisywania nadmiaru kodu.

Chociaż Sass ma tylko jedną metodę @import, włączyłem miksy i symbole zastępcze, aby zademonstrować elastyczność kodu, który można zapisać w jednym pliku, ale w dowolnym miejscu.

Podczas budowania struktury importu pamiętaj o przestrzeganiu koncepcji kodowania DRY (Nie powtarzaj siebie).

Konwencje nazewnictwa

Ogólne zasady dotyczące konwencji nazewnictwa mają zastosowanie do zmiennych, funkcji i miksów. Przy nazywaniu czegokolwiek w Sassie zaleca się używaj wszystkich małych liter z myślnikami do separacji.

Składnia kodu Sass jest faktycznie oparta na zestawie reguł CSS. Oto kilka zalecanych najlepszych praktyk, o których należy pamiętać:

• dwa (2) wcięcia spacji, bez zakładek
• idealnie, linie o szerokości 80 znaków lub mniej
• znaczące użycie białych znaków
• użyj komentarzy do wyjaśnienia operacji CSS

Nie są to wymagane pozycje dla prawidłowego kodu Sass. Ale te sugestie pochodzą od profesjonalnych programistów, którzy stwierdzili, że te zestawy reguł zapewniają najbardziej jednolite doświadczenie kodowania.

Ale jeśli chodzi o konwencje nazewnictwa, możesz skończyć na dwóch różnych strukturach: jednej dla nazw Sass i drugiej dla nazw klas CSS. Niektórzy programiści wolą BEM od sugestii Sass. Ani jedno, ani drugie nie jest poprawne; różni się tylko różnymi procedurami operacyjnymi.

Problem polega na tym, że BEM nie przenosi się dobrze na zmienne Sass lub miksy, ponieważ nie mają struktury blok / element / modyfikator (BEM). Osobiście wolę używać konwencji nazewnictwa Sass, ale możesz spróbować wszystkiego od camelCase do własnej wewnętrznej składni.

Podczas organizowania zmiennych i miksów zaleca się podzielić je według kategorii, a następnie wymienić je w kolejności alfabetycznej. To sprawia, że ​​edycja jest o wiele łatwiejsza, ponieważ wiesz dokładnie, gdzie coś znaleźć.

Na przykład, aby zmienić kolor łącza, otwórz plik zmiennych (być może _variables.scss) i znajdź sekcję dla zmiennych kolorów. Następnie znajdź link według nazwy (link nagłówka, link tekstowy itp.) I zaktualizuj kolor. Prosty!

Aby dowiedzieć się, jak możesz skonstruować spis treści dla plików Sass, sprawdź plik ustawień Fundacji.

 // Foundation for Sites Settings // ----------------------------- // // Spis treści: // // 1 . Global // 2. Breakpoints // 3. The Grid // 4. Base Typography // 5. Typography Helpers ... // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1.5; // etc

Inna praktyka nazewnictwa dotyczy czułe punkty przerwania. Podczas nadawania nazw punktom przerwania Sass staraj się unikać nazw specyficznych dla urządzenia. Lepiej jest pisać nazwy takie jak małe, med, lg i xlg, ponieważ są względem siebie.

Jest to lepsze dla wewnętrznych relacji między punktami przerwania, ale także dla zespołów, w których programiści mogą nie wiedzieć, które urządzenia są ze sobą powiązane.

Jeśli chodzi o faktyczne zapisywanie nazw, zaleca się być tak konkretnym, jak to możliwe, bez dodatkowych długich zmiennych. Powinieneś przyjąć konwencje nazewnictwa obejmujące całą witrynę, które są łatwe do zapamiętania podczas kodowania.

Podaj konkretne konwencje nazewnictwa dla wszystkiego, jak kolory, marginesy, stosy czcionek i wysokości linii. Nazwy można nie tylko szybko przypomnieć, ale i to ułatwia pracę podczas pisania nowych nazw zmiennych, które muszą pasować do istniejącej składni.

Ale jest cienka linia między specyficznością a splotem. Praktyka pomoże ci znaleźć tę linię, a pisanie bardziej pamiętnych nazw ułatwia kopiowanie kodu do innych projektów.

Zagnieżdżanie i zapętlanie

Te dwie techniki Sass są bardzo różne w działaniu, ale oba mają zdolność do nadużywania, jeśli nie zostanie wykorzystana w znaczący sposób.

Zagnieżdżanie jest procesem dodanie selektorów zagnieżdżonych razem poprzez wcięcia, aby uzyskać większą specyficzność przy mniejszej ilości kodu. Sass ma przewodnik zagnieżdżania, który ilustruje przykłady zagnieżdżania kodu w akcji. Ale łatwo jest dać się ponieść zagnieżdżeniu. Jeśli jesteś nadgorliwy, możesz skończyć z kodem, który wygląda tak:

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

Zbyt specyficzny i prawie niemożliwy do nadpisania, ten typ kodu pokonuje cel kaskadowych arkuszy stylów.

Przeglądając przewodnik po SitePoint znajdziesz trzy złote zasady zagnieżdżania:

• Nigdy nie idź głębiej niż 3 poziomy.
• Upewnij się, że dane wyjściowe CSS są czyste i nadają się do ponownego użycia.
• Korzystaj z zagnieżdżania, gdy ma to sens, a nie jako opcja domyślna.

Deweloper Josh Broton sugeruje zagnieżdżanie, gdy jest to konieczne, wciskając resztę jako ogólną regułę składni.

Wcięcie selektorów nie spowoduje żadnych kaskadowych efektów CSS. Ale będziesz miał łatwiejszy czas, przeglądając plik Sass, wskazując, które klasy są ze sobą powiązane.

Pętle mogą również być nadużywane, jeśli nie są właściwie stosowane. Trzy pętle Sass są @dla, @podczas, i @każdy. Nie będę szczegółowo omawiać, jak one działają, ale jeśli jesteś zainteresowany, sprawdź ten post.

Zamiast tego chciałbym omówić cel użycia pętli i jak działają w Sass. Powinny one służyć do oszczędzania czasu na pisanie kodu, który można zautomatyzować. Na przykład, oto fragment kodu z posta Clubmate pokazujący kod Sass, po którym następuje wyjście:

/ * Kod Sass * / @dla $ i od 1 do 8 $ szerokość: procent (1 / $ i) .col - # $ i szerokość: $ szerokość;  / * wyjście * / .col-1 szerokość: 100%; .col-2 szerokość: 50%; .col-3 szerokość: 33,33%; .col-4 szerokość: 25%;  .col-5 szerokość: 20%; .col-6 szerokość: 16,666%; .col-7 szerokość: 14,285%; .col-8 szerokość: 12,5%;

Te klasy kolumn mogą być używane w połączeniu z systemem siatki. Możesz nawet dodać więcej kolumn lub usunąć niektóre, edytując kod pętli.

Pętle powinien nie być używane do duplikowania selektorów lub właściwości selektora; po to są miksy.

Również podczas zapętlania jest coś zwanego mapami Sass, które przechowują klucz: wartości par danych. Zaawansowani użytkownicy powinni korzystać z tych możliwości, gdy tylko jest to możliwe.

Ale zwykłe pętle Sass są proste i skuteczne w dostarczaniu kodu bez powtórzeń. Najlepszym powodem używania pętli jest Właściwości CSS, które zmieniają dane wyjściowe.

Oto dobry sposób na sprawdzenie, czy pętla jest pomocna: zadaj sobie pytanie jeśli istnieje inny sposób na wydrukowanie potrzebnego CSS przy użyciu mniejszej liczby linii kodu. Jeśli nie, to składnia pętli jest prawdopodobnie świetnym pomysłem.

Jeśli jesteś kiedykolwiek zdezorientowany lub chcesz uzyskać informacje o zagnieżdżaniu lub pętlach Sass, powinieneś zamieścić pytanie w / r / sass / lub / r / css /, aktywnych społecznościach Reddit z bardzo doświadczonymi programistami Sass.

Modularyzacja

Praktyka pisania modularnego Sassa jest absolutną koniecznością dla większości projektów (kłóciłbym się, każdy projekt). Modularyzacja to proces podział projektu na mniejsze moduły. Można to osiągnąć za pomocą Sass częściowe.

Ideą modularnego Sassa jest pisanie pojedynczych plików SCSS w określonym celu ukierunkowanym na treści globalne (typografia, siatki) lub elementy strony (karty, formularze).

Definicja modułu Sass jest dość jasna i zawiera bardzo konkretną sugestię: import modułu nie powinien nigdy generować kodu.

Idea obowiązkowej produkcji dla wszystkich modułów byłaby koszmarem optymalizacji. Zamiast tego powinieneś tworzyć moduły indywidualnie i dzwoń tylko do tych, których potrzebujesz. Moduły mogą być definiowane przez miksy lub funkcje, ale możliwe jest również tworzenie modułów zawierających selektory.

Jednak artykuł Sass Way sugeruje pisanie wszystkich selektorów jako miksów i wywoływanie ich tylko w razie potrzeby. To, czy przyjmiesz to, czy nie, jest ostatecznie twoim wyborem. Myślę, że zależy to od wielkości projektu i komfortu obsługi miksów.

Cytując Johna Longa z jego postu na The Sass Way:

“Dla mnie moduły stały się podstawowymi jednostkami lub elementami składowymi moich projektów Sass.”

Jeśli naprawdę szukasz rutyny Sass, polecam przejście w pełni modułowe. Spróbuj zbudować prawie wszystko jako modułową część, która zostanie dołączona do podstawowego pliku CSS. Początkowo ten przepływ pracy może wydawać się zniechęcający, ale ma sens na większą skalę - zwłaszcza w przypadku dużych projektów.

Ponadto znacznie łatwiej jest kopiować moduły z jednego projektu do drugiego, gdy znajdują się w osobnych plikach. Elastyczność i kod wielokrotnego użytku są podstawą rozwoju modułowego.

Aby dowiedzieć się więcej o modułach Sass i technikach modularyzacji, sprawdź te posty:

• Moduły CSS: Witamy w przyszłości
• Plusy i minusy modularnego Sassa
• Modułowa organizacja CSS za pomocą SMACSS i SASS

Znajdź swój idealny przepływ pracy

Każdy zespół i indywidualny programista mają swoje własne najlepsze praktyki. Powinieneś zaadoptować praktyki, które najlepiej sprawdzają się dla ciebie osobiście, lub zdecydować się na przyjęcie tych, które najlepiej sprawdzają się zawodowo dla twojego zespołu.

Rozważ także użycie Gulp lub Grunt do automatyzacji projektu i zminimalizowania kodu. Pozwoli to zaoszczędzić wiele ręcznych narzędzi do pracy i automatyzacji, które są teraz niewątpliwie częścią najlepszych praktyk w zakresie nowoczesnego rozwoju frontendu.

Przejrzyj biblioteki open source, takie jak SCSS Foundation na GitHub, aby dowiedzieć się więcej o najlepszych praktykach stosowanych przez inne biblioteki.

Najlepsze praktyki polegają na tym, że przez większość czasu poprawiają one twoją pracę, ale istnieje wiele alternatyw. Po prostu spróbuj rzeczy i zobacz, jak się czują. Zawsze będziesz się uczyć, więc twoje najlepsze praktyki mogą się szybko zmienić w ciągu 5 lat.

Ostatnia sugestia, jaką mam dla całego procesu Sass, to: podejmować decyzje z myślą o jasności. Napisz kod, który ułatwi Ci pracę. Nie komplikuj projektu, jeśli jest to prostszy sposób.

Sass ma na celu zwiększenie doświadczenia w rozwoju CSS, więc pracuj z jasnością i najlepszymi praktykami aby uzyskać jak najlepsze wrażenia.

Zakończyć

Przeciążenie w przepływie pracy Sass można poprawić, dostosowując style kodu i postępując zgodnie z najlepszymi praktykami. Przedstawiłem kilka sugestii zawartych w tym poście, które otrzymałem od blogów Sass i profesjonalnych programistów.

Najlepszym sposobem, aby dowiedzieć się więcej, jest zastosowanie tych praktyk w swoim obiegu pracy i zobacz co działa. Z czasem przekonasz się, że niektóre działania są bardziej korzystne niż inne, w takim przypadku powinieneś zatrzymaj wszystko, co działa, i upuść to, co nie.

Sprawdź te linki, aby znaleźć więcej wskazówek i najlepszych praktyk dotyczących rozwoju Sass:

• Wytyczne Sass
• Wizja naszej Sass
• 8 porad, które pomogą Ci uzyskać najlepsze z Sass
• Rozszerzanie w Sassie bez tworzenia bałaganu
• Sass Best Practices - Zagnieżdżanie na więcej niż 3 poziomach