@campykid Предложу экспресс-туториал, который не раскрывает всех возможностей, но, надеюсь, дает возможность решить 90% возникающих задач.

Для начала важно понять принцип работы BEMHTML.

Работает он примерно так. 1) Скомпилированный BEMHTML — это функция, на вход которой подается дерево (в данном случае BEMJSON).

2) Это дерево рекурсивно обходится и для каждого узла вызываются все описанные в шаблонах предикаты (они же условия или матчеры).

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

В общем случае условие записывается в виде

match(function() {
    // если эта функция вернет truly-значение, выполнится тело шаблона
})

Можно писать проверку на произвольные условия типа match('a' == 'a'), match(3 < 5) или match(true), но чаще всего нас интересуют условия, проверяющие текущий узел BEMJSON-дерева. Он доступен в поле this.ctx (текущий контекст).

Например, чтобы написать какой-то шаблон для блока b1, нужно проверить, что this.ctx.block === 'b1'. Это можно сделать с помощью универсального

match(function() {
    return this.ctx.block === 'b1';
})

А можно воспользоваться шоткатом:

block('b1') // это эквивалентно предыдущему условию (на самом деле не совсем ;))

Аналогичные шоткаты есть и для остальных БЭМ-сущностей — элементов (elem()) и модификаторов (mod()).

Вот так можно записать условие, которое отработает, когда во входящем BEMJSON окажется { block: 'b1', elem: 'e1', elemMods: { m1: 'v1' } }:

block('b1').elem('e1').elemMod('m1', 'v1')

4) Помимо условий про БЭМ-сущности, есть еще моды про конкретную часть результирующего HTML:

• tag() — тег
• attrs() — атрибуты
• mix() — миксы с другими БЭМ—сущностями
• js() js-параметры
• cls — дополнительные классы
• content() — содежимое тега.

Все эти моды являются шоткатами для проверки поля _mode на равенство соответствующей строке. Например,

match(function() {
    return this._mode === 'tag';
})

эквивалентно tag().

Когда условие на одну из этих мод для данного узла BEMJSON-дерева истинно, в теле шаблона можно повлиять на соответствующую часть HTML, получаемого на выходе:

block('b1').tag()('span'); // <span class="b1"></span>

5) Вызов этих мод происходит благодаря базовым шаблонам, описанным в блоке i-bem.bemhtml.

Грубо говоря, сначала для каждого узла BEMJSON-дерева, вызывается шаблон по моде '' (пустая строка). В этом шаблоне вызывается мода default. В ней в нужном порядке зовутся все моды из пункта 4.

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

mode('my-mode')(function() {
    return 42;
});

Чтобы ее вызвать пригодится apply(). Выполнение apply('my-mode') вернет42` — результат вычисления тела данной моды.

7) Условия проверяются снизу вверх. Например, если написать

block('b1').content()('первый');
block('b1').content()('второй');

То в результате получим <div class="b1">второй</div>.

Т.е. принцип ровно такой же, как в CSS:

.b1 {
    color: red;
}

.b1 {
    color: green; /* победит правило, записанное ниже */
}

8) Если возникает необходимость повлиять на процесс выполнения стандартных мод из пункта 4, можно написать собственный шаблон для нужной сущности по моде def() и т.к. он окажется ниже базового шаблона по этой моде, отработает новая реализация.

9) Может возникнуть ситуация, когда из нижнего шаблона нужно получить результат выполнения предыдущего. Для этого можно вызвать applyNext():

block('b1').content()('первый');
block('b1').content()(function() {
    applyNext() + 'второй' // первыйвторой
});

Частая задача, когда в нем возникает необходимость — это добавить обертку:

block('b1').content()(function() {
    return {
        elem: 'inner',
        content: applyNext()
    };
});

или дополнительную сущность рядом:

block('b1').content()(function() {
    return [
        { block: 'b2' },
        applyNext()
    ];
});

Еще с его помощью можно повлиять на поля объекта this и продолжить выполнение остальных шаблонов для данного узла BEMJSON с уже измененным this:

block('b1').def()(function() {
    applyNext({ someField: 'b1' });
});

При этом очень часто приходится менять какие-то поля this.ctx. Это можно сделать с помощью applyNext({ 'this.ctx': 'новый контекст' }), а можно воспользоваться шоткатом для такого случая: applyCtx('новый контекст').

Это удобно, например, когда нужно полностью перезаписть какой-то узел входного BEMJSON на новый и выполнить для него шаблоны:

block('b1').def()(function() {
    applyCtx({
        block: 'b2'
    });
});

Краткое резюме

1. applyCtx({}) — это applyNext({ 'this.ctx': {} }).
2. applyNext() — это вызов предыдущих шаблонов по текущей моде (наследование). Может как вернуть результат для дальнейшего использования, так и просто выполнить остальные шаблоны с какими-то изменениями this.
3. apply() в чистом виде чаще всего нужен для получения результата выполнения определенной моды. Все остальные случаи нужны крайне редко и скорее всего указывают на ошибку в архитектуре.

А что будет, если в двух шаблонах матчащихся на один блок будут конструкции applyNext() ? Что будет, если шаблон один, в нем используется applyNext , но больше никто на этот блок не матчится?

Всем привет! @tadatuta, скажу от себя спасибо за разъяснение, стало немного понятнее=) Видимо все-таки от недопонимания всей технологии задам здесь еще вопрос, который имеет отношение к apply. Возможно ли контролировать порядок применения apply для модификаторов. Поясню на примере. Допустим у нас есть блок link (ссылка). Есть к нему модификатор "loading" со значением "yes", который добавляет справа от ссылка еще маленький span с иконкой загрузки. И есть модификатор external опять же со значением "yes". Этот модификатор, добавляет справа иконку extrenal ссылки (например http://fortawesome.github.io/Font-Awesome/3.2.1/icon/external-link/). Хотелось сделать их примерно одинаково.

    block('link').mod('loading', 'yes')(
        content()(function() {
            return [
                applyNext(),
                {
                    block: 'mrkt-loading',
                    mix: [
                        {
                            block: 'mrkt-link',
                            elem: 'loading-icon'
                        }
                    ]
                }
            ];
        })
    );

    block('link').mod('external', 'yes')(
        content()(function() {
            return [
                applyNext(),
                {
                    elem: 'external-icon'
                }
            ];
        })
    );

Но в таком

        {
            block: 'mrkt-link',
            mods: {
                view: 'dashed',
         //       external: 'yes',
                loading: 'yes'
            },
            content: 'Тестовая ссылка',
            url : '/test'
        },

случае получаем ошибку "Maximum call stack size exceeded". Видимо по-очереди дергаются applyNext в коде модификаторов и уходит в бесконечную рекурсию. Как разрулить? Такая проблема возникала у меня пару месяцев назад и пример был чуть менее надуманный, но сейчас я его уже точно не могу вспомнить, поэтому привожу пример с ссылками).

Хотелось бы узнать как лучше решать такую задачу. И еще важно, что мне нужно контролировать в каком порядке идет html. Т.е. если оно заработает мне важно, чтобы иконка загрузки была всегда после иконки extrenal, если она есть.

UPDATE Сообщение @escaton в момент написания своего не видел. Похоже, что спрашивается примерно тоже.

@escaton

А что будет, если в двух шаблонах, матчащихся на один блок, будут конструкции applyNext()?

Отвечу простым примером. Пусть есть такой BEMJSON: { block: 'b1', content: 'initial' }.

Напишем такие шаблоны:

/* сначала в любом случае окажутся базовые шаблоны из i-bem.bemhtml */

block('b1').content()(function() {
    var base = applyNext();
    console.log('first tmpl', base);

    return 'new content';
});

block('b1').content()(function() {
    var base = applyNext();
    console.log('second tmpl', base);

    return base + ' after second tmpl';
});

block('b1').content()(function() {
    var base = applyNext();
    console.log('third tmpl', base);

    return base + ' after third tmpl';
});

В результате сгенерируется вот такой HTML: <div class="b1">new content after second tmpl after third tmpl</div> и вот такой лог окажется в консоли:

first tmpl initial
second tmpl new content
third tmpl new content after second tmpl

Думаю, эта иллюстрация отвечает на вопрос?

Что будет, если шаблон один, в нем используется applyNext , но больше никто на этот блок не матчится?

Правильнее сказать не «больше», а «раньше». applyNext() — это про вызов предыдущих шаблонов. И тут можно быть спокойным — вызовется базовый шаблон из i-bem.bemhtml.

@2rist В примере что-то напутано: матчеры написаны на link, а судя по всему предполагался mrkt-link, но даже так не очень понятно, что хотелось сделать, чтобы шаблоны зациклились.

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

block('b1')
    .match(function() { return !this._guard; }) // проверяем, что флаг не выставлен
    .content()(function() {
        return [
            applyNext({ _guard: true }), // выставляем флаг
            { block: 'icon' }
        ];
})

@tadatuta результат выполнения базовых шаблонов — html?

@escaton результат выполнения BEMHTML — строка.

@2rist помогло с флагом? ;) Какие у вас версии библиотек используются? @tadatuta А разве эту проблему с зацикливанием не решает какая то версия bem-core?

@tadatuta, @voischev Натупил с примером. По ходу написания коммента, кое-что переделывал и накосячил с копипастой. Попробую еще раз. Есть блок mrkt-link (на префиксы mrkt не обращайте внимание, специфика проекта)

block('mrkt-link')(
    tag()(function() {
        return 'a';
    }),
    attrs()(function() {
        return {
            href: this.ctx.url || '#'
        }
    })
);

И есть 2 модификатора external и loading, работающих одинаково - добавляющих справа ссылки "иконку внешней ссылки" или значок загрузки. Код модификаторов

block('mrkt-link').mod('loading', 'yes')(
    content()(function() {
        return [
            applyNext(),
            {
                elem: 'loading-icon'
            }
        ];
    })
);

block('mrkt-link').mod('external', 'yes')(
    content()(function() {
        return [
            applyNext(),
            {
                elem: 'external-icon'
            }
        ];
    })
);

Если использовать модификаторы по одному, то все работает и получается html вида

{
    block: 'mrkt-link',
    mods: {
        external: 'yes'
       //, loading: 'yes'
    },
    content: 'Тестовая ссылка',
    url : '/test'
},
<a class="mrkt-link mrkt-link_external_yes" href="/test">Тестовая ссылка<div class="mrkt-link__external-icon"></div></a>

//-----------------
{
    block: 'mrkt-link',
    mods: {
       // external: 'yes',
       loading: 'yes'
    },
    content: 'Тестовая ссылка',
    url : '/test'
},

<a class="mrkt-link mrkt-link_loading_yes" href="/test">Тестовая ссылка<div class="mrkt-link__loading-icon"></div></a>

Если же включать оба модфикатора одновременно

{
    block: 'mrkt-link',
    mods: {
       external: 'yes',
       loading: 'yes'
    },
    content: 'Тестовая ссылка',
    url : '/test'
},

то получаем Maximum call stack size exceeded

Теперь надеюсь более понятно получилось.
Попробовал решить флажками.

block('mrkt-link').mod('external', 'yes')(
    content().match(function() { return !this._external_guard; })(function() {
        return [
            applyNext({ _external_guard: true }),
            {
                elem: 'external-icon'
            }
        ];
    })
);

block('mrkt-link').mod('loading', 'yes')(
    content().match(function() { return !this._loading_guard; })(function() {
        return [
            applyNext({ _loading_guard: true }),
            {
                elem: 'loading-icon'
            }
        ];
    })
);

Проблема с Maximum call stack size exceeded исчезла. Теперь отображается нормально

<a class="mrkt-link mrkt-link_external_yes mrkt-link_loading_yes" href="/test">Тестовая ссылка<div class="mrkt-link__external-icon"></div><div class="mrkt-link__loading-icon"></div></a>

Не совсем понял почему был косяк, я думал у applyNext есть защита от зацикливания. Т.е. получается, если я в двух модификаторах одного и того же блока использую applyNext, то мне нужно в обоих добавлять guard-а, чтобы я мог применить модификаторы одновременно? Или я что-то принципиально не так делаю?

И еще вопрос, можно ли в моем случае как-то управлять порядком применяемых модификаторов. Т.е. Не важно в каком порядке я указываю модфикаторы loading: 'yes', external: 'yes'

            block: 'mrkt-link',
            mods: {
                loading: 'yes',
                external: 'yes'
            },

в результате

10 years ago

voischev

@2rist Ты все очень понятно написал :) можно же написать в одном шаблоне) что-то типа:

block('mrkt-link')(
    content()(function() {
        var mods = this.ctx.mods;
        return [
            applyNext(),
            mods.external && {
                elem: 'external-icon'
            },
            mods.loading && {
                elem: 'loading-icon'
            }
        ];
    })
);

Тут как раз удобны булевы значения модификаторов ;)

Если я что-то не так написал, думаю меня поправят.

10 years ago

2rist

@voischev Можно и в одном шаблоне, но это не удобно=) Пример сильно упрощен для наглядности, кода может быть сильно больше, чем просто добавление одного элемента. К тому же у нас к блоку ссылки уже 6 возможных модификаторов с различными значениями, а блоку кнопки 7 модификаторов (юзать так юзать) и не хотелось бы их в одном файле держать. Так что как вариант твое решение подходит, но хотелось бы узнать есть ли еще варианты=).

10 years ago

2rist

Получается вопрос еще в том - должны ли модификаторы знать друг о друге? Нормально ли в коде одного модификатора проверять есть ли другой? Или же они должны быть полностью независимыми. Вопрос идеологический=)

10 years ago

voischev

@2rist ох) какие все идеологичные стали) Ты же знаешь что мы делаем 100500 сайтов на БЭМ? Примерно представляешь их сложность. Интерес в том, что почему то, у нас не возникает таких мыслей как то сильно менять представление в зависимости от модификатора какой то блок. Скорее всего у нас так получается потому что мы более сильно дробим на блоки какую то функциональность и уже в месте объявления блока рулим расположением контента в массиве, а не хотим модификатором все поменять) (хотя часто что-то меняется модификатором и в наши проектах, но чаще модификаторы про разное) А если что-то по расположению меняется модификатором — то скорее всего достаточно CSS для этого. )))

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

А расположением блоков рулит бы в месте где объявляется блок. (Повторил мысль))) )

Надеюсь очевидные вещи пересказал)

---

PS: Кстати да. У тебя модификаторы про одно. По хорошему нужно писать модификатор так

block: 'mrkt-link',
mods: {
    icon : 'loading' // или 'external'
},

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

10 years ago

2rist

@voischev Разве это сильное изменение представления? По-моему нет=) Опять же повторюсь, что этот код просто для "примера". Естественно можно решить и другими способами без applyNext, с помощью css или еще как-то. Мне интересно разобраться в том как это работает. На мой взгляд, ситуация в которой у одного блока в разных модификаторах есть applyNext не такая уж надуманная и может случиться. Поэтому хотелось бы знать, что в таком случае надо делать, как предлагает методология БЭМ справляться с такими задачами. Если методология такова, что "старайтесь разбить все как можно меньше, чтобы не надо было применять applyNext", то ок, нет проблем, я хотя бы буду знать,что такая best practice. P.S.: Модификаторы не совсем про одно. По-факту у нас есть модификатор view с возможными значениями ["extrenal", "dashed", "without-underline"], вот этот модификатор у нас про одно и то же и отвечает за вид ссылки и не может быть одновременно несколько значений (потому как есть ui kit и в нем прописано как должны выглядеть все внешние ссылки, и что они не могут быть подчеркнутыми). И есть отдельно модификатор loading yes, он может добавляться к любой ссылке в зависимости от бизнес логики. Я упростил пример немного, чтобы не вдаваться в детали.

10 years ago

tadatuta

@2rist

applyNext() добавляет защиту от зацикливания для самого себя, но в описанном случае происходит примерно следующее:

1. Отрабатывает матч на один из модификаторов. В нем вызывается applyNext(), который должен выполнить матчи на все остальные шаблоны, кроме самого себя.
2. Среди них оказывается шаблон для второго модификатора, а в нем — снова applyNext(), который требует вызвать все шаблоны, кроме текущего. Т.к. в этот момент предыдущий шаблон еще не выполнился, то он вызывается снова. И так до бесконечности.

По поводу порядка выполнения, предположу, что нужно в _external добавить mustDeps от _loading.

9 years ago

belozer

Захотелось немного поднять ветку форума :)

А почему название функции для вызова предыдущей версии шаблона applyNext()? Почему не applyBase() или applyPrevious() (applyPrev())?

9 years ago

tadatuta

@belozyorcev Шаблоны применяются снизу вверху от более частного к более общему (как в CSS). И applyNext() означает «выполни следующий подходящий для данного узла шаблон, как если бы текущего шаблона не было».

9 years ago

belozer

@tadutata теперь ясней стало :) Спасибо

9 years ago

tadatuta

@JiLiZART у меня связь пропала, но здесь в комментах есть ответ про applyCtx()

9 years ago

Roman-Fov

Всем привет!

Потихоньку разбираюсь с apply*. Но меня не покидает ощущение, что копаю я не в том направлении и это совсем не то, что мне нужно. Прошу направить в нужное русло.

Какие дела: Есть project-stub со стремительно растущими bemjson файлами и мешаниной из данных и описания блоков. Рост создают повторяющиеся блоки(трёхуровневые менюхи, несколько десятков товаров на странице или теги). Вместе с ростом bemjson растёт и моё желание сделать их чище и меньше. Cначала попробовал генерировать bemjson в bemjson. Забивал массив данных и делал по ним map. Сильно не помогло тк и данные остались в bemjson и при изменении структуры страницы описание блоков необходимо править в нескольких bemjson файлах. Сейчас пытался вынести генерацию bemjson вместе с логикой в bemhtml. Попробовал... Дико усложнились bemhtml...

• Это идёт в разрез с рекомендацией из документации, что шаблоны должны быть максимально простыми и затрагивать только html-представление.

Можно ли сложить данные в одном месте, а блоки описывать в другом месте (единственном)?

9 years ago

tadatuta

@Roman-Fov Ответ на этот вопрос называется BEMTREE. Начать знакомство можно с https://github.com/bem/bem-forum-content-ru/issues/716

А в качестве примера реализации посмотреть на https://github.com/tadatuta/bem-bemtree-static-project-stub/tree/one-bundle-gulp-watcher (важно: это не основная ветка репозитория, не перепутать с master при чекауте).

Если возникнут вопросы — можно завести отдельный тред про BEMTREE на форуме.