Какой вариант именования более правильный по БЭМу?

Question

[Barring]

Есть компоненты карточек, которые выглядят таким образом :



Корректен ли такой вариант наименования? Или правильнее писать не CircleCard, а CardCircle? (в проекте нет какого-то базового компонента Card)

Answer 1

[Realetive]

Корректен ли такой вариант наименования?

— https://ru.bem.info/methodology/naming-convention/

Или правильнее писать не CircleCard, а CardCircle?

— Если Circle — это модификатор Card, то правильно будет иметь разделитель, например, Card_circle. Если нет базового компонента Card, то не нужен никакой Card_circle (можно просто переименовать файл).

Comments

[Barring]

То есть в ситуации, когда у меня нет базового компонента "карточки", то всё же логично оставить всё как есть? А если бы у меня все "карточки" наследовались от какого - то базового компонента Card, то тогда наименование типа "CardCircle" имело бы смысл, верно?

[Realetive]

Нет. Базовый компонент должен быть по определению. Если он круглый, но может быть квадратным, то один из признаков может быть описан в базовом компоненте, а другой компонент «модифицировал» бы базовое поведение.
Т. е. или

Card/
  _view/
    Card_view_circle.vue
    Card_view_square.vue
  Card.vue

или

CardCircle/
  _square/
    CardCircle_square.vue
  CardCircle.vue

[Barring]

Realetive, в моей ситуации все карточки это полностью отличающиеся друг от друга компоненты. И к примеру, взять CircleCard. Если мне нужно сделать наследуясь от него, сделать тот же CircleCard, но с обводкой, то я бы его назвал CircleCardBordered. Или всё равно изначально необходимо начинать наименование по принципу CardCircle, а потом добавлять CardCircleBordered?

[Realetive]

Barring, нет. Потратьте несколько минут на вдумчивое прочтение статьи вместо новых вопросов — это сэкономит время нам обоим. Про расположение файлов там тоже есть.

[Aetae]

Тока яб юзал не snake_case и тем более не жуткую смесь c PascalCase, а старый добрый kebab-case, с удвоением -- для элементов блока. Модификаторы как отдельные vue-компоненты, очевидно, не встречаются(иначе вы делаете что-то сильно не так).

[Realetive]

Aetae, два минуса для отделения модификатора имеют проблемы у некоторых подсветок синтаксиса — принимают их за HTML-комментарий. Один минус итак используется для обозначения сложносоставных названий переменных. Какую бы схему именования вы не использовали, будет ошибкой, если эти имена пишутся руками, а не генерируются.
Если у вас нет модификаторов, то с большей вероятностью (минимум 100%) — вы не понимаете их предназначение.

[Aetae]

Realetive, у меня есть css модификаторы. Но у меня нет vue-компонентов - модификаторов. Задачей "модификации" компонента занимаются пропсы.)

[Realetive]

Aetae, т. е. у вас разметка состоит из «лапши» if-ов, определяющих, что именно рендерить по значению из пропсов? Модификаторы как раз и позволяют решить эту проблему, описывая шаблоны более декларативно. По сути, пропс и является модификатором, потому что модификатор не обязательно должен быть в списке CSS-классов.

[Barring]

Realetive, сейчас ещё повторно просматриваю ещё документацию Vue, и там есть такой пример наименования :

Из-за него у меня вероятно и не получается перестроиться на иной принцип. Т.е. тут тоже должно идти не SearchButtonClear, a ButtonSearchClear?

[Realetive]

Barring, вот тут уже более «тонкий» нюанс — по идее имя файла (как и любой переменной) должно отражать функционал (чтобы не тратить время на чтение кода). Т. е. кажется, что, если сгруппировать компоненты, имеющие отношение к поиску, то проще будет этот файл найти или перенести в новый проект. Но тут ещё имеет значение договорённость в команде — если в проекте один или пару человек (и им легко договориться), то ButtonSearchClear — вполне приемлемый вариант. Но если с библиотекой может работать разработчик «со стороны», для него такое поведение может быть не очевидно с первого раза.