Войти с помощью github

Код бандла index.bemjson.js выглядит следующим образом: index.bemjson.js

module.exports = {
    block: 'page',
    title: 'Title of the page',
    favicon: '/favicon.ico',
    head: [
        { elem: 'meta', attrs: { name: 'description', content: '' } },
        { elem: 'meta', attrs: { name: 'viewport', content: 'width=device-width, initial-scale=1' } },
        { elem: 'css', url: 'index.min.css' }
    ],
    scripts: [{ elem: 'js', url: 'index.min.js' }],
    mods: { theme: 'islands' },
    content: [
        {
            block: 'header',

        }
    ]
};

В блоке header, в файле header.deps.js я устанавливаю зависимость вида:

({

    shouldDeps: [
        {
            block: 'logo',
            mods: {theme: 'sea'}
        }
    ]
})

Соответственно блок лого существует, и у него прописаны стили. Но при сборке проекта блок header не содержит никакой вложенности. Соответственно вопрос: как добавить вложенность? Или это так не должно работать, и в любом случае в index.bemjson.js должен быть явно прописан блок внутри блока?

День добрый!

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

enbBemTechs = require('enb-bem-techs'),
    levels = [
        { path: 'node_modules/bem-core/common.blocks', check: false },
        { path: 'node_modules/bem-core/desktop.blocks', check: false },
        { path: 'node_modules/bem-components/common.blocks', check: false },
        { path: 'node_modules/bem-components/desktop.blocks', check: false },
        { path: 'node_modules/bem-components/design/common.blocks', check: false },
        { path: 'node_modules/bem-components/design/desktop.blocks', check: false },
        { path: 'node_modules/bem-font-awesome-icons', check: false },
        'common.blocks'
    ];

я так понял тут они и пишутся, только вот добавляю иконки а они чет не приезжают :)

вот зависимости

({
    mustDeps: [
        { block: 'icon' }
    ],
    shouldDeps: [
        { block: 'button', mods: { type: 'link' } },
        'link',
    ]
})

вот так я их зову

{
                block: 'button',
                mods: { theme: 'islands', size: 'm', type: 'link', disabled: item.disabled, view: item.view },
                text: item.name,
                url: item.url,
                icon : { block: 'icon', mods: { bg: 'adress-book' } }
}

где я не прав? или где почитать подробно?

Спасибо.

Добрый день!!

Не могу разобраться почему не подтягиваются зависимости задекларированные в Deps

В блоке: activities существует блок content-image с модификатором content-image_img_left

В файле activities.deps.js существует следующее содержимое:

([
    {
        shouldDeps: [
            {
                block: 'content-image',
                mods: { img: [
                        'left',
                        'right'
                    ]
                }
            }
        ]
    }
])

Пробовал по разному:

  1. Имя модификатора передавать строкой в Deps
  2. Модификаторы передавать массивом и прочим синтаксическим сахаром

залил проект в гитхаб Сборка ENB. При сборке Gulp - без деклараций работает, и по зависимостям (от блока) приходит то что надо. Хотя он и задекларирован только в index.bemjson

Пожалуйста помогите разобраться

Добрый! Есть таск

function less() {
  return bundler('*.bundles/*')
    .pipe(builder({
      less: bundle => {
        bundle.src('less')
          .pipe(gulpLess())
          .pipe(postcss([
            postcssImport(),
            postcssUrl({ url: 'inline' }),
            autoprefixer({browsers: prefixes}),
            postcssReporter()
          ]))
          .pipe(concat(bundle.name + '.min.css'))
          .pipe(gulpif(isProd, csso()))
      }
    }))
    .on('error', console.error)
    .pipe(debug())
    .pipe(gulp.dest(file => path.dirname(file.path)));
}

Крашится

TypeError: Cannot read property 'block' of undefined
    at data.forEach.dep (/home/arsen/dev/nodeprojects/njs_nian/node_modules/@bem/deps/lib/formats/deps.js/parser.js:29:37)
    at Array.forEach (native)
    at depsData.forEach.record (/home/arsen/dev/nodeprojects/njs_nian/node_modules/@bem/deps/lib/formats/deps.js/parser.js:27:14)
    at Array.forEach (native)
    at parse (/home/arsen/dev/nodeprojects/njs_nian/node_modules/@bem/deps/lib/formats/deps.js/parser.js:23:14)
    at Promise (/home/arsen/dev/nodeprojects/njs_nian/node_modules/@bem/deps/lib/parse.js:11:25)
    at /home/arsen/dev/nodeprojects/njs_nian/node_modules/@bem/deps/lib/parse.js:9:16

Есть каталог common.blocks в корне, там button, внутри .js файл, .browser.js, .less, .deps.js и Page, в нем те же технологии

Билдер

const builder = Builder({
  levels: [
    'common.blocks',
    'desktop.blocks'
  ],
  techMap: {
    bemhtml: ['bemhtml.js'],
    js: ['js'],
    less: ['less']
  }
});

Что я делаю не так? Хотелось бы поподробнее узнать о библиотеках

const Builder = require('gulp-bem-bundle-builder');
const bundler = require('gulp-bem-bundler-fs');

И можно ли с помощью них полноценно собирать БЭМ проекты на gulp?

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

Не нашёл никакого освещения проблемы. Иногда (часто) хочется иметь доступ к свойствам иконки через css. Наиболее оптимальный способ — использование <use> (с инлайном общего SVG-спрайта в body или обращение к самому файлу через xlink:href). Т. к. при сборке страницы мы получаем .deps.js, нельзя ли использовать это для получения списка иконок, которые «соберутся» в один спрайт? Есть ли подобная технология для enb?

В проекте есть часть системы (модель) с использованием организации файлов по БЭМ и YModules, которая не зависит от вью и могла бы загружаться асинхронно.

Вопрос, куда прописать зависимость бандла от блоков без DOM-представления модели?

Если прописать модель в BEMJSON виде пустого блока, то у блока page появляется зависимость от модели и асинхронной инициализации визуальных блоков внутри page не происходит.

Привет всем! Решил я почитать исходники технологии deps для enb. Нашел поддержку .yaml файлов. Но с какой то другой схемой описания зависимостей. в документации ничего не нашел. Хотелось бы узнать, для чего потребовалась новая схема описания зависимостей? Зачем использовать yaml - это понятно - меньше писать. но почему его нужно писать иначе чем deps.js?

Добрый день, Не могу понять в чем дело. Наверное, какая-то глупая ошибка. Я пытаюсь примиксовать стили к input и select в блоке qa-form.

.bemjson.js

        block: 'qa-form',
        url: "http://guk/api/feedback",
        content: [
            {
                elem: 'fields',
                content: [
                    {
                        block: 'input',
                        mods: {'has-clear': true},
                        name: 'flexibility'
                    },
                    {
                        block: 'select',
                        mods: {mode: 'radio'},
                        name: 'slenderness',
                        val: 1,
                        options: [
                            {val: 1, text: 'Report'},
                            {val: 2, text: 'Workshop'},
                            {val: 3, text: 'Round-table conference'}
                        ]
                    }
                ]
            }
        ]

qa-form.bemhtml.js

block('qa-form') ( js()(true),

tag()('form'),

block('input').mix()({  mods: {theme: 'islands', size: 'm'} }),
block('select').mix()({mods: { theme: 'islands', size: 'm'}}),

attrs()(function () {
    return {action: this.ctx.url};
})

);

qa-form.deps.js ({ mustDeps: [ {block: 'input', mods: {theme: 'islands', size: 'm'}}, {block: 'select', mods: {theme: 'islands', size: 'm'}}, ] })

В результате для input стили подключаются, а для select нет. Позже я понял, что внутри select есть блоки button и popup, для которых стили не подключаются. Если сделать так:

qa-form.bemhtml.js

block('qa-form') ( js()(true),

tag()('form'),

block('input').mix()({  mods: {theme: 'islands', size: 'm'} }),
block('select').mix()({mods: { theme: 'islands', size: 'm'}}),
block('button').mix()({mods: { theme: 'islands', size: 'm'}}),
block('popup').mix()({mods: { theme: 'islands', size: 'm'}}),

attrs()(function () {
    return {action: this.ctx.url};
})

);

qa-form.deps.js ({ mustDeps: [ {block: 'input', mods: {theme: 'islands', size: 'm'}}, {block: 'select', mods: {theme: 'islands', size: 'm'}}, {block: 'button', mods: {theme: 'islands', size: 'm'}}, {block: 'popup', mods: {theme: 'islands', size: 'm'}}, ] })

То стили подключаются и для select, но он не работает (кнопка не нажимается). Видимо почему-то js не подключается.. P.S. Извините, не понял как здесь правильно вставлять код, чтобы все было красиво.

Только начинаем внедрять, есть вопрос, почему зависимости из BEMJSON создаются автоматически, а в шаблоне -- нет. Есть какая-то идеологическая причина? Или это ограничение сборщика enb текущей версии?

Касательно стилей mustDeps - гарантированное нахождение блока до текущего; shouldDeps - просто включение в сборку

Нормальная ли практика - в *.deps.js файле блока указывать зависимости от его элементов и модификаторов?

Для того, чтобы подключать этот блок в депсах другого одной строкой { block: 'b1' }, а не перечислением всех необходимых модификаторов данного блока. И для того, чтобы неиспользуемые на песочнице модификаторы backend уже на свое усмотрение мог юзать.

Как то давно, мной был задан вопрос https://ru.bem.info/forum/793/ по реализации разделения css стилей и последующего их инлайна на html страницу.

Подход довольно простой.

  1. Собираем два разных бандла, первый critical, второй со всеми стилями.
  2. Превращаем файл critical.css в js файл, через инлайн файла module.exports = '....'
  3. Подключаем этот файл обычным require в виде элемента блока page {elem: 'css', content: require('desktop.bundles/critical/critical.css.js')}

В critical бандле подключается только один единственный блок critical (простите за каламбур) у которого в зависимостях описаны все блоки которые нужно заинлайнить.

Выложил выжимку своего конфига на enb https://gist.github.com/JiLiZART/efa6b23c478b17c4708b931a44fce996

Я использую bemtree, но для bemjson будет даже проще.

Есть у этого способа и недостатки, стили, которые инлайнятся в страницу, дублируются в бандле со всеми остальными стилями. Для решения этой проблемы я навоял вычитание deps'ов друг из друга в этом PR https://github.com/enb/enb-bem-techs/pull/190 Что поможет в дальнейшем вычитать все блоки critical бандла из основного

...
11:49:48.427 - [rebuild] [desktop.bundles\merged\merged.dirs] files
11:49:53.753 - [failed] [desktop.bundles\merged\merged.css] stylus
11:49:53.759 - [failed] [desktop.bundles\merged\_merged.css] borschik
11:49:53.759 - build failed
Error: D:\_my-work-tasks\project\desktop.bundles\merged\merged.css:21:14
   17| /* ../../template.blocks/header/header.styl:begin */
   18| @import "../../template.blocks/header/header.styl";
   19| /* ../../template.blocks/header/header.styl:end */
   20|
   21| /* ../../desktop.blocks/ico-location/ico-location.styl:begin */
--------------------^
   22| @import "../../desktop.blocks/ico-location/ico-location.styl";
   23| /* ../../desktop.blocks/ico-location/ico-location.styl:end */
   24|

Failed to @extend ".link"

    at D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\normalizer.js:406:17
    at Array.forEach (native)
    at Normalizer.extend (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\normalizer.js:402:17)
    at Normalizer.visitGroup (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\normalizer.js:279:8)
    at Normalizer.Visitor.visit (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\index.js:28:40)
    at Normalizer.visitBlock (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\normalizer.js:232:27)
    at Normalizer.Visitor.visit (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\index.js:28:40)
    at Normalizer.extend (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\normalizer.js:423:22)
    at Normalizer.visitGroup (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\normalizer.js:279:8)
    at Normalizer.Visitor.visit (D:\_my-work-tasks\project\node_modules\enb-stylus\node_modules\stylus\lib\visitor\index.js:28:40)

Похоже, что какой-то блок зависит от link (используется @extend ".link"), но в сборку link попадает позже

Вопросы:

  1. как (где) можно посмотреть файлы с @import?
  2. правильно ли я понял суть ошибки?

И ещё, понимаю, что торможу, но есть какой-то способ сохранять комментарии разработчика в итоговом файле css?

Добрый день! Внимательно прочитал всю доступную документацию в старом виде и в новом, несколько статей, посмотрел несколько вебинаров и лекций. Но некоторые моменты всё равно ускользнули от моего внимания и понимания. В целом эта непонятная ситуация причиняет мне физический дискомфорт. Боюсь, что для понимания многих вещей, придется просмотреть много кода, что бы найти примеры использования, а это камень в огород документации. Без ответа на эти вопросы, я буду плавать в методологии и не смогу ей воспользоваться.

Из документации я не понял:

1. Шаблонизация в браузере когда и зачем нужна? Я предполагаю, что весь HTML будет собираться на сервере, в том числе, что динамично будет отправляться клиенту. Но, коль есть возможность компилировать в браузере, хотелось бы узнать о плюсах и кейсах, когда это может понадобиться. Что, касательно ресурсов, насколько это ресурсозатратно?

2. Возможность частичной сборки и компиляции со статичными html файлами Многие элементы интерфейса - статичные, например, шапка, меню, футер, общие лейауты. Собирать их отдельно для каждого клиента - бессмысленно. Возможно ли как-то объединять уже собранный, статичный HTML и динамичные блоки?

3. Документация про сборку Я прочитал весь раздел про enb, но там скорее кейсы, чем сама архитектура. Мне непонятно, как организовать сборку для проекта в целом.

4. Как организовать сборку для дева, прода, лайв В продолжение предыдущего вопроса - для разработки и для прода требуются разные настройки. Я правильно понимаю, что разные настройки обеспечиваются разными файлами по типу make.js ?

5. Документация про декларацию Я не нашел цельной информации про декларацию (?.bemdecl.js), и всё, что я про это знаю - частички из статей про enb, из-за этого складывается ощущение, что я чего-то не догоняю.

_6. Почему и зачем есть BEMHTML и bh, какой для каких ситуаций лучше _ Я долго пытался понять - что делает bh, пока не понял, что это - еще один шаблонизатор, такой же, как BEMHTML. Так в чём же разница, и как так получилось, что есть два шаблонизатора? Какой из них под какие цели заточен? И, кстати, про bh нет документации.

_7. Где доки про BEMTREE, когда что лучше использовать _ Про BEMTREE лишь сказано, что синтаксис "Такой же, как в BEMHTML, но только с двумя режимами", при всём при том, что это - важный и основной инструмент при сборке. Очень хотелось бы увидеть примеры и объяснения, как делать шаблоны для BEMTREE.

8. Доки про SASS|LESS| любые модули Основной инструмент библиотеки для css - stylus, по историческим причинам. Хотелось бы узнать, как можно использовать другие препроцессоры. Я часто встречал мнение, что БЭМ - навязывает свой стек. Я понимаю, что это не так, просто инструменты дефолтные такие. Хотелось бы узнать, как можно в сборку включать те, что соответствуют моему стеку.

9. Контроллеры для сборки, практики BEM - штука хорошая, но кажется очень замкнутой в себе из-за того, что до конца не ясен сам процесс сборки и связь с внешним миром. Во всех статьях и гайдах говорится в-основном о статичных сайтах. И из-за этого, совсем мне не понятно, как сделать динамичный сайт, как организовать динамичную и частичную сборку, роутинг и т. д.

10. Шапка, лейаут в общем html Возможно, мой мозг еще не переключился в БЭМ-область, но мне до конца не ясно, как сделать общие части интерфейса для всех страниц сайта - каждый раз подключать header, content, footer?

11. Подключение скриптов, стилей, других библиотек. Если подключение своих скриптов, всё худо-бедно понять можно, то как подключить скрипты библиотек? Их ведь нужно указать в head (а некоторые скрипты в футере). Как же это всё делается в рамках шаблонов, страниц? Хардкодить?

12. Какие практики бандлов Из документации мне совсем не понятно что такое и для чего нужны бандлы. Как я понял - это собранные пакеты css и js, но куда их нужно пихать и зачем - непонятно.

13. Борщик Для чего борщик существует внутри enb, ведь в enb есть другие инструменты, для работы с файлами. В чем его отличие и назначение?

Возможно, многие вопросы очевидные или неправильно сформулированы, про неправильное пользование той или иной технологией. Каждый из этих вопросов - для меня важный, прошу, если вы знаете ответ или имеете мнение хоть по одному из них - не стесняйтесь.

На бэминаре я задавал вопрос, связанный с "картой" для bemtree, сейчас постараюсь его более конкретно расписать.

На файловой системе у нас блоки расположены на плоскости.

блок-1
блок-2
блок-3
...
блок-N

но при построении, плоская структура превращается в иерархическую.

BEMTREE | BEMJSON | HTML

Приходит новый разработчик... И хватается руками за голову. Ему необходимо перекопать проект (если он знаком с БЭМ), в поисках того, как всё устроено.

Но мы показываем ему картину мира: blocks И просмотр кода в браузере|bemtree становится понятным. При данном визуальном представлении можно абстрагироваться над всеми отвлекающими факторами (тегами, кавычками, скобками, bemjson) и видеть цельную картину из блоков.

CSS

Но вот наш новобранец решает что ему не нравится блок header, мысли у него локальные... Он и меняет стили блока header, думая про popup. Но мы говорим ему: "Стой друг! Мысли глобальней - возьми картину мира, картину мест использования данного блока (зависимостей независимых блоков)": blocks

Теперь разработчик оценивает масштабы и к изменением подходит более обдуманно.

JS

Ну и на последок он решился сделать свой блок и написать ему бизнес-логику для браузера. И мы ему опять таки говорим: "Дружище лови себе памятку по компонентам. Наследуйся от блоков, в них уже многое реализовано!" i-bem

Это всё абстракция и выдуманные примеры, но хочется сделать БЭМ ещё понятней для новых членов команды. Вот я и задавал вопрос, используются ли подобные подходы в Яндекс?

Использую новые депсы. Столкнулся с тем, что в некоторых случаях элементы блока идут раньше чем сам блок, хотя они описаны в shouldDeps. В чем может быть причина?

Просто интересно в чем может быть причина? В папке merged лежат скопированные бемдеклы бандлов (копируются при обходе бандлов проекта), при заходе на merged-бандл срабатывает эта функция

config.nodes('*.bundles/merged', function(nodeConfig) {
        var dir = path.dirname(nodeConfig.getPath()),
        bundles = fs.readdirSync(dir),
        bemdeclFiles = [];
        bundles.forEach(function (bundle) {
            if (bundle === 'merged' || bundle === '.bem') return;
            var node = path.join(dir, bundle),
            target = bundle + '.bemdecl.js';
            bemdeclFiles.push(target);
        });
        nodeConfig.addTechs([
            [enbBemTechs.mergeBemdecl,  { sources: bemdeclFiles }],
        ]);
        nodeConfig.addTarget( 'merged.bemdecl.js' );
    });

И выдает ошибку There is no tech for target desktop.bundles\merged\example.bemdecl.js Что не так? Заранее спасибо

Помоги пожалуйста .js ява скриптом, а именно с функцией