Wprowadzenie / tło: komponenty CSS
W przypadku stosunkowo dużej witryny współpracujemy z SASS i staramy się zarządzać CSS w komponentach. Podstawowa idea komponentów polega na tym, że komponent powinien wszędzie wyglądać tak samo, niezależnie od elementów kontenera w dalszej części DOM.
Dlatego chcemy uniknąć takich rzeczy (SASS):
// User picture component.
.user-picture {
img {..}
}
// Override user picture for the frontpage.
body.page-front .user-picture img {..}
Zamiast tego, jeśli chcemy, aby obraz użytkownika wyglądał inaczej na pierwszej stronie, musiałby to być inny komponent. Np. Z dziedziczeniem SASS lub z mixinem:
// User picture component.
.user-picture {
img {..}
}
// User picture on frontpage.
.user-picture-front {
@extend .user-picture;
img {..}
}
Następnie musimy dostosować HTML na stronie głównej, aby używał innej wersji obrazu użytkownika.
Na razie w porządku. Opublikowałem powyższe jako ilustrację mojego obecnego zrozumienia tego, o co chodzi w komponentach CSS.
Pytanie: Klasy modyfikatorów - dobra praktyka?
Teraz mamy problem: niektóre strony mają ciemne (czarne) tło, więc tekst, ramki i inne elementy muszą być białe.
To w jakiś sposób wykracza poza komponenty: ten sam komponent powinien domyślnie mieć ciemny tekst, ale biały tekst, jeśli znajduje się w kontenerze z ciemnym tłem.
Mamy więc niesamowity pomysł:
// Generic modifier class for all dark-background containers.
.white-on-black {
// Generic text color change.
color: white !important;
}
// Component.
.my-component {
border: 1px solid blue;
// Special for white-on-black.
.white-on-black & {
border-color: yellow;
}
}
Mamy więc zewnętrzną klasę „modyfikatora” lub „kontekstu”, white-on-blackktóra modyfikuje sposób wyświetlania elementów wewnętrznych.
Motywacja polega na tym, że sam komponent nie jest odpowiedzialny za tło elementu kontenera w dalszej części DOM.
To działa. Jedynym problemem jest to, że mamy pojemnik z białym tłem w pojemniku z ciemnym tłem. Ale to na bok działa dobrze.
Pytanie brzmi, czy jest to dobra praktyka architektoniczna, w kontekście prób utrzymania niezależności komponentów.
Alternatywą byłoby mieć inny komponent, np. my-component-on-dark-bgKtóry dziedziczy my-componenti ma inny kolor tekstu i obramowań. Ale tutaj kod (np. PHP), który produkuje komponent html, musi wiedzieć o zewnątrz, to znaczy, czy używany jest ciemny plik bg. Zakładając, że kod PHP renderujący komponent jest oddzielny od kodu PHP renderującego kontener. Co jest nadal możliwe do zarządzania, ale może być argumentem dla wzorca z klasą modyfikatora, jak opisano powyżej.
Notatki
W rzeczywistości prefiksujemy nasze klasy CSS prefiksem specyficznym dla projektu. Zostawiłem to tutaj dla uproszczenia, a ponieważ to nie jest niczyja sprawa, nad którym projektem pracuję :).