Как организовать файлы в библиотеке компонентов?

Question

[Кирилл Гладиков]

Я использую методологию БЭМ, но это общая проблема.

Проблема заключается в связанных модификаторах и блоках.
Объясню что имею ввиду.
У нас есть блок "Кнопка", у нее есть дочерний элемент "Кнопка__иконка" и модификатор "Кнопка--Иконка-Слева"(уменьшает отступ слева, чтоб иконка смотрелась лучше).

Если в проекте не нужна иконка в кнопке, нужно удалить модификатор "Кнопка--Иконка-Слева» и элемент "Кнопка__иконка", а также все модификаторы "Кнопка__иконка", если они есть.

Усложним пример. У этой кнопки есть три модификатора размера (sm,m,l). У каждого размера будет разный отступ слева при модификаторе "Кнопка--Иконка-Слева".

Добавим изменение размера "Кнопка__иконка" для разных размеров кнопки (если это иконочный шрифт можно использовать font-size всей кнопки, но мы как современные используем svg иконки и размер нужно задавать вручную).
Получается такая структура.

Это я называю связанные модификаторы.
При такой структуре, мы явно видим что модификатор размера(S,M,L) влияет на модификатор "Кнопка--Иконка-Слева"(Btn--Icon-left) и на элемент "Кнопка__иконка"( Btn__Icon). А значит можно легко найти нужный стиль и изменить его. Плюс, если нам не нужен какой-то из размеров кнопки, удалив одну папку, мы удаляем все его связанные стили. Но есть и обратная сторона, если мы хотим удалить модификатор "Кнопка--Иконка-Слева" и оставить все размеры (S, M, L), то придется заходить в каждую папку размера и удалять этот модификатор.

Теперь о связанных блоках.
В библиотеке есть три блока: "Btn", "Dropdown", "Btn-group".
В "Btn-group" у "Btn" и "Dropdown" убирается скругление углов у всех элементов, кроме первого и последнего по бокам.

.btn-group  > .btn, 
.btn-group > .dropdawn{
border-radius: 0;
}

.btn-group > .btn:first-child,
.btn-group > .dropdawn:first-child,{
border-top-left-radius: 4px;
border-bottom-left-radius: 4px;
}
.btn-group > .btn:last-child,
.btn-group > .dropdawn:last-child,{
border-top-right-radius: 4px;
border-bottom-right-radius: 4px;
}

Проблема такая же, если в проекты не нужен "Dropdown", то и стили для его скругления в блоке "Btn-group" нам не нужны.

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

В идеале нужна структура, чтоб видеть все связи (пример выше), для быстрого доступа к нужному свойству, но также инструмент, который умеет удалять не нужные стили по связям. Удалив элемент "Кнопка__иконка" в сборку не должны попасть модификаторы "Кнопка--Иконка-Слева" разных размеров.

Может кто то встречался с решением или рекомендациями по данному вопросу.

Спасибо за внимание.

Answer 1

[Алексей Ярошевич]

У нас есть блок "Кнопка", у нее есть дочерний элемент "Кнопка__иконка" и модификатор "Кнопка--Иконка-Слева"(уменьшает отступ слева, чтоб иконка смотрелась лучше).
У этой кнопки есть три модификатора размера (sm,m,l). У каждого размера будет разный отступ слева при модификаторе "Кнопка--Иконка-Слева".

Легко решается через CSS Custom Properties и типографские константы
--sm, --m, --l при этом выставляют эти константы, а другие модификаторы и элементы их используют в нужных им местах.

Добавим изменение размера "Кнопка__иконка" для разных размеров кнопки (если это иконочный шрифт можно использовать font-size всей кнопки, но мы как современные используем svg иконки и размер нужно задавать вручную).

Лучше делать враппер над иконкой, чтобы не завязываться на svg или нет.
Если библиотека компонент общая — ситуации могут быть разные.
Такая структура более менее:

<Button>
  <Button__icon><Icon ... /></Button__icon>
  <Button__body>Текст на кнопке</Button__body>
</Button>

Если иконка есть — выводим `Button__icon`, если нет — не выводим. Стили вешаем на `Button__icon`.

Для кастомизации — оставляем `Button__body`, потом пригодится в кастомных `Select`.

В идеале нужна структура, чтоб видеть все связи (пример выше), для быстрого доступа к нужному свойству, но также инструмент, который умеет удалять не нужные стили по связям. Удалив элемент "Кнопка__иконка" в сборку не должны попасть модификаторы "Кнопка--Иконка-Слева" разных размеров.

Может кто то встречался с решением или рекомендациями по данному вопросу.

Звучит как сборка стилей по зависимостям из bemjson/jsx. Технически, есть возможность даже из html получить bemjson и инициировать для него сборку css/js.
Процесс будет выглядеть примерно так:

const fs = require('fs');
const miss = require('mississippi');
const html2bemjson = require('html2bemjson');
const bemjsonToDecl = require('bemjson-to-decl');
const src = require('gulp-bem-src');
const gconcat = require('gulp-concat');
const vfs = require('vinyl-fs');

src(
    ['path/to/blocks'],
    bemjsonToDecl.convert(
        html2bemjson(
            String(fs.readFileSync('path/to/your.html')))),
    'css',
    { // дополнительные настройки
        skipResolvingDependencies: false, // отключаем зависимости
        {
            'path/to/blocks': { scheme: 'nested' } // у 'path/to/blocks' схема nested 
        }
    }
).pipe(gconcat('path/to/your.css')).pipe(vfs.dest('.'))

Ну и всё

Comments

[Кирилл Гладиков]

Спасибо за ответ.
Насчет пункта 1 и 2 вашего ответа, вопрос был не совсем про то как использовать сss переменные и наименовать элементы в компонентах. А про хранение стилей в библиотеке так, чтоб можно было легко их найти и модифицировать под конкретный сайт.

Пункт 3 намного интереснее.
Вот еще пример. Опять с кнопками. "Кнопка" использует компонент "Иконка". То есть это две разные директории в библиотеке. У кнопки ,все также, есть модификатора "Кнопка--Иконка-Слева". И, например, удалив из сборки компонент "Иконка", должен удалиться модификатор "Кнопка--Иконка-Слева", так как иконок в сборке больше нет, модификатора тоже не должно быть.
Используя bemjson, можно такое сделать?
Также я понимаю что существует плагины для gulp, которые удаляют неиспользуемый css из сборки (gulp-uncss), но в таких плагинах нет контроля.

[Алексей Ярошевич]

Хранить модификации под конкретный сайт лучше рядом с кодом сайта. В БЭМ за это отвечают уровни переопределения. Лучше иметь отдельный уровень с доопределениями для каждой отдельной библиотеки.

Про зависимость модификатора Кнопки с иконкой слева (Кнопка--Иконка-слева) от Иконки — с этим нет проблем, если использовать сборку, и по специальным файлам или инструкциям в js/css догружать нужный код.
Да, используя bemjson можно такое сделать. В bemjson будет выглядеть так:

({
  block: 'button',
  mods: {icon: 'left'},
  icon: {block: 'icon', mods: {fa: 'x-sign'}},
  text: 'Кнопка с крестом'
})

И в данном случае даже зависимости не нужны, потому что в bemjson явно написано `{block: 'icon'}`.

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

Еще в bem сборках (enb, gulp-bem-*) есть т.н. технология deps.js, в которой описываются зависимости между компонентами, и даже их отдельными сущностями.
Например, можно для разных типов алертов подключать нужную иконку:

// bemjson:
[{ block: 'alert-message', mods: { type: 'warning' }, text: '' }]

// alert-message--type_warning.deps.js:
[{ block: 'icon', mods: { fa: 'icon-exclamation-sign' } }]

(скобки квадратные — сахар, чтобы не писать `module.exports = ...;`).
CSS, JS и код шаблонов приедет автоматически, согласно настроенной сборке.

Минус такого подхода — нужна сборка). Но сейчас такое время, что везде нужна сборка.
Под webpack хороших решений пока нет. Есть `bem-pack`.

Можно использовать `enb` и `gulp-bem-src`.
`enb` такой же сложный, как webpack, но работает.
`gulp-bem-src` тоже работает, и это gulp-like винильные стримы, но нет кеширования и могут быть баги.

[Кирилл Гладиков]

Алексей Ярошевич, Большое спасибо. Буду копать в этом направление.