Как стать автором
Обновить

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

Привет. Есть шансы на поддержку BH наравне с BEMHTML?
Я думал над этим, но если оставлять bemtree — то есть ли смысл в bh?
А если не оставлять — то что использовать взамен?
Ммм, еще не видел этого репозитория, спасибо. Попробую найти время на интеграцию.
Конечно, видел, пробовал.
Многое не понравилось.
Например, там плохо реализована маршрутизация. Если про то, что там есть для роутинга, вообще можно употреблять такие слова как «маршрутизация» и «реализована».
Такое надо сразу же развидеть.
Там много моментов под вопросов в коде, работающим с АПИ, очень маленькая скорость шаблонизации в BEM.JSON, bem-bl вместо bem-core и еще куча всего.
Имеет лишь смысл форкнуть проект, переписать на bh, поработать с i-api-request медленным и неоптимальным и возможно потом писать что-то в продакшн на получившемся велосипеде.
Я бы сказал, что форкать смысла нет. Проще заново написать — что я и сделал, собственно.
Если позволяет время и команда, то да, bem-node даже не стоит переписывать.
Сначала хотел возмутиться, а потом таки да поход в АПИ все равно я переписывал под себя и то что нет новых библиотек тоже напрягает.
Специально залогинился, чтобы описать одну вещь, которая действительно мешает нам в bem-node.
1. Есть например базовое описание страницы, состоящее из трех блоков. Один из этих блоков раскрывается еще в три. Ну и один из этих трех раскрывается еще в два.
2. Допустим для описания структуры у нас будет blocks-desktop, а данные будут забираться через ctx.defer() в blocks-data (#евпочя)

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

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

Пока что это у нас одна из главных причин отказаться от bem-node.
Это разумеется легко обходится с помощью i-state

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

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

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

Кстати, я тут подумал, что мне все-таки будет не очень просто сделать нормальную интеграцию bem-priv+bh, потому что первым я вообще не пользовался, а на втором сделал только один небольшой проект. А там ведь наверняка свои «лучшие практики» уже и сформировавшися подходы.
Написал node-приложение, позволяющее создавать бем-сущности исходя из указанной папки (например, если натравить на папку block/__elem, то создастся файл с именем block__elem с нужным расширением и шаблоном), а также автоматическое создание структурыэлементов и модификаторов по deps- файлам. Легко интегрируется в webstorm. Стоит ли выложить в opensource?
Конечно. Хуже от этого никому не станет
> и шаблоном
какой шаблонизатор?
С шаблоном файла. Например, если в параметрах вы указали 'css js', то в файлы создадутся по шаблонам, которые идут в поставке либо настроены вами. По-умолчанию, для css файла используется шпблон с содержимым .{{block}}{{elem}}{{modname}}{{modval}} { }, и следуя примеру выше, в нем станет .block__elem {}. Разделители сущностей и пути к шаблонам настраиваемы.
Если вы считаете, что сделали что-то полезное и готовы потратить время и силы — выкладывайте, почему нет?
Выложил. Буду рад помощи переводу на англ. github.com/f0rmat1k/bemy
Только что понял, что это очень похоже на bem create. Вот дока. Можете пояснить в двух словах, в чем разница?
Отличия примерно такие:
— bem tools, насколько я помню, требует наличие level.js, без него отказывается даже просто блок создать. Bemy работает проще (кому-то плюс, кому-то минус) и ориентируется на path, который вы в него отправили.
— bemy использует шаблоны для файлов и во время создания заполняет их бем-именами.
— bemy умеет создавать структуру элементов, модификаторов текущего блока по deps-файлам (bem tools вроде бы так не умеет, он создает файлы страниц по депсам, как заявлено. Не проверял). То есть вы заполняете deps тем, что вам надо, 1 хоткей и структура (по-умолчанию с css-файлами) готова.
— планирую допилить глубокий rename бем-сущности.
Наконец то доделал задачу переименования (в т. ч. внутри файлов). И добавил еще различных плюшек:
— автооткрытие файлов с указателем на нужной строке (указатель конфигурируется в шаблонах)
— шоткат bemy для простого вызова тулзы
— более гибкая работа с файловой структурой (например, можно вызывать беми относительно файлов)
— поддержка кастомных разделителей БЕМ сущностей (теперь не только '_' и '__')
— тесты и другое.
Ммм, развиваетесь, очень интересно!
Напишите на ru.bem.info/forum пост — там намного больше народу увидит.
Можно задать обратный вопрос: а почему код изначально не на GitHub'е? )
На гитхабе, да не на том. На днях выложу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории