@daniel_z:
Na czym wg Ciebie polega większa ilość zachodu w importowaniu stylów do komponentu vs importowaniu do zbiorczego arkusza? Ja nie widzę tutaj różnicy, natomiast podejście komponentowe ma taką przewagę nad globalnym arkuszem, że jest bardzo wygodnie zrobić w ten sposób ładną, komponentową strukturę plików:
/components
/Article
Article.jsx
Article.scss
W powyższym Article
jest komponentem, który stanowi blok w terminologii BEM (jeśli mam subkomponenty (elementy BEM) to nie tworze dla nich osobnych arkuszy - w BEM najmniejszą samodzielną jednostką blok i takie samo założenie stosuję jeśli chodzi o arkusze stylów).
Taka struktura jest o wiele lepsza niż wywalanie stylów do osobnego folderu i kursowanie między jedną lokacją a drugą - przy powyższej stukturze wczytywanie arkusza do komponentu jest najbardziej naturalnym rozwiązaniem. Liczba komponentów nie ma tu nic do rzeczy - aplikacje lubią się rozrastać (a nawet z małej aplikacji nie warto robić śmietnika).
@Czarny Lew
BEM ma dla mnie kilka istotnych zalet:
- jest uniwersalny - niezależny od używanego frameworka (lub jego braku),
- stanowi swoisty DSL dla frontu aplikacji, uniwersalny język niezależny od szczegółów implementacyjnych (warstwa abstrakcji),
- wymusza ładną, modularną architekturę, reużywalność na poziomie bloków
Składnia BEM (można spotkać kilka wersji) jest szczegółem implementacyjnym, przy czym jest czytelna i intuicyjna - o ile rozumie się ogólną ideę. No właśnie - i tu myślę jest największy problem - wielu programistów "używa BEMa" bez zrozumienia o co w nim chodzi - "no są bloki elementy i modyfikatory i z tego trzeba jakoś poskładać te klasy", czego efektem są potworki typu:
.some-block {
...
.some-element {}
.some-block---modifier {}
}
.some-block.some-block__some-element {}
.some-block__some-element__other-element {
.some-block__some-element__other-element__and-one-more {}
}
gdzie ma to z BEMem niewiele wspólnego.