Vue + БЭМ: почему это всё ещё работает

[vanxant]

Ну те. из статьи следует, что кнопку-аватар с БЭМ вообще сделать нельзя:)

[Pnym]

Можно, просто проще было привести пример с button. Если вам необходимо реализовать специальную кнопку для аватара, то тут вообще можно несколько вариантов предложить:

• на основе button.vue сделать avatar-button.vue;

• понять, что значит avatar-button. Ну, например, это передача Icon и border-radius: 30px, тогда проще как будто отдельные классы сделать

[irtek]

:deep() в Vue это как !important в css аварийные выходы, которые лучше не использовать )

[MLG_Noscope]

А зачем мне эта портянка БЭМа в компоненте, когда я могу динамически ставить класс типа :class=styles[size-${props.size}

[Pnym]

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

Главная проблема подхода :class="styles['size-' + size]"- он рвёт статическую связь между шаблоном и <style>. Для человека это читаемо, но для всей экосистемы разработки эти классы становятся «невидимыми» до момента выполнения кода.

Что конкретно ломается:
- Линтинг и поиск неиспользуемых классовstylelint, purgecss, eslint-plugin-vue и подобные инструменты работают на статическом анализе. Когда класс собирается динамически, линтер не видит его в шаблоне.

- Явность vs Магияbutton_size_l сразу читается как «модификатор размера у блока button». styles['size-' + size] требует лезть в JS-объект, смотреть маппинг и гадать, какие ключи вообще существуют. В команде из 3+ разработчиков это превращается в квест.

Динамические маппинги имеют полное право на жизнь: когда вы работаете с CSS-переменными, утилитарными фреймворками или когда стили действительно генерируются на лету. Но для компонентной UI-системы, где важна долгосрочная поддержка, явный :class с БЭМ-модификаторами выигрывает за счёт прозрачности для разрабов и инструментов.