Tworzenie rozbudowanych projektów w CSS jest nie lada wyzwaniem. Trzeba wziąć pod uwagę kaskadowość i specyficzność CSS, warto pamiętać o klasach, które powinny być reużywalne i wspólne dla całego projektu, należy unikać notacji !important, zadbać o odpowiednie nazewnictwo. W wielu rzeczach pomagają metodologie, takie jak: BEM, SMACSS czy OOCSS czy też preprocessory, takie jak: LESS, SASS.

Pomimo to - same metodologie i preprocessory nie zawsze rozwikłają wszystkie problemy. Przygotowując jakikolwiek projekt programistyczny prędzej czy później napotkamy na problemy związane z architekturą naszych rozwiązań. Zmiany architektoniczne wymusi na nas charakterystyka samego projektu. Zbyt rozbudowany kod źródłowy stanie się nieczytelny., jeśli czegoś z nim nie zrobimy.

W swoim wpisie przedstawię moje ulubione podejście do budowania styli w CSS. Moje rozwiązanie oparte jest o: Sass, BEM oraz wzorzec 7-1.

Pojęcie komponentu

Komponent w rozumieniu interfejsu graficznego naszego projektu, to samodzielny, reużywalny element, który wykonuje tylko jedno zadanie. Taka definicja komponentu stawia go bardzo blisko definicji Bloku w metodologii BEM. Idea dzielenia interfejsów na zbiory komponentów powinna zaprowadzić nas do tworzenia bardziej uporządkowanego kodu CSS. Co do zasady komponentem może być wszystko, o ile spełnia powyższe wymagania. Samo tworzenie komponentów i umieszczanie ich w jednym pliku CSS nadal nie rozwiąże problemu zbyt rozbudowanego kodu, dlatego warto dodać założenie, że każdy komponent to samodzielny plik.

W tym miejscu warto wspomnieć o preprocessorach, np. Sass. Nowe komponenty możemy dodawać do nowych plików, rozpoczynając ich nazwy od  _ , a dzięki @import możemy składać je później w całość, importując te, które potrzebujemy.

Wzorzec 7-1

Na stronie sass-guidelin.es znajdziemy bardzo dużo wskazówek na temat sposobów doładowania naszego sass’a, tak aby był możliwie najskuteczniejszy. Jeden z podrozdziałów dotyczy zaproponowanego wzorca 7 w 1. Wzorzec 7 - 1 wyszedł pierwotnie z założeń metodologii SMACSS, która zawiera wskazówki jak budować skalowalny i modułowy CSS. Według wzorca 7-1 mamy do dyspozycji 1 główny plik, który zawiera tylko informacje o pozostałych plikach, które należy załadować, aby nasz projekt działał poprawnie. 7 natomiast oznacza 7 najważniejszych grup, w które dzielimy nasze pliki z kodem.

Kitty Giraudel, twórca tej koncepcji, zaproponował podział projektu na 7 grup:

• base

• components

• layout

• pages

• themes

• utils

• vendors.

Szczegóły tego, co powinno znajdować się w poszczególnych katalogach znajdziesz na pewno na stronie Hugo - sass-guidelin.es . Ja ze swojej strony dodam, że pomysł na taki podział według mnie ma sporo sensu, aczkolwiek przy większości projektów spokojnie można ograniczyć 7 katalogów do 5. Ja praktycznie zawsze pomijam themes, z racji tego, że mało, który projekt nad którym pracuję, wspiera wiele motywów oraz pages. Traktuję każdy element interfejsu jako komponent, a zatem poszczególne strony są tylko zbiorem różnych komponentów.

Co w tym wszystkim robi BEM?

BEM jako metodologia wspiera pisanie łatwego w utrzymaniu kodu, aczkolwiek pewnie każdy kto z nim pracował, potwierdzi, że najtrudniejsze w pracy z nim jest wymyślanie kolejnych nazw dla bloków. Nazwy bloków powinny być unikalne, to znaczy, że nie powinny się powtarzać w naszym projekcie. Czasami trudno to osiągnąć. Ponadto trudno czasami rozróżnić czy dana klasa CSS jest komponentem, fragmentem layoutu czy klasą pomocniczą. Dlatego w swoich projektach, klasy, które tworzę są zawsze prefixowane jedną literką, np. chciałbym stworzyć komponent formularza logowania, który umieszczę w katalogu components/:

Zwróć uwagę na konstrukcję samego pliku scss. Korzystam z zagnieżdżeń, które są dostępne w Sass, a jednocześnie mój plik wynikowy będzie płaski. Prefix dla tego komponentu do c-, z racji tego, że trafi on do katalogu components/. Dodatkowo wszystkie elementy powtarzalne są zawarte w zmiennych. Taki zapis gwarantuje mi, że łatwo odnajdę pliki swoich komponentów, że zmieniając je, nie zmienię nic innego poza tym, co chcę zmienić oraz że zmiana elementów wspólnych w plikach bazowych wpłynie również na ten plik.

Podsumowanie

Warto zawsze przemyśleć swój projekt CSS zanim wystartujemy z pisaniem. Trzeba być krok przed naszym CSSem, żeby nie wpaść w jego pułapkę. Pamiętaj, że czas, który poświęcisz przed napisaniem jakiekolwiek klasy CSS, to czas który zwróci Ci się z nawiązką w czasie dalszego rozwoju projektu czy w czasie debugowania. Decyzje podjęte na szybko z czasem bardzo trudno zmienić.