Привет ! Подскажите пожалуйста, в методологии есть возможность создать layout как в Jade , подключать все скрипты в теге head и для других страниц.

Как правильно составить условие в bemtree для блока, чтобы он не выводился при определенных условиях

Например у меня есть блок block-a и я хочу чтобы он вообще не появился в результирующем bemtree, если в нем this.ctx.data не определено. У меня получился следующий рабочий вариант:

block('block-a')
(
    match(this.ctx.data)
    (
        content()
        (
            function ()
            {
                var ctx = this.ctx;
                var result;

                // Some code ....

                return result;
            }
        )
    ),

    match(this.ctx.block && !this.ctx.data && !this.ctx.content) // @todo !!!
    (
        function ()
        {
            this.block = undefined;
            this.ctx = {};

            return applyNext();
        }
    )
);

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

Буду рад любой подсказке, заранее спасибо!

Есть ли смысл писать вручную bemjson для сайтов с динамическим контентом? Сайт берет данные из БД, bemjson генерируется автоматически, получается bundlename.bemjson.js используется только при сборке, и то зачастую, там прописаны 2 - 3 блока, все остальное попадает в сборку по зависимостям.

Вижу на странице:

TypeError: Cannot read property '0' of undefined
    at __$b29.iterateItems__$69 (.../users-list.bemhtml.js:501:46)
    at __$b29.iterateItems__$69 (.../users-list.bemhtml.js:509:21)
    at __$b29 (.../users-list.bemhtml.js:513:9)
    at __$g2 (.../users-list.bemhtml.js:1028:24)
    at applyc (.../users-list.bemhtml.js:33:20)
    at __$b75 (.../users-list.bemhtml.js:809:5)
    at applyc (.../users-list.bemhtml.js:105:20)
    at __$lb__$160 (.../users-list.bemhtml.js:784:22)
    at __$b74 (.../users-list.bemhtml.js:787:7)
    at applyc (.../users-list.bemhtml.js:102:24)

Реально ли собирать sourcemaps и при таких выбросах резолвить файлы/строки вменяемо?

Не могу разобратьcя:

{
    block: 'logo',
    mix: { block: 'header', elem: 'logo' },
    content: [
        {
            elem: 'name',
            content: {
                block: 'image',
                mix: {block: 'logo', elem: 'pic'},
                url: 'карзина.svg',
                alt: ' альтернативный текст '
            }
        }
}

Вопрос: Как сделать чтобы image блок находил картинку которая лежит в папке блока logo, но не хочется менять путь url

Выявил особенность работы с модификаторами одного js блока на нескольких DOM-нодах:

• установка и удаление мода из i-bem изменяет соответствующий класс на всех нодах блока
• если при инициализации у DOM-нод набор модификаторов отличается, то первый вызов метода hasMod имеет некоторые особенности:

{ block: 'a', mods: { foo: 'bar'}, js( { id:1})},
{ block: 'a', js( { id:1})}

> this.hasMod('foo')
true
> this.toggleMod( 'foo', 'bar').getMod( 'foo')
""

{ block: 'a', js( { id:1})}
{ block: 'a', mods: { foo: 'bar'}, js( { id:1})},

> this.hasMod('foo')
false
> this.toggleMod( 'foo', 'bar').getMod( 'foo')
"bar"

Возможные последствия:

• первый вызов toggleMod может не выполнить то, что возможно ожидалось
• стили модификатора могут повлиять на элемент, для которого они не предназначались

Способы решения:

• одинаковые модификаторы на всех нодах блока при инициализации
• стилизовать элементы по модификатору специфичным селектором

#asktheteam

• данные особенности стоит отразить в документации
• console.warn("unambigios mods set on block's nodes. see http://bem.info/... for more info") при инициализации в девелопер режиме P.S. если способа добавлять js код специфичный для девелопер режима сейчас нет, рассматривать это как отдельный фичреквест

Свершилось!

Есть такая страничка, заявляющая, что она раскрывает смысл терминов Блок, Элемент, Модификатор. https://ru.bem.info/method/definitions/ Но, во-первых, нет конкретного определения, и, во-вторых, ничего не говорится про технологии, реализации, и другие важные при разработке сборки части.

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

• БЭМ — акроним Блок-Элемент-Модификатор;
• Блок — ключевая самодостаточная сущность, описываемая набором реализаций (обычно, набор файлов и папок в папке блока);
• Элемент — вспомогательная сущность, составная часть блока, описываемая аналогично блоку, которая имеет ровно один родительский блок, и не может использовать вне его контекста;
• БЭМ-сущность — это определение содержания страницы или сущность в БЭМ-предметной области: блок ИЛИ элемент со всеми его состояниями (модификаторами);
• БЭМ-предметная область — предметная область, описывающая все возможные варианты БЭМ-сущностей, их свойств, и отношений между ними;
• Методология БЭМ — это набор паттернов и способ описывать действительность при помощи кода и размышлять о БЭМ-сущностях вне зависимости от того, на каком языке программирования реализуется проект;
• Модификатор — состояние БЭМ-сущности, описываемое реализациями аналогично БЭМ-сущностям, может иметь строго одно строковое или булевое значение, не может как использоваться отдельно от БЭМ-сущности, так и считаться отедльной БЭМ-сущностью, поскольку является его состоянием (часть целого не может быть целым, если целое состоит не только из этой части);
• Уровень — набор реализаций БЭМ-сущностей (обычно, набор папок с блоками и их внутренней структурой с элементами и модификаторами);
• Библиотека — набор уровней;
• Реализация (в технологии) — функциональная часть БЭМ-сущности, описанная в рамках конкретной технологии файлом или папкой с набором файлов;
• Технология (tech, technology) — набор процессов для преобразования исходных файлов в целевой продукт (материалов в изделие, результат работы процессов, см. wiki: Технология);
• БЭМ-технология — технология, применимая к БЭМ-сущностям;
• Технология сборки — процесс преобразования реализаций блоков, используемый инструментами для сборки (обычно, модуль или набор , stateful?);
• Технологии борщика — технология, реализуемая js-файлами, используемая инструментом borschik;
• Цель (сборка) — результат работы технологии сборки;
• Зависимость — способ включения в сборку сущности или её состояний других сущностей или состояний;
• Зависимость по БЭМ-технологии — зависимость, используемая в случае сборки определенной БЭМ-технология (верно?);
• Бандл (сборка) — это набор реализаций сущностей, описанный некоторой специальной реализацией (точкой входа для сборщика с набором сущностей, обычно, в виде реализации технологии bemdecl.js или bemjson.js), и некоторое кол-во собранных целей на выходе, а также способный включать в себя дополнительные уровни;
• Merged-бандл — частный случай бандла, включающий в себя сборку всех используемых наборов сущностей и их состояний со всех бандлов;
• Dist-бандл — частный случай бандла, включающий в себя сборку всех доступных БЭМ-сущностей, обычно используется для сборки библиотек;
• JS-бандл — целевой файл бандла с реализацией JS;
• CSS-бандл — целевой файл бандла с реализацией CSS (?, противоречит JS-бандлу, где в сборку включаются еще и шаблоны, и стили);
• JS-бандл (путаница, может mixed-бандл?) — цель специальной технологии, результат которой содержит в себе CSS, JS и шаблоны, поставляемая в виде одного файла технологии JS.

Off-topic. А еще вот такое хочу:

  // возвращаем первое удачно разрешенное
  target('bemdecl', oneOf(
    // либо грузим файл `{level.path}/{bundle.name}/{bundle.name}.bemdecl.js`
    fs.provide('bemdecl.js'),
    // либо пытаемся загрузить bemjson.js и собрать динамически из bemjson.js
    bemjsonToBemdecl(fs.provide('bemjson.js'))
  ));

Всем привет! Начал писать небольшой скрипт (т.к. подобного не смог найти), который на основе html файлов генерирует мне dep.js файл со всем используемыми блоками/элементами. Вот я получил такой файл:

exports.deps = [
{ block: 'b-layout', elem: 'content' },
{ block: 'b-layout',  elem: 'content',  modName: 'align',  modVal: 'center' },
{ block: 'b-logo' },
{ block: 'b-auth-form' },
{ block: 'b-form' },
{ block: 'b-form', modName: 'stretch', modVal: true },
{ block: 'b-form', elem: 'content' },
{ block: 'b-form', elem: 'title' },
{ block: 'b-form', elem: 'controls' },
{ block: 'b-form', elem: 'control' },
{ block: 'b-input' },
{ block: 'b-input', modName: 'size', modVal: 'xl' },
{ block: 'b-button' },
{ block: 'b-button', modName: 'type', modVal: 'primary' },
{ block: 'b-button', modName: 'size', modVal: 'xl' },
{ block: 'b-button', elem: 'text' },
{ block: 'b-form', elem: 'footer' },
]

Конечный результат я получил с помощью библиотеки bem-naming. Но там не совсем корректно устанавливаются ключи для модификаторов. Собственно в этой issue как раз об этом говорится. Я не совсем понял что там в комментариях решили по этому поводу, поэтому пришел сюда. Чем я могу собрать свои css/js файлы используя полученный deps.js? Или я пошел в какие-то дебри и решение на основе обычных html файлов уже есть?

И снова популярный вопрос про вспомогательные классы, на этот раз его задает ‏@life_maniac.

«Я правильно понимаю, что по БЭМу я не могу добавлять общие вспомогательные классы ко всем блокам? Например, есть класс center, который центрирует содержимое по обеим осям. Хочется иметь его в шапке и еще в паре блоков.»

Да, но нет :)

С одной стороны, БЭМ утверждает: «Не может быть классов вне блоков». С другой стороны, в БЭМ есть понятие миксов — нескольких блоков на одном DOM-узле.

Этот случай — наш.

Предлагаю рассмотреть класс center как универсальный блок, который можно подмешивать к любым другим блокам, чтобы центрировать их содержимое.

Примером такого блока в bem-core может служить clearfix, а в bem-components — z-index-group.

Важно помнить, что миксы можно использовать не только в CSS, но и в JavaScript.

Подробнее об этом можно узнать из доклада «Миксы во вселенной БЭМ».

https://gist.github.com/ec7034b7a409c826e989 Объявил зависимость shouldDeps модификатора от другого булевого модификатора.

({
  shouldDeps:[
    { mods: { visible: true}}
  ]
})

В итоге в собранный deps.js булевый модификатор попадает дважды. До исходного модификатора:

    {
        "block": "drawer",
        "mod": "visible"
    }

После исходного модификатора:

    {
        "block": "drawer",
        "mod": "visible",
        "val": true
    }

При этом появление модификатора visible до исходного является нежелательным и неожиданным. Сборщик ENB настроенный generator-bem-stub

Приветствую, подскажите пожалуйста, куда нужно класть шрифты?

Использую BEM для генерации страничек, которые ходят в java-сервер за данными. Тестирую с помощью 'bem server'.

Собственно вопрос, могу ли я что-то сказать в командной строке, чтобы весь необходимый контент сгенерировался в указанную мной директорию, которую я положу за ngnix/Apache и у меня все будет работать?

Есть в bem-tools такое волшебное заклинание?

Пытаюсь осваивать bem в качестве веселой игрушки. Сам с вебом связан очень посредственно, основная деятельность C++ для приложений и Java для серверов.

Сейчас не могу вполне понять, как я могу из JavaScript кода динамически создавать bem-блоки и добавлять их в дерево на странице.

Есть желающие помочь разобраться?

Потерял ссылку на GITHUB-страничку, где было полное и поступенное описание всего стека технологий. В т.ч. там было про то, как вводить свои технологии, расширяя имеющиеся, и т.д. Перерыл историю браузера, но ничего не могу найти. Если подскажете, буду рад, т.к. имеющаяся документация оставляет некие кусочки в голове, не давая сразу целой картины мира. Спасибо.

Приветствую, друзья! Хочу собрать i-bem.js из bem-core, чтобы использовать его на проекте без полного БЭМ-стека. И я собрал его, но что то не фурычит он. Видимо я что-то не правильно делаю. Подтолкните в нужном направлении. Вот мой порядок действий:

1. Склонировал bem-core
2. Выполнил npm i
3. В директорииcommon.bundles\index создал файл index.bemjson.js с таким содержимым:

({
    block: 'i-bem',
    elem: 'dom'
});

1. Выполнил команду `bem make
2. Получил собранный файл i-bem.js
3. Подключаю его на страницу. Вот исходный код этой страницы:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
    <script src='i-bem.js' type="text/javascript"></script>
    <script src='index.js' type="text/javascript"></script>
</head>
<body>
    <div class="b-calendar i-bem" data-bem="{'b-calendar:{}'}"></div>
</body>
</html>

1. В index.js я написал такой код:

modules.define('i-bem__dom', function(provide, DOM) {
    DOM.decl('b-calendar', {
        onSetMod: {
            'js' : {
                'inited' : function() {
                    console.log('inited');
                }
            }
        }
    });
    provide(DOM);
});

В итоге после открытия страницы в консоль ничего не выводится... Что не так в моих действиях?

Привет, подскажите пожалуйста, что нужно сделать для того что бы подключить i-bem и правильно им воспользоваться, сейчас при обращении к серверу получаю ошибку "Uncaught ReferenceError: modules is not defined"

Ссылки по теме:

• Оригинальный пост;
• Сам движок bh-php - порт bem/bh на пхп;
• Технология для enb: enb-bh-php;
• Технологию для тулзов: .bem/techs/bh.php.js (спасибо @tadatuta и @kompolom);
• project-stub с bh-php;
• Тест сборки на project-stub.

Roadmap

• Научится генерировать вменяемый bh.php код из bh.js шаблонов, если bh.php отсутствует, а bh.js в наличии, чтобы уменьшить кол-во работы при поддержке (тулзы не смогут?);
• Показать, как можно использовать в WP, Drupal, Joomla(?), etc.(?);
• Упростить API объекта BEMContext и другие мелочи (см. https://github.com/bem/bh-php/issues);
• Причесать технологии, и все остальное по возможности;
• Ну и: Добавить шаблоны в библиотеки, тэги на форум, документацию на bem.info, etc.

Шаблоны для bem-core и bem-components

• PR в bem-core bem-core-php;
• PR в bem-components bem-components-php.

Делитесь историями успеха, не стесняйтесь!

upd: поправил ссылки — перенсли проект в группу bem upd: еще поправил ссылки — веточки протухли, вместо PR получились отдельные библиотеки с шаблонами для PHP

Доброго времени суток комрады. Столкнулся с необходимостью использовать конструкции сабжа, из доки, ничего не понял. Сделал вывод что для понимания нужно знать как это работает в XSL. Но с XSL'ом не работал, кто нибудь может объяснить как эти конструкции работают более подробно и в чем разница между ними? Было бы очень круто если на примерах.

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

Текст комментария не сохраняеться при ошибке отправления комментария. Не очищайте форму до отправки сообщения, или сохраняйти в localstorage.

Леша @zxqfox, а следом и Коля @gruzzilkin интересуются, как начать разрабатывать свою БЭМ-библиотеку.

Ответ на этот вопрос может быть разным в зависимости от того, что вы вкладываете в этот термин.

Я попробовал рассмотреть создание библиотеки от простого к сложному, постепенно добавляя фичи.

А именно:

• Самый простой вариант, когда библиотекой является просто папка с блоками
• Разделение библиотеки по уровням переопределения
• Вид библиотеки после добавления документации
• Пример файловой структуры с тестами и линтерами
• Оформление своей библиотеки

А в конце поделился рецептом, как быстро получить себе всю инфраструктуру, которую мы используем для bem-библиотек. TL;DR

Любая папка с блоками — библиотека

В самом простом случае любая папка, в которой лежат файлы с реализацией блоков, может служить библиотекой.

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

my-library/
    clearfix/
        clearfix.css

Конечно, просто копировать ее из проекта в проект не очень удобно. Поэтому стоит воспользоваться любимой системой контроля версий и опубликовать библиотеку, скажем, на github. На проекты ее удобно будет доставлять через bower.

Получим:

my-library/
    .git/
    bower.json
    clearfix/
        clearfix.css

Теперь представим, что у нас в библиотеке появился блок ua, который будет помогать с feature detection.

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

Нужный блок можно реализовать несколькими способами.

Самый простой — поступить по аналогии с clearfix и положить реализацию в соответствующую папку:

my-library/
    .git/
    bower.json
    clearfix/
        clearfix.css
    ua/
        ua.js

Однако, очевидно, что для разных платформ будут нужны разные данные. Например, на мобильном устройстве нас интересует ориентация устройства, для десктопа это знание не нужно. Тогда как часть информации о user agent будет нужна на всех платформах.

Как можно избежать дублирования кода и при этом не тянуть лишний код туда, где он заведомо не нужен?

Разделение блоков по уровням переопределения

Можно воспользоваться концепцией уровней переопределения. Это может выглядеть так: один блок представляем «слоями», а каждый новый слой до- переопределяет либо какую-то часть визуальных свойств, либо доопределяет поведение блока.

В результате структура библиотеки может выглядеть так:

my-library/
    .git/
    bower.json
    common.blocks/
        clearfix/
            clearfix.css
        ua/
            ua.js
    desktop.blocks/
        ua/
            ua.js
    touch.blocks/
        ua/
            ua.js

Мы видим, что блок ua оказался разделен на общую между всеми платформами часть (она попала в common.blocks) и специфику, необходимую в конкретном окружении.

Как это работает?

Сборщик знает, какие уровни переопределения и в каком порядке мы хотим собирать для нашего проекта. Поэтому код из последующих «слоев» сможет перекрыть предыдущий.

Нагляднее всего это можно продемонстрировать на примере с CSS:

/* my-library/common.blocks/b1 */
.b1 {
    width: 150px;
    height: 50px;
}

/* my-library/desktop.blocks/b1 */
.b1 {
    font-size: 24px;
    height: 80px;
}

Здесь некий блок b1 представлен на двух уровнях: common.blocks и desktop.blocks. При этом на общем уровне ему задаются высота и ширина, на уровне desktop.blocks добавляется знание про размер шрифта, а высота переопределяется новым значением.

Если писать код определенным образом, то аналогичного эффекта можно достичь и для остальных технологий, в т.ч. JavaScript и шаблонов. Например, мы используем i-bem.js и BEMHTML(https://ru.bem.info/technology/bemhtml/), чтобы упростить себе эту задачу.

Документируем блоки библиотеки

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

Получим что-то вроде:

my-library/
    .git/
    bower.json
    common.blocks/
        clearfix/
            clearfix.css
            clearfix.md
        ua/
            ua.js
            ua.md
    desktop.blocks/
        ua/
            ua.js
            ua.md
    touch.blocks/
        ua/
            ua.js
            ua.md
    README.md
    CHANGELOG.md

Тестируем и следим за кодстайлом

Если работу над библиотекой ведут сразу несколько разработчиков, то нужно следить за кодстайлом, для блоков писать тесты, которые бы запускались на прекоммит-хук и в CI:

my-library/
    .csscomb.json
    .git/
    .githooks/
        pre-commit
    .jscsrc
    .jshint-groups.js
    .travis.yml
    bower.json
    common.blocks/
        clearfix/
            clearfix.css
            clearfix.md
        ua/
            ua.js
            ua.md
            ua.spec.js
    desktop.blocks/
        ua/
            ua.js
            ua.md
            ua.spec.js
    package.json # здесь задекларируем модули для сборки и тестирования
    touch.blocks/
        ua/
            ua.js
            ua.md
            ua.spec.js
    README.md
    CHANGELOG.md

Как мы оформляем bem-библиотеки

В какой-то момент для наглядного примера работы каждого блока во всей его вариативности может потребоваться демо-страница.

Я не случайно оставил за скобками всю историю про сборку таких примеров, тестов и документации по всем уровням переопределения.

Также не стоит ограничиваться unit-тестами для JavaScript, проверки требуют и шаблоны, и верстка. А для всех видов тестов в свою очередь потребуется анализ покрытия (coverage).

Для решения всех этих задач в БЭМ-платформе существуют готовые инструменты. Их достаточно много, и каждый требует какого-то времени, чтобы с ним разобраться.

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

TL;DR

Я бы предложил поступить примерно так:

git clone https://github.com/bem/bem-components.git my-library
cd $_
rm -rf *.blocks/* design

Теперь можно пользоваться ;)

Конечно, это не самый элегантный способ, но зато быстро и работает.

Мы думаем над тем, как облегчить получение готовой инфраструктуры для своей библиотеки. Решение видится в пакете-обертке над всем необходимым с удобным и лаконичным API.

Рассказывать о ней планируем в нашем блоге. Stay BEMed!

Возможно ли использование компонентов реализованных как bem блоки на проектах ничего не знающих о bem? Если да, то как именно?

Можем ли мы использовать вместо BEM модификаторов WAI ARIA атрибуты, в случаях, когда нужно отобразить состояние и прочие кейсы на доступность?

Например,

<div aria-disabled="true"></div>

Можем ли мы опираться только на ARIA-атрибуты, если нам нужно написать какую-то логику на задисейбленный элемент?

if (this.attr('aria-disabled')) {}

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

if (this.elem('some-element').mod('disabled')) {}

Смотря на то как написаны COA нет ясности, а из API то как мне использовать команды?

Вот мне надо собирать bem-tools-ом так, чтобы он не использовал cache,

И вроде нечто такое есть forceCache: ture, но как мне

require('bem').api.build({ forceCahse: true, //.....  })

выполнить то? Чтобы не использовал он Cache.... А то подает с ним постоянно.