Изоморфный БЭМ

[@Guria]

Привет. Есть шансы на поддержку BH наравне с BEMHTML?

[@asavin]

Я думал над этим, но если оставлять bemtree — то есть ли смысл в bh?
А если не оставлять — то что использовать взамен?

[@tadatuta]

github.com/sbmaxx/bem-priv

[@asavin]

Ммм, еще не видел этого репозитория, спасибо. Попробую найти время на интеграцию.

[@asci]

github.com/bem-node/bem-node/ видели?

[@asavin]

Конечно, видел, пробовал.
Многое не понравилось.
Например, там плохо реализована маршрутизация. Если про то, что там есть для роутинга, вообще можно употреблять такие слова как «маршрутизация» и «реализована».

[@xaxaTyH]

Такое надо сразу же развидеть.
Там много моментов под вопросов в коде, работающим с АПИ, очень маленькая скорость шаблонизации в BEM.JSON, bem-bl вместо bem-core и еще куча всего.
Имеет лишь смысл форкнуть проект, переписать на bh, поработать с i-api-request медленным и неоптимальным и возможно потом писать что-то в продакшн на получившемся велосипеде.

[@asavin]

Я бы сказал, что форкать смысла нет. Проще заново написать — что я и сделал, собственно.

[@xaxaTyH]

Если позволяет время и команда, то да, bem-node даже не стоит переписывать.

[@JCHouse]

Сначала хотел возмутиться, а потом таки да поход в АПИ все равно я переписывал под себя и то что нет новых библиотек тоже напрягает.

[@theproof]

Специально залогинился, чтобы описать одну вещь, которая действительно мешает нам в bem-node.
1. Есть например базовое описание страницы, состоящее из трех блоков. Один из этих блоков раскрывается еще в три. Ну и один из этих трех раскрывается еще в два.
2. Допустим для описания структуры у нас будет blocks-desktop, а данные будут забираться через ctx.defer() в blocks-data (#евпочя)

И вот тут если для каждого из блоков мне нужны данные, по логике bem-node их логично получать для каждого блока внутри blocks-data. По факту же это означает последовательное выполнение запросов, в то время как зачастую они не связаны друг с другом и эффективнее было бы выполнять их параллельно.

Это разумеется легко обходится с помощью i-state, но это 1) невообразимый костыль и 2) придется данные, полученные главным блоком прокидывать во внутренние блоки через ctx.content().

Пока что это у нас одна из главных причин отказаться от bem-node.

[@xaxaTyH]

Это разумеется легко обходится с помощью i-state

А можно поподробнее?

[@theproof]

i-state — это аналог req в express, туда можно положить данные, которые относятся к конкретному запросу. То есть в главном блоке, описывающем страницу сайта (например главную), можно сделать все запросы через ctx.defer(promise) и положить все данные в i-state, а уже во внутренних блоках брать данные из i-state. Выглядит очень странно и идет вразрез с логикой bem-node, но работает.

[@asavin]

В случае bnsf подобную проблему можно решить, например, таким способом:

// в этот блок вложен элемент data, в котором есть свой запрос
block('user-card').content()(function () {
    // рендерим элемент data
    var dataBlock = applyCtx({
        elem: 'data'
    });
    // шлем запрос
    return this.get('users', {
        user_ids: this.route.parameters.id
    }, function (data) {
         // что-то делаем с отрендеренным элементом и ответом от сервера
        return [dataBlock, {elem: 'bla', content: data.body}];
    });
});

// описание элемента data, который посылает запрос
block('user-card').elem('data').content()(function () {
    return this.get('users', {
        user_ids: 1
    }, function (data) {
        return data.body;
    });
});

Запросы объединятся. Выбор, когда рендерить блоки — до отправки запроса или после — остается за разработчиком.

[@theproof]

Вам правда нравится xjst?

[@asavin]

Ну, скобочек многовато, конечно, но свою задачу вполне решает.

Когда я начинал, то хотел сразу делать и под bh, но не нашел аналога bemtree. Сейчас появился, судя по тому проекту, на который чуть выше дает ссылку tadatuta, можно добавить поддержку. Это не должно быть очень сложно.

[@theproof]

Я скорее о том, что любой веб-разработчик не из Яндекса вряд ли выберет bemtree хотя бы по той причине, что непонятно, что он делает. Сюда можно добавить и новый синтаксис несмотря даже на js-вариант XJST — он очень непривычный.

[@asavin]

Может быть, хотя я — вполне себе любой разработчик не из Яндекса.

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

[@Mew]

Написал node-приложение, позволяющее создавать бем-сущности исходя из указанной папки (например, если натравить на папку block/__elem, то создастся файл с именем block__elem с нужным расширением и шаблоном), а также автоматическое создание структурыэлементов и модификаторов по deps- файлам. Легко интегрируется в webstorm. Стоит ли выложить в opensource?

[@Guria]

Конечно. Хуже от этого никому не станет

[@xaxaTyH]

> и шаблоном
какой шаблонизатор?

[@Mew]

С шаблоном файла. Например, если в параметрах вы указали 'css js', то в файлы создадутся по шаблонам, которые идут в поставке либо настроены вами. По-умолчанию, для css файла используется шпблон с содержимым .{{block}}{{elem}}{{modname}}{{modval}} { }, и следуя примеру выше, в нем станет .block__elem {}. Разделители сущностей и пути к шаблонам настраиваемы.

[@asavin]

Если вы считаете, что сделали что-то полезное и готовы потратить время и силы — выкладывайте, почему нет?

[@Mew]

Выложил. Буду рад помощи переводу на англ. github.com/f0rmat1k/bemy

[@asavin]

Только что понял, что это очень похоже на bem create. Вот дока. Можете пояснить в двух словах, в чем разница?

[@Mew]

Отличия примерно такие:
— bem tools, насколько я помню, требует наличие level.js, без него отказывается даже просто блок создать. Bemy работает проще (кому-то плюс, кому-то минус) и ориентируется на path, который вы в него отправили.
— bemy использует шаблоны для файлов и во время создания заполняет их бем-именами.
— bemy умеет создавать структуру элементов, модификаторов текущего блока по deps-файлам (bem tools вроде бы так не умеет, он создает файлы страниц по депсам, как заявлено. Не проверял). То есть вы заполняете deps тем, что вам надо, 1 хоткей и структура (по-умолчанию с css-файлами) готова.
— планирую допилить глубокий rename бем-сущности.

[@Mew]

Наконец то доделал задачу переименования (в т. ч. внутри файлов). И добавил еще различных плюшек:
— автооткрытие файлов с указателем на нужной строке (указатель конфигурируется в шаблонах)
— шоткат bemy для простого вызова тулзы
— более гибкая работа с файловой структурой (например, можно вызывать беми относительно файлов)
— поддержка кастомных разделителей БЕМ сущностей (теперь не только '_' и '__')
— тесты и другое.

[@asavin]

Ммм, развиваетесь, очень интересно!
Напишите на ru.bem.info/forum пост — там намного больше народу увидит.

[@Andre_487]

Можно задать обратный вопрос: а почему код изначально не на GitHub'е? )

[@Mew]

На гитхабе, да не на том. На днях выложу.

[@Mew]

github.com/f0rmat1k/bemy