Интересно, зачем тут https://github.com/bem/project-stub/blob/bh/.bem/make.js технология bemhtml подключается. Вроде как страница должна bh собираться, Но у меня статическая html не собирается с отключенным bemhtml. Это нормальное поведение?

Здравствуйте , матерые бойцы методологии БЭМ ! )) Вот столкнулся с проблемой , прочел документацию узнал про bem-tools и enb и встал в ступор , че из них юзать? Потом прочел все про bemhtml все чудно! И тут ниже я прочел про bh , что использовать? Что профитнее всего ?

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

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

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

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

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

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

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

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

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

толкнулись с проблемой распределения картинок по блокам Решили что наилучшим способом будет папка /block ../i ....block__element.jpg

Есть ли технология под сборку картинок? Я про bem-tools

По просьбе в твиттере от @life_maniac.

Те, кто используют наши шаблонизаторы BEMHTML или BH для верстки статики, часто спрашивают, как отключить минимизацию получаемого HTML.

Но не многие знают, что на самом деле никакой минимизации не происходит.

Почему? Потому что шаблонизаторы изначально генерируют из BEMJSON оптимальный для продакшена HTML.

Если вам необходимо получать красиво отформатированный HTML, подойдет любой pritty-print, например, js-beautify.

Его можно звать через CLI (js-beautify --html) либо встроить прямо в технологию сборки через JS API.

Приведу примеры такой технологии для bem-tools и ENB (технология написана исходя из предположения, что вы используете project-stub).

bem-tools

var BEM = require('bem'),
    Q = BEM.require('q'),
    environ = require('bem-environ'),
    join = require('path').join,
    BEMBL_TECHS = environ.getLibPath('bem-bl', 'blocks-common/i-bem/bem/techs'),

    beautify = require('js-beautify').html;

exports.baseTechPath = join(BEMBL_TECHS, 'html.js');

exports.techMixin = {
    getCreateResult: function(path, suffix, vars) {
        // не вызывать js-beautify в production-режиме
        if (process.env.YENV === 'production') return this.__base.apply(this, arguments);

        return this.__base.apply(this, arguments)
            .then(function(html) {
                return beautify(html, { /* см. доступные опции https://www.npmjs.com/package/js-beautify#options */ });
            });
    }
};

ENB

Для ENB приводить полный листинг не буду. Все сводится к полному копипасту html-from-bemjson.js с добавлением вызова бьютифаера на 40 строке:

var html = bemhtml.BEMHTML.apply(json);

return process.env.YENV === 'production' ? html : require('js-beautify').html(html, { /* см. доступные опции https://www.npmjs.com/package/js-beautify#options */ });

Использование

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

• здесь для bem-tools
• и здесь для ENB.

PS: Не забываем установить сам модуль: npm i js-beautify --save.

Мне очень нравится идея deps.js т.к. позволяет описывать зависимости не большой простыней, а только там где они нужны. Да и сборку приложения можно организовать достаточно тонко.

Например создать бандл который собирает только js технологию. И при необходимости js можно подключать отдельно на нужную страницу в нужное время.

Существуют даже методы работы с файлами зависимостей, такие как merge BEM.decl.merge(), subtract BEM.decl.subtract()

Но вот опишу задачку. Есть у меня подгружаемые части для SPA. CSS генерится для них и подключаться в сборку главной страницы. HTML же создается шаблонизатором внутри JS файла.

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

При этом, блоки этих частей используют одни и те же JS блоки на 80%.

Соответственно есть идея вынести эти общие блоки так же как и CSS в сборку общего бандла.

И тут не хватает одной команды, которая выдаст общие блоки между несколькими файлами deps.js

Выкручиваясь в объяснениях при рассказе того, что происходит при сборке БЭМ. Нарисовал такую картинку:

bundle (начальная точка сборки) => deps.js (собираем граф) => bemdecl.js (линейная структура зависимостей) => сборка (конкатенация) => компиляция (преобразование типа less=>css)

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

app/
..css/
..../images
......logo.png
....app.css
..app.html

А собирает все обратно в блоки. При этом откровенно мешая работать над исходниками.

Пришлось написать пример с bem-tools + gulp

Где разделил понятия компиляция и сборка таким образом:

1. bem-tools компилирует файлы исходников в нужный вид раскидывая по папкам блоков
2. gulp собирает файлы из блоков в ожидаемую структуру.

Так, вот может быть стоит ввести в оборот "сборка/конкатенация файлов для компиляции", "компиляция", "сборка структуры".

Может станет понятнее новичкам?

На сегодняшний день разработка bem-tools заморожена. Подробнее об этом в заметке о статусе bem-tools, причины приведшие к такому положению вещей значение имеют второстепенную, вопрос в том что делать и как развиваться дальше.

В теме Визуальный генератор страницы из имеющихся блоков вплыл вопрос о "правлении" ENB в БЭМ-экосистеме, @zxqfox лаконично и не субъективно описал свой взгляд:

Названия технологий и их апи настолько разные, что убивают многое. У них нет зависимостей других технологий, которые стоило бы запилить. Конфиги больших проектов выглядят как какашка (см. bem-components и проекты с хакатона). Технологии жестко завязаны файловую систему и имена технологий — оба не критично, но имхо это не правильно. И это все не субъективно. Для 80% пользователей это так ;-)

1. Хочется услышать другие мнения.
2. Хочется разложить все по полочкам, а именно разложить по полочкам составляющие bem-tools и составляющие ENB.
3. Хочется понять какие есть варианты достижения счастья и консистентности.

Здравствуйте, друзья!

Простейший, казалось бы, вопрос, но через поиск ответ найти не могу.

Нашлась только эта http://clubs.ya.ru/bem/4080/ тема в клубах, я задал там вопрос, но не уверен в том, что тот сервис все еще работает, поэтому дублирую тут:

запускаю БЭМ-сервер и хотелось бы им аякс-запросы проксировать на бекенд (надоело использовать хром с опцией disable-web-security и костыль в коде), подскажите пожалуйста, можно ли это как-то настроить.

Всем привет. У меня не получается добиться от bem-server того, чтобы он каждый раз пересобирал итоговый html при обновлении страницы. Приходится отключать его и делать bem make, затем заново включать. Очень неудобно. Как можно заставить его делать это автоматом? Также если его запускать из корневой директории проекта, например start-pretty-project, а затем, по папкам перейти в директорию index, то можно обнаружить, что до css файла сгенерировался некорректный путь (без папки index). Если же в консоли запустить bem-server из папки index, то путь генерируется корректный и все отображается как надо. Как поправить? Ткните, плз, чтобы время не терять.

Привет! Подскажите есть в природе enb или bem-tools технологии для работы с графикой(jpg/png/svg). Например блок с фоновой картинкой(картинка лежит гдето в папке блока)

А кто-то использует subj?

Поделитесь как это использовать?

Я создаю несколько страниц командой bem create -l desktop.bundles -b about bem create -l desktop.bundles -b map

После выполнения bem make я получаю соответствующие css и js для каждой страницы, а как получить общий css и js для подключения на сайте?

И второй вопрос, на сколько я понял команда bem make не "минифицирует" js и css файлы?

P.S. за время написания данного текста, курсор раз 20 убегал в поле поиска, не удобно.

Пока @veged не закрыл песочницу, скажите, как лучше подключать плагины?

Вариант нумер 1 с ручным переопределением, доопределением некоего объекта BEM. Плагин выглядит так:

module.exports = function (BEM) {
  // пишем команду
  BEM.command.cmd()
    .opt()....end()
    .act(function () { ... });
  // работаем с внуренностями
  BEM.levelManager.get('somelevel').doSomething();
  BEM.techManager.get('uberstrings').makeMeHappy();
  // добавляем какой-то метод и объект
  BEM.mySpecialMethod = function ... ;
  BEM.superContainer = { ... };
};

Вариант нумер 2 с предоставлением интерфейса с ym. В этом случае можно даже зафризить объект, чтобы не было желания работать через "глобальный" объект BEM. Т.е. некий jail.

module.exports = function (BEM) {
  // отдаем объект coa, который подкоманда abc
  BEM.defineCmd('abc')
    // тут лучше оставить как есть, решение хорошее
    .opt()...end().act(...);
  // внутренности закрываем
  BEM.requireLevel(['somelevel'], function (somelevel) {
    somelevel.doSomething();
  });
  BEM.requireTech(['uberstrings'], function (uberstrings) {
    uberstrings.makeMeHappy();
  });
  // добавляем какой-то метод
  BEM.define('bem', function (provide, bem) {
    bem.mySpecialMethod = ...;
    bem.superContainer = { ... };
    provide(bem);
  });
};

Вариант нумер 3. Как 2, но через "промисы":

module.exports = function (BEM) {
  BEM.defineCmd...
  // fail навешиваем в BEM.requireLevel, если он не найдется.
  BEM.requireLevel('somelevel').thenCall('doSomething');
  BEM.requireTech('uberstrings').then(function (uberstrings) {
    uberstrings.makeMeBoring();
  });
  BEM // или просто define
    .defineProperty('mySpecialMethod', function ...)
    .defineProperty('...');
});

"Зачем нам этот огород?" — спросите вы. Все просто. Менеджер уровней и уровни, которые есть в bt1.0, предлагается спрятать в пакете bem-levels, допилить, и подключать как-то так:

module.exports = function (BEM) {
  require(level), require(levels), ...
  var levelManager = new ...
  BEM.define('levels', function () {
  });
  BEM.on('ready', function () {
    levelManager.cd( BEM.require('config').cwd() );
  });
}

Аналогичным образом, еще до bem-levels, подключится bem-config, и скажет, что он определяет config. За ними bem-deps, bem-make, build, decl, etc. Все эти команды должны иметь 1 понятный интерфейс, чтобы работать с бэм-предметной областью, а не js-объектами, методами, магией.

p.s. Мне кажется, тут всем нравится api у coa. Можно выкинуть пачку методов для каждого define*, примерно как в 3. Фактически, через плагины нужно будет работать с уровнями, технологиями, командами. Последние две можно описать тасками (или, как минимум, наследоваться от него). Таким образом, получится команда — coa, технология и уровень — какое-то api. Похожим образом сделано в enb: defineНечто(...).настройка1(...).настройка2(...).etc().

p.p.s. Призываю к голосованию потенциальных авторов команд, технологий, и других плюшек. Каждый голос важен!

Конспект встречи Арикона с Лешей Ярошевичем

bem-tools 2.0 — это модульная штука, где ядро — это небольшая программа, использующая COA и для которой можно писать библиотеки.

Все, что относится к командам и АПИ реализуется в виде АПИ.

Уже сейчас с командами сделано, так, что команды можно расширять. Это сделано за счет COA.

Текущее АПИ нужно выносить в отдельные модули. Все команды реализуются в виде отдельных пакетов с экспортируемой функцией, которая на вход получает определенный контекст.

Но как писать эти команды? Копипастить код из текущих bem-tools плохо, т.к. будет много копипаста. Так что нужно вынести куда-то общебэмовую функциональность:

• bem-config, который умеет читать common-js модуль. Когда программе нужна какая-то настройка, она дергает функцию из конфига (у нее зовется коллбек).
• Уровни (bem-levels)
  • чтение конфигов
  • интроспеция
  • создание уровня
• deps (bem-deps)
  • stub
  • parse
  • Deps
  • merge
  • intersect
  • substruct

Служебное низкоуровневое API (bem-util):

• map
• reduce
• translate
• create (new)

Build берет на вход декларацию (список) и технологию, а на выходе получается как правильно одна сущность — reduce (получает размеченный список сущности, у которых уже есть технология).

translate — это часть bem create, которая из одного файла технологии получает файл в новой технологии.

В bem-tools 2.0 хочется писать технологии не для команд bem create/ bem build, а технологии для сборки. Они будут работать по-разному в зависимости от необходимой собираемой технологии и вызывать внутри себя bem reduce, bem translate, etc.

bem-sets — это форк bem-pr, который отличается по интрефейсу, т.к. служебные библиотеки нужно подключать как npm-модули. Теперь bem-sets расширяются для сборки документации.

bem map — на входе несколько уровней и декларацию, а на выходе не одна сущность, а пачка значений. Пришедший набор в декларации возвращается таким же набором, но как-то трансформированным. Нарпимер, был были common.blocks + desktop.blocks и в результате examples собираются смерженными по специальным правилам.

taffyDB (?)

Пакет bem-tools по зависимостям тянет стандартные модули.

bem make будет отдельным пакетом.

https://github.com/bem/bem-tools/pull/502

// cc @zxqfox

https://github.com/bem/bem-tools/pull/271

// cc @arikon @zxqfox