Как лучше подключать scss bem блоки?

Question

[wakenbyWork]

Есть такая структура:

src
├── modules
│   ├── header
│   │   ├── header.json
│   │   ├── header.pug
│   │   ├── header.js
│   │   └── header.scss
│   └── footer
│       ├── footer.json
│       ├── footer.pug
│       ├── footer.js
│       └── footer.scss
└── styles
    └── styles.scss

И в modules лежат bem компоненты, и их может быть больше 150+

Я решил их подключать через glob:

@use 'src/modules/**/*.scss' as null;

И это все удобно, но порядок подключения компонентов иногда подводит. Компонент может быть элементом другого компонента, и случится так, что стили компонента будут иметь большую специфичность чем стили из микса элемента.

На примере:

<div class="card">
  <div class="button card__button"></div>
</div>

button.scss

.button {
  width: max-content;
}

card.scss

.card {
  &__button {
    width: 100%;
  }
}

Порядок подключения стилей:

@use 'src/modules/**/*.scss' as null;
⇅
@use 'src/modules/card.scss';
@use 'src/modules/button.scss';

В следствии чего card__button не сработает из за каскада подключения, чем стили .button.

Какие есть решения данной проблемы? Как вы подключаете bem блоки?

Вручную думаю это очень сложно следить за порядком подключения 200 компонентов, у меня есть идеи как повышать специфичность в данном кейсе, но интересно как вы поступаете в данной ситуации))

Comments

[Сергей delphinpro]

У .card__button и .button всегда одинаковая специфичность (010).
Применение стиля в этом случае определяется правилами каскадирования.

[wakenbyWork]

Сергей delphinpro, Да, точно, специфичность у них одна. Спасибо что поправили, не знал просто как правильно назвать это)

Answer 1

[Сергей delphinpro]

Не сваливайте все блоки в одну папку, а делите по уровням абстракции.
Кнопка – примитив
Карточка – компонент более высокого порядка, может содержать в себе в том числе кнопки.

@use primitives/**
@use components/**

Answer 2

[Александр Талалаев]

У вас немного напутанно в концепции БЭМ
Вы либо убираете с той кнопки стиль .button
Либо у вас для кнопки в карточке у кнопки в классах должно быть нечтно такое:
.button .button_card, те у вас модификация элемента button, если вы уж хотите развивать от центрального button.
Тогда в своём src/modules/card.scss (если следовать вашей структуре)

.card {
/* */
}
.button {
    &_card {
        width: 100%;
    }
}

Ну либо он вовсе не связан с тем бутон и тогда да, это вложенный элемент. Без родительского стиля .button и у него все стили свои в классе .card__button.

Comments

[Сергей delphinpro]

Кстати, да.

Данный стиль больше подойдет как модификатор кнопки. И размещать его тогда следует в файле описания кнопки

.button {
  width: max-content;

  &_block { // &_wide, &_fullwidth
    width: 100%;
  }
}

[Александр Талалаев]

Сергей delphinpro, где размещать уже варианты, зависит от практик в проекте.
Лично я тоже склоняюсь к вашему(хотя могут быть варианты), но написал иначе, чтобы быть ближе к тому, что у топикастера (как мне показалось).

[Сергей delphinpro]

Александр Талалаев, Стиль слишком общий, чтобы быть локализованным только для карточки. И в других местах может пригодиться.

[Александр Талалаев]

Сергей delphinpro, а, я не понял, что вы имели в виду конкретное содержание. Тогда да, я чёт подумал про абстрактное содержание, не просто width, а может там разные. Тогда конечно же это обычные стандартные модификаторы.

[wakenbyWork]

Александр Талалаев, Сергей delphinpro, Да вы правы, это лучше выносить в модификатор. Но я это привел чисто как пример проблемы))

Есть случае когда миксование лучше чем модификатор. Если например стили микса встречаются только один раз. И для одного момента не зачем плодить лишний модификатор.

[Александр Талалаев]

wakenbyWork, а в чем экономия? К тому же логика БЭМ немного нарушается тогда. Ну и вот, выскакивают такие проблемы.
Вы конечно можете просто написать хитрую логику сборки, перепридумать структуру папок чтобы угадывать специфичность и тп. Но ИМХО это переусложненным проект выйдет.
Я бы совместил советы из первого комента с нормальным БЭМ где он нужен.
Позволит всё упростить и уменьшить повторяемость кода.

[wakenbyWork]

К тому же логика БЭМ немного нарушается тогда

Почему? Это же типичный миксин => блока и элемент одновременно. это все по документации bem.

Я бы совместил советы из первого комента с нормальным БЭМ где он нужен.

Можете подробнее описать как вы считаете лучше делать?)

Правильно ли я понимаю что все стили из микса которые конфликтуют со стилями самого блока, должны быть вынесены в миксин блока?

Тогда не понятно зачем вообще миксование нужно...

[Александр Талалаев]

wakenbyWork, вопрос холиварный.
Миксины как вы видите несут в себе подводные камни.
Общее правила такое: использовать модификаторы всегда, когда возможно и логично. Если видно, что в других элементах дублирования кода, это повод задуматься о миксах.
При этом миксы крайне желательно чтобы обозначал всякие нестандартные вещи, которые в базовом элементе/модификаторах не использует и не пересекается.
Те в вашем случае это прям стандартная модификация(width), почему микс?
Нужно так разделить модификаторы и миксы, чтобы избежать дублирования кода.
Вот и смотрите.
Что может быть в button - ага, там цвета, форма, размеры, цвета.
А вот в миксе button__card - ага, тут могут быть внешние отступы, какие либо свойства которые отвечают за взаимодействия с окружением внутри родителя (условно позиционирование, марджины).
Вот тогда куча проблем исчезнет.
В целом это все делается ещё с дизайнером на уровне проектирования, тут нередко сами дизайнеры могут подложить бомбу, нужно с ними заранее договариваться о принципах и правилах. Разбираются стандартные элементы и вкладывается логика сборки всего в удобную структуру. Отдельно разбивается сам вид базовых элементов (шрифты, паддинги, оформление). Отдельно как они могут быть внутри других элементов (вот тут уже могут появляться миксины).
Вот так и будет складываться. поэтому начинаете в любом случае с модификаторов, если видно, что модификатор выходит за рамки логики элемента (как независимого), тут можно подумать о миксинах.
Это всё примерно описал, лучше согласовывать с командой и дизайнером.