Правильная генерация блока menu из bem-components

Форум /

Я сломал весь мозг пытаясь понять можно ли сгенерировать контент для блока menu за один проход. Проблема заключается в том, что блок menu не приемлет в поле content контекста ничего кроме элемента menu__group или блока menu-item. Таким образом, даже если положить в контент блока menu БЭМ сущность, которая могла бы развернуться в menu__group или menu-item, будет выброшено исключение. Проблему мне удавалось решить только используя 2 прохода. Сначала выполняем преобразование блоков в поле content вне блока menu, а на второй проход уже развёрнутое содержимое размещаем в блоке menu.

В BH это получилось сделать более-менее удачно, с помощью метода bh.processBemjson(). В xjst трансформацию контента пришлось делать в bemtree, а в блок menu вставлять уже в bemhtml. Приручить applyCtx, чтобы получилось как в BH не вышло.

Хотелось бы понять, возможно ли сгенерировать таким образом содержимое блока menu средствами bemhtml,не прибегая к bemtree:

view ориентированный bemjson на входе

{
    block: 'my-menu',
    content: [
        {
            elem : 'group',
            content : [
                {
                    elem : 'item',
                    title : '1st level item with sub-item'
                    content : [
                        elem : 'group',
                        content : {
                            elem : 'item',
                            content : '2nd level item'
                        }
                    ]
                }
            ]
        },
        {
            block: 'my-menu',
            elem : 'group',
            content : [
                {
                    elem : 'item',
                    title : '1st level item but in separate section'
                }
            ]
        }
    ]
}

На выходе ожидается разметка блока my-menu один из элементов которого будет блок menu (mix my-menu__menu) внутри которого будут menu__group (mix my-menu__group) и menu-item (mix my-menu__item).

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

9 years ago

Guria

https://github.com/bem/bem-components/issues/1513

9 years ago

narqo

Проблему мне удавалось решить только используя 2 прохода. Сначала выполняем преобразование блоков в поле content вне блока menu, а на второй проход уже развёрнутое содержимое размещаем в блоке menu.

У нас имено так работает блок select (см. select__menu.bemhtml). Не скажу, что это хорошо или плохо — другого способа, мы пока не придумали.

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

Ты можешь раскрыть мысль? Как сохранить ленивость блока, правильную отрисовку в HTML до загрузки JS (нам важно, чтобы лейаут максимально «не скакал» в процессе загрузки страницы — это очень «анноит» пользователей) и при это унести часть логики в JS?

9 years ago

Guria

Вот такой подход мне как раз совсем не подходит. Во-первых, у меня довольно не простые menu-item. Во-вторых они бывают разные в зависимости от модификатора. Хочется воспользоваться всей мощью bemhtml и описать их как элемент блока.

Ты можешь раскрыть мысль? Как сохранить ленивость блока, правильную отрисовку в HTML до загрузки JS (нам важно, чтобы лейаут максимально «не скакал» в процессе загрузки страницы — это очень «анноит» пользователей) и при это унести часть логики в JS?

Да я уже понял именно эту проблему был призван решать код шаблонов блока menu.

https://github.com/bem/bem-components/issues/1520 решит мои проблемы, т.к. мне требуется базовый блок menu без menu_mode_* расширений.

9 years ago

narqo

Во-первых, у меня довольно не простые menu-item. Во-вторых они бывают разные в зависимости от модификатора.

Пообщались с @veged @dfilatov @aristov, проблему можно решить через кастомные моды (по сути создать аналог processBemjson из bh). Это будет куда проще, чем текущая реализация в pr.

9 years ago

Guria

А что такого сложного в текущем pr? Код ровно тот же. Совместимость соблюдена. Гибкость повышена

9 years ago

qfox

Не знаю что вы решите по этому issue, но всеми руками за аналог processBemjson в bemhtml.

9 years ago

Guria

Аналог processBemjson это хорошо и хотелось что бы кто-то более подробно осветил эту тему. Тем не менее хочется услышать аргументированный ответ, что именно не позволяет принять https://github.com/bem/bem-components/issues/1520 ?

9 years ago

narqo

А что такого сложного в текущем pr? Код ровно тот же. Совместимость соблюдена. Гибкость повышена

1) PR не решает проблему в общем случае, а просто перекладывает ее из одной папки в другую. Если тебе, для того же самого kg-menu, нужен будет модификатор _mode, ты сможешь сделать, как хочешь? 2) Добавлять флаги в this вне моды default, не очень круто — они точно так же могут понадобиться в модах mix/js/attrs (сейчас не нужны, но с точки зрения общего стиля кода в библиотеке, это аргумент). 3) Говорить «в BEMJSON блока menu можно класть все что угодно, но работать будет только с блоками menu-item», исключительно по опыту поддержки библиотек, не прокатывает. Как задокументировать такое BEMJSON API в библиотеке?

Это основные причины, почему сходу я не готов принять PR в текущем виде.

Можешь показать пример того, что в каком виде ты хочешь задавать твой блок и во что он должен разворачиваться? Код из gist выше, некоректен — там вообще блока menu в финальном BEMJSON нет.

9 years ago

Guria

Спасибо, так гораздо понятнее.

На самом деле я смогу воспользоваться в том числе модификатором _mode, благодаря проверке на наличие поля content. Можно добавить только его не перекладывая в папку, хоть я и считаю что переложить всё же стоит.
Понятно. Ни что не мешает снова вернуться к использованию моды def.
Здесь мне сложнее аргументировать, но попробую.

В документации есть следующее предложение:

Служит для визуальной группировки пунктов меню. Не влияет на общую логику выбора пунктов.

Что уже противоречит декларации:

content Array Массив пунктов меню.

Оказывается в массиве у нас могут быть группы с массивами пунктов в меню. И, внезапно, в документации не сказано, что пункт меню должен быть реализован блоком menu-item.

Таким образом, вопрос: "Как задокументировать такое BEMJSON API в библиотеке?" - актуален, в том числе, и для текущей версии. У меня есть некоторые мысли на этот счёт, но они пока не сформировались в нечто целостное.

Итого, предлагаю:

в PR вернуть использование моды def
принять PR, т.к. оно не ломает совместимость, сохраняет текущее API блока и не требует изменения документации
вынести на обсуждение вопрос с документированием блока menu

9 years ago

veged

@zxqfox в bemhtml в текущем виде не может быть аналога processBemjson т.к. там нет выделенной стадии формирования bemjson — дефолтная мода заполняет буфер строками с html

но это не проблема для реального использования (в частности для изначальной задачи @Guria) — можно сделать свою кастомную моду и использовать её

9 years ago

qfox

@veged Очевидно, стоит портировать xjst на пхп, чтобы понять как оно там работает... ;-)

Вы не думали там дом ноды генерировать из bh/bemhtml? Строки даже не модно уже.

9 years ago

Guria

@veged Можно пример подобной кастомной моды? Будет ли такой подход приемлем для библиотеки?

9 years ago

veged

можно даже без кастомной моды!

как я вижу задачу: есть my-menu и внутри есть my-menu__my-elem ({ block : 'kg-menu', content : [{ elem : 'my-elem' }, { elem : 'my-elem' }] }), которые должны превратиться в какое-то memu с menu-item-ами

достаточно таких шаблонов:

block('my-menu')(
    def()(function() {
        var menu = { block : 'menu', content : [] };

        this.ctx.content.forEach(function(i) {
            applyCtx({ _kgMenuContent : menu.content }, i);
        });

        applyCtx(menu); // к этому моменту имеем полный bemjson для menu
    }),

    elem('my-elem').def()(function() { // матчимся на любые элементы my-menu
        this._kgMenuContent.push({ block : 'menu-item' }); // делаем любые menu-item
    })
)

9 years ago

aristov

это же магия!

9 years ago

Guria

@veged Спасибо за пример. Попробую данный подход и посмотрю на сколько он будет удобен.

Однако яро прошу принять хотя бы проверку на наличие поля content перед попыткой итерирования по нему.

9 years ago

veged

мы готовы принять все полезные исправления, но только, пожалуйста, в виде раздельных пуллреквестов

9 years ago

Guria

@veged подход отличный, беру на заметку. Однозначно его надо сохранить в рецепты BEMHTML. Но меня всё таки волнует тот факт, что пользователю блока my-menu или разработчику делающего новый элемент придётся знать, что шаблоны не имеют права ничего генерировать и лишь добавлять что-либо в некое поле контекста. Таким образом считаю, что подход имеет право жить на уровне проекта, но не в библиотеке. Вы сами учите критически относиться к тому, как должна выглядеть библиотека. Библиотека вынуждающая такой подход использовать, тоже не желательный вариант

9 years ago

Guria

@veged @tadatuta @narqo вынос логики в menu_mode с сохранением работы в рамках моды def считаем полезным исправлением?

Чтобы оставлять комментарии, необходимо авторизоваться.