@gkopylov8 июл 2014 в 11:36

Вёрстка по БЭМу в Ruby on Rails

7 мин

12K

Ruby * Ruby on Rails * HTML *

Туториал

Из песочницы

Комментарии 9

@funca 8 июл 2014 в 12:15

Уже многие в БЭМ сообществе отходят от написания отдельного файла под модификатор и пишут модификатор прямо в файле с блоком,

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

@gkopylov 8 июл 2014 в 12:24

Ну да, в бемтулсах это всё имеет значение. Тем не менее, команда bem create создаёт структуру файлов, полностью идентичную той, что создают бемтулсы. Так что, если не хотите использовать эти амперсанды, можно делать всё по правилам БЭМа.

Насчёт переопределения и порядка — для этого я как раз добавил возможность вставки css ассетса прямо в манифест через опцию -i, чтобы верстальщик смог контролировать переопределение и порядок таким образом.

@gkopylov 8 июл 2014 в 12:56

И ещё — конечно можно использовать разные манифесты и не складывать все стили в один файл. Например, для разных лэйаутов можно использовать разные манифесты. А если вы хотите использовать свой манифест для каждого контроллера(что правда убивает преимущества turbolinks), то нужно будет прописать пару строк и не забыдь добавить в прекомпиляцию соответствующие манифесты. В последней версии рельс это добавляется в файле config/initializers/assets.rb.

@tadatuta 10 июл 2014 в 21:31

а можно какой-нибудь пример, который бы проиллюстрировал ситуацию, когда результат сборки «все в одном файле» окажется непредсказуемым?

@funca 11 июл 2014 в 06:01

например, когда у нас есть библиотека (common), мы пытаемся переопределять что-то на своем уровне (desktop):

common/
  block/
   block.css
   block_mod.css

desktop/
  block/
    block.css

предположим, что я положил все свои переопределения в один desktop/block/block.css:

.block {}
.block_mod {}

в сборке у меня часто получалась вот такая прелесть:

@import url(common/block/block.css);
@import url(desktop/block/block.css);
@import url(common/block/block_mod.css);

т.е. common/block/block_mod.css перекрывает все старания desktop/block/block.css. если же модификаторы класть в отдельный файл, тогда эффект в сборке получается правильным:

@import url(common/block/block.css);
@import url(desktop/block/block.css);
@import url(common/block/block_mod.css);
@import url(desktop/block/block_mod.css);

в прочем, не до конца уверен, фича это сборщика, или какая-то локальная проблема в проектных конфигах. но есть ощущение, что все же фича. :)

@tadatuta 11 июл 2014 в 12:38

описанная ситуация — фича :)
и, как мне кажется, достаточно логичная. результат будет получаться ожидаемым, если класть сущности на файловую систему консистентно на всех уровнях: либо везде разделяем, либо везде в один файл.

в процессе сборки происходит достаточно простая штука.

есть 2 сущности, задекларированные в БЭМ-дереве: блок и модификатор.

{
    block: 'block',
    mods: { mod: true }
}

на файловой системе на одном из уровней сущности описаны в отдельных файлах, на другом — в одном:


common/
    block/
        block.css
        _mod/
            block_mod.css
desktop/
    block/
        block.css

сборщик на основе дерева строит граф зависимостей, представляющий из себя массив. зависимости попадают туда строго в том порядке, в котором они встречаются в БЭМ-дереве:

exports.deps = [
    {
        "block": "block"
    },
    {
        "block": "block",
        "mod": "mod"
    }
];

далее при сборке конкретной технологии (в нашем примере — CSS), сборщик обходит все задекларированные уровни и пушит в массив пути к каждому найденному файлу.
соответственно, для первого элемента массива найдутся ['common/block/block.css', 'desktop/block/block.css'], затем перейдет к модификатору и допушит туда 'common/block/block_mod.css'.

затем для технологии CSS этот массив просто мапится в импорты.

@funca 11 июл 2014 в 14:40

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

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

@faost 9 июл 2014 в 14:27

А ещё там есть отличная фича, которая как раз подходит для БЭМ — это использование амперсанда.

В LESS также:

.nav {
  background: white;
  &__link {
    font-size: 1.2em;
    &_active {
      color: blue;
    }
  }
}

Превратится в

.nav {
  background: white;
}
.nav__link {
  font-size: 1.2em;
}
.nav__link_active {
  color: blue;
}

@gkopylov 9 июл 2014 в 14:48

Да, действительно, есть такое. Спасибо, добавил ссылку на документацию и ваш комментарий в статью.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий