File Structure

[iatsdotfatr]

У каждого компонента (бэм-блока) должна быть своя директория, в которой находятся:

1. шаблон (pug)
2. стили (scss), если есть
3. поведение (js), если есть

[hoka-hoka]

Но ведь БЭМ методология не определяет конкретного наличия той или иной технологии для реализации блока. Это я к тому, что сам шаблон бэм-блока не обязательно должен присутствовать в его директории (если только для удобства?). А что, если блок состоит только из scss (например, clearfix или visuallyhidden). Я исправил.

[iatsdotfatr]

Если шаблон есть, то должен присутствовать. Если блок состоит только из scss тоже нормально, если не использовать шаблонизаторов, то есть делать разметку на чистом html, шаблонов вообще не будет :). БЭМ-миксы в целом, и классы с общими стилями в частности, не надо использовать (то есть не надо добавлять к одному html-элементу больше одного класса--бэм-блока), что-то подобное clearfix можно сделать scss-миксином, вместо общего visuallyhidden использовать модификаторы (их тоже можно сделать миксином).

1. Директорию с блоками надо вынести на один уровень с assets

2. Подобное разделение имеет смысл использовать только при работе с css, в случае с препроцессорами, файл со стилями должен быть один, в котором на верхнем уровне находится только правило блока, остальные правила вкладываются с помощью "&" внутрь в порядке их расположения в разметке, то же касается медиазапросов, например:

3. Как было написано выше, не использовать миксы / общие стили, что использовать вместо них, можно почитать по ссылке.
4. Не надо использовать нижнее подчеркивание в названиях файлов со стилями блоков: имена шаблонов, стилей, скриптов в рамках блока должны совпадать, в файлах с scss-переменными, миксинами и т.п. использовать можно.

[hoka-hoka]

Хорошо, тогда, если для кастомизации компонентов использовать только миксины, разве это не приводит к очень большому дублированию стилей и раздуванию кодовой базы? Например, для компонентов input-date и input-list стили для элементов input и button одинаковы, но мы вынуждены их всё равно разделять разными классами дабы сохранить специфичность компонентов.

Но компонент может по прежнему остаться независимым, если использовать подблоки. Сами классы input и button содержат только общие стили (присущие всем таким элементами), а расширяются уже модификаторами.

Чем плох именно второй вариант?

Ещё возникли такие вопросы:

1. Как принято именовать js-модификаторы? blockelement_js, block__element_js-name или blockelement_name_js.
2. Может ли модификатор описывать положение узла на странице (margin, padding ...)?
3. Если стили блока записываются в один scss-файл, то какая глубина вложенности селекторов допускается (до 3)?
4. Scss-переменные или катомные свойства?
5. При подключении фоновых изображений обязательно их кодировать в формат base64. Или обрабатывать изображения только небольших размеров?

Исправил.

[iatsdotfatr]

Не уверен, что понял по поводу инпутов, но если какие-то элементы повторяются в разных местах, то, скорее всего, из них надо сделать отдельные бэм-блоки, тогда и стили для них будут описаны в одном месте.

1. js-block.block. На элементы и модификаторы добавлять не надо, выбираешь нужный блок через js-класс, внутри него уже работаешь с обычными классами.
2. В смысле, содержать свойства margin, padding ...? Да, только надо помнить, что у бэм-блока не указывается внешнее позиционирование (margin, top, left ...), как и фиксированная геометрия вроде фиксированных ширины и высоты (в большинстве случаев). И названия у модификаторов должны быть семантическими.
3. Вложенность через & ненастоящая вложенность: Поэтому через & можно вкладывать на любую глубину). А так, при необходимости, одно уровня почти всегда достачно.
4. Этот вопрос тоже не понял, используемые на проекте цвета, семейства шрифтов и т.п. имеет смысл вынести в переменные.
5. На проекте нет никаких требований по кодированию изображений, можно подключать как есть.

[iatsdotfatr]

1. Зачем это в scss?

[hoka-hoka]

В modules стилизуются основные страницы, а в templates страницы ui-kit.

[iatsdotfatr]

А они точно дожны находиться в scss?

[hoka-hoka]

Наверное, зависит от того для чего делаются страницы uikit, как и кем они будут использоваться. А это был риторический вопрос. да?

[iatsdotfatr]

Ага, в scss должно находиться то, что относится только к scss.

[hoka-hoka]

Готово. Теперь компоненты находятся в папке components. В папке scss лежат только стили: normalize, fonts, mixins и variables. Для каждой точки входа (страницы) свой js-файл, где подключаются компоненты, которые используются на этой странице.