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

Съезжают настройки sourcemaps для технологий bemhtml.js и browser.js. Глядя на старые проекты (где всё как-то работало), кое-как восстанавливаю для browser.js (перадчей параметров из конфига enb/make + патчем модулей enb-source-map, source-map), для bemhtml.js пока вообще не могу найти, куда крутить?

Хелп? Как это делается? Или у всех из коробки работает? А почему у меня -- никогда (теперь; кажется)?

Текущий проект бутстрапил на последнем bem/project-stub (месяц назад) перстаскивал библиотеки/патчи из старых проектов.

Попробовал на "чистом" project-stub -- при минимальных изменениях (меняем в index.bemjson.js подключение скрипта index.js на последовательные: index.bemhtml.js и index.browser.js) -- И достигаем такого же эффекта: sourcemaps подтягиваются для browser.js, для bemhtml.js перебрасывает совсем в другие места общего бандла. Чего/куда крутить?

UP: Глянул на старые проекты ещё раз: там sourcemaps от шаблонов были вообще откручны. Т.е., дебажимся уже в собранном бандле. Т.е., видимо, так и дальше надо. Вывод: отключаем все sourcemaps от технологии bemhtml вообще, раз так.

Собственно, ситуация довольно сложная и вряд ли что-то измениться от этого поста, но свободное время нужно куда-то конвертировать, пусть это будет небольшой рассказ.

Чуть более года назад связался с БЭМ, до этого что-то умел в плане вёрстки сайтов, но знания были сумбурные. Фреймворк связал эти знания в единое целое и позволил заниматься этим более профессионально, а также подтолкнул к изучению NodeJS и npm. Конечно, путь был довольно тернист и первое время порог входа в БЭМ был слишком высок, но всё-таки преодолеть его удалось.

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

Пожалуй именно БЭМ выступил катализатором моего обучения (привёл на Github в том числе) и позволил мне создать парочку сайтов на заказ (например), но также именно БЭМ сделал нечто плохое. В какой-то из статей Яндекса о БЭМе была фраза "сначала вы его отрицаете, потом не можете без него жить". И оказалось, что для рядового разработчика это не так уж и хорошо, так могло казаться вначале.

БЭМ штука довольно непопулярная, особенно если вы пытаетесь работать фрилансером. Порой часами приходилось объяснять горе-заказчикам что это за зверь и для чего нужен, а после полностью выполненной работы (простой лендинг) я получил деньги и отрицательный отзыв вроде "хотел немного стиль select поправить, а там куча непонятного CSS и длиннющие классы, а JS-код вообще огромен, что это?". И что теперь всех заказчиков-самоучек учить писать по БЭМ и развертывать среду разработки? Увы, получить БЭМ-фрилансеру адекватный заказ оказалось довольно сложно, так как у людей ещё Вордпресс в голове и PHP, перемешанный с HTML в одном файле.

Получается либо искать человека, который хочет сайт под ключ и ему плевать на чём этот сайт работает, либо отказываться от БЭМ и "приземляться" к народу на 5-6 лет назад. А кто-то ещё сталкивался с такой дилеммой?

P.S. Открыт к любым предложениям, связанным с БЭМ (ещё есть куда расти) P.P.S. Извините за многобукв :)

Всем привет! Запаситесь терпением, пожалуйста, но мне правда нужен совет Есть компоненты формы (select, input, textarea) Так вышло, что в зависимости от страницы у элементов меняется вид и я думал, все эти блоки разные (по типу функциональности), но группы элементов имеют одинаковый вид и я поступил так Создал блок form-element, единственное назначение которого быть миксином для стилизации групп сущностей, т.к. мне показалось странным создавать одинаковые стили для каждого компонента, DRY наше всё После этого я стал искать различия между элементами и вышло что-то невероятное

7 различных значений высоты компонента 7 различных значений размера шрифта компонента 5 различных значения bg, включая отсутствие bg 2 значения border-radius, 1 на 10px, другое на 16 Есть или нет рамки 2 значения толщины рамки 3 значения цвета рамки 3 разных значения расположения тени

Сидел, сидел и сЕдел и думал, как я "люблю" дизайнеров, но делать что-то нужно и создал я 5 модификаторов, а именно: form-elementboder(normal || bold) отвечающие только за толщину рамки form-elementrounded(md || lg) отвечающие за значения 10 и 16 form-elementshadow(md || lg), отвечающие за тень form-elementsize(много значений) отвечающие за высоту и размер шрифта form-elementtheme(много значений) отвечающие за цвет фона, цвет шрифта, цвет рамки

Создал отдельно блок input, в итоге код выглядит примерно так

<div class="
    input form-element
    form-element_theme_first
    form-element_size_md
    form-element_rounded_md
    form-element_border_normal
">
    <input type="text" class="input__field">
</div>


.input__field {
    padding: 0 16px;
    margin: 0;
    height: 100%;
    width: 100%;
    border: none;
    outline: none;
    background: none;
    color: inherit;
}

И всё было бы ничего, но пришло время создавать select, который сейчас выглядит так

<div class="
    select
    select_opened
    form-element
    form-element_theme_first
    form-element_size_md
    form-element_rounded_md
    form-element_border_normal
">
     <select name=""></select>
     <div class="select__header">
         <p class="select__value">Product</p>
         <span class="arrow arrow_bottom select__arrow"></span>
      </div>
      <ul class="select__body">
          <li class="select__option">Product</li>
          <li class="select__option">Product</li>
      </ul>
</div>

И здесь я понял, что мне конец, ведь в зависимости от модификаторов form-element, мне нужно менять элементы компонента select, а это неправильно, потому что будут селекторы вида .class .class, но хуже всего, что модификатор одного блока будет влиять на элементы другого блока, совсем не относящегося к нему. Что я имею ввиду, в зависимости от form-element_size_md должен меняться размер select__option, в зависимости от рамки добавляться или уходить она, также про border-radius, да вообще хоть про что, плюсом идут немного разные стили, когда select развернут. В итоге, я в тупике и не знаю как быть, мои варианты были такими, создать все компоненты отдельно select, input, textarea и тупо для каждого были бы свои модификаторы, НО они были бы идентичны, т.к. select_size_md, input_size_md, textarea_size_md означали одно и тоже, это плохо, одинаковые реализации. Дальше я подумал, а что если вынести select из всей этой кучи и добавить модификаторы для него, я получил бы что-то типа select_size_md для селектов и form-element_size_md для input и textarea, но тогда мы всё равно имеем 2 одинаковых реализации. Я бы мог написать их так select_size_md, form-element_size_md, но тогда смысла в создании form-element как отдельной сущности вообще не стало.

И вопросов у меня ровно 3 1) Правильно ли я разбил на модификаторы все различия между элементами, просто их вышло так много и они по 1 строчке почти все, что я сомневаюсь в правильности? 2) Как мне быть с особенностями select компонента (описанию проблемы отдана большая часть текста)? 3) Могу ли я использовать блок так

<div class="block">
    <div class="block__elem1"></div>
    <div class="block__elem2"></div>
</div>

.block {color: #fff; position: relative}
.block__elem1 {position: absolute; right: 0}
.block__elem2{position: absolute; left: 0}

А в другом месте так

<div class="block">
    <div class="block__elem1"></div>
</div>

То-есть, я могу написать хоть 100 стилей для элементов, а потом взять и в блоке только 1 элемент использовать, это нормально?

P.S. Возможно я не совсем корректно написал название вопроса, но моя голова кипит. Заранее спасибо

Есть эл-т NavBar-MenuItem, добавляем модификатор _hasSubmenu. Примерно так:

//...
import INavBarMenuItemProps from '../NavBar-MenuItem';
export interface INavBarMenuItemHasSubmenuProps extends INavBarMenuItemProps {
  hasSubmenu?: boolean;
  menu?: Array<{}>;
}
export default class NavBarMenuItemHasSubmenu<P extends INavBarMenuItemHasSubmenuProps> extends Elem<P> {
  public block = 'NavBar';
  public elem = 'MenuItem';
  public static mod = ({ hasSubmenu }: INavBarMenuItemHasSubmenuProps) => hasSubmenu === true;
  public elemMods() {
    const {hasSubmenu} = this.props;
    return {
      ...super.mods(),
      hasSubmenu,
    };
  }
  // ...
}

Пробовал по-разному, напр., NavBarMenuItemHasSubmenu extends Elem<INavBarMenuItemHasSubmenuProps>, ещё как-то.

При использовании в родительском эл-те ругается на отсутствие свойств в определении props у родительского или модифицированного элемента. Напр.:

[tsl] ERROR in .../src/blocks/NavBar/Menu/NavBar-Menu.tsx(138,15)
      TS2339: Property 'no' does not exist on type '(IntrinsicAttributes & ClassAttributes<{} | EntityProps<INavBarMenuItemHasMenuProps>> & IBemProps...'.

(no -- свойство расширяемого NavBar-MenuItem.)

В NavBar-Menu Делаем так:

// ...
import MenuItem from '../MenuItem/NavBar-MenuItem';
import hasMenu from '../MenuItem/_hasMenu/NavBar-MenuItem_hasMenu';
const MenuItemWithMods = withMods(MenuItem, hasMenu);
// ...
export default class NavBarMenu extends Elem<INavBarMenuProps, INavBarMenuState> {
  public block = 'NavBar';
  public elem = 'Menu';
  // ...
  public content() {
    const {menuItems, selectedNo, showDebugMsg, debugMsg} = this.state;
    return (
      <MuiMenuList classes={{root: this.block + '-MenuContainer'}}>
        {Array.isArray(menuItems) && menuItems.map(({id, text, menu}, no) => {
          const hasMenu = Array.isArray(menu);
          return (
            <MenuItemWithMods
              hasMenu={hasMenu}
              menu={menu}
              key={no}
              no={String(no)}
              selected={selectedNo === no}
              onClick={this.handleClick}
            >{text}</MenuItemWithMods>
          );
        }, this)}
      </MuiMenuList>
    );
  }
}

Как правильно дополнять описания пропсов для модификатора элемента?

В react'е пока "плаваю". Наверняка глупый вопрос:

Не могу найти способ "примешать" чужой компонент к своему. Т.е., задача в том, чтобы на одном DOM-узле находилось два компонента. Последняя конкретная ситуация:

Блок NavBar имеет элемент Menu, в который вложен набор элементов MenuItem. Использую Material-UI: в Menu вкладываю MuiMenuList, в MenuItem -- MuiMenuItem.

В итоге получаю такую структуру:

<div class="NavBar-Menu">
  <div class="MuiList...">
    <div class="NavBar-MenuItem">
      <div class="MuiListItem...">...</div>
    </div>
    <!-- ... -->
  </div>
</div>

Могу ли примешивать для NavBar-Menu и NavBar-MenuItem примешивать соотв. MuiMenuList и MuiMenuItem, вместо вкладывания чилдренов в методе content()?

Т.е., чтобы в итоге получалось:

<div class="NavBar-Menu MuiList...">
  <div class="NavBar-MenuItem MuiListItem...">...</div>
  <!-- ... -->
</div>

Как?

UPD: На всякий случай: приходило в голову пытаться как-то наследовать помимо Elem, ещё и от MUI-шного класса, но абсолютно не понимаю, как подсовывать нужные параметры. Сейчас это выглядит так:

export default class NavBarMenuItem extends Elem<INavBarMenuItemProps, INavBarMenuItemState> {
  public block = 'NavBar';
  public elem = 'MenuItem';
  public content() {
    return (
      <MuiMenuItem
        id={String(this.props.no)}
        selected={this.props.selected}
        onClick={this.props.onClick}
        classes={{
          root: `${this.block}-${this.elem}Mui`,
          selected: `${this.block}-${this.elem}Mui_selected`,
        }}
      >{this.props.children}</MuiMenuItem>
    );
  }
}

(MenuItemMui* -- Это, чтобы иметь возможность стилизовать создаваемый компонент.

Добрый день.
Решили верстку в своих проектах реализовать с помощью БЭМ, а потом и JS
Что есть сейчас - на бекенде единый движок с моделями и контроллерами, и есть несколько сайтов - шкур, там схема урлов, статика, шаблоны, все на Django
Что мне нужно - единая организация пока что верстки в проектах
Какие я вижу проблемы:

  • не пойму как организовать уровни переопределения, у нас есть несколько сайтов, у нас есть мобильная верстка (а она применяется не только если девайс мобильный, но и когда экран < 768px)
  • что делать если шаблон для мобильной версии очень сильно отличается от десктопной? сейчас в DOM есть копии с префиксом "m-", но мне это уже не особо нравится, это все усложняет шаблоны и верстку
  • не пойму как и чем сейчас собирают, сам я за webpack/gulp (может все же удастся образумить заказчика сделать домен m.* и тогда буду в разные бандлы собирать), есть примеры сборки БЭМ на этих утилитах?
  • как это все должно выглядить в шаблонах?
    • каждый блок - templatetag?
    • в какой структуре хранить на фс?
    • как будет выглядеть разметка страницы? одни include блоков с указанием типов? с удовольствием бы посмотрел примеры
  • очень хотелось бы получить ссылки на вебинары/туториалы от вас по подводным камням и БЭМ в проде, так сказать квинтэссенцию материалов по теме
  • как не наломать дров? =)
  • что делать с JS, сейчас там везде применен паттерн "модуль", делать все в прототипах(классах) и на уровнях переопределения наследованием рулить?

Спасибо, очень надеюсь на помощь, чтобы получить долгожданный порядок во фронтенде

Расскажите, как вы тестируете проекты на bem-react-core, как пишите юнит и интерграционные тесты, используете ли тестирование скриншотами. Если есть видео на эту тему - киньте ссылкой.

Есть микс для параграфа .paragraph. Он используется для параграфов в различных элементах, в том числе для элементов-параграфов в блоке .article. Однако в этом блоке необходимо добваить еще стили для параграфа.

Как я понимаю это будет реализовыватся как то так (с добавлением элемента .article__paragraph):

<div class="article">
  <div class="article__paragraph paragraph"></div>
</div>

Это явлется правильным?

Может ли микс иметь модификаторы?

Допустим у нас есть класс .link который задает стили для всех ссылок на странице, есть элемент .navbar__link который должен унаследовать стили от класса .link.

Как это правильно реализовать?

P.S. Тут написно как нужно: https://ru.bem.info/methodology/css/#Стилизация-групп-блоков

Не могу понять, как теперь правильно работать со стилями модификаторов. Смотрю на bem-react-boilerplate@0.1.0. Вижу два модификатора для <ExampleWithMods mod1 mod2 />. Имен классов, как привычно (<Example class="Example Example_mod1 Example_mod2">) не добавляются. Пробую добавлять вручную через mods (bem-react-core/REFERENCE.md - mods):

  public mods() {
    return {mod1: this.props.mod1};
  }

-- при этом отрабатывается только один вызов mods для всех модификаторов.

Как правильно?

Вообще, ткните, пож., в актуальные примеры кода/кейсы по bem-react-core?

Ситуация: при сборке в enb в bundle хочется подключать модули из исходного кода для использования в самом make.js и внутри .bemhtml шаблонов. Например, для получения общих параметров конфигурации или утилит вроде форматирования дат и пр.

В одном из прошлых проектов решал путём возврата промиса из bemjson, который разрешался после запроса нужных зависимостей (вручную, по списку). Кажется, было что-то приличное. Где-то когда-то видел что-то (почти, кажется?) готовое, но вот никак не могу найти. Хелп?

UP: Вижу что-то похожее в API / 8.x / Шаблоны (BEMHTML, BEMTREE) / Платформа / БЭМ - Подключение-сторонних-библиотек.

Пробую поключить ym-модуль project (находится в уровнях переопределения):

В make.js:

            // bemhtml
            [techs.bemhtml, {
                sourceSuffixes: ['bemhtml', 'bemhtml.js'],
                forceBaseTemplates: true,
                engineOptions : {
                    elemJsInstances : true,
                    requires : {
                        project : {
                            globals: 'project',
                            ym: 'project',
                        },
                    },
                },
            }],

В common.blocks/test/test.bemhtml:

    def()(function(){
        var project = this.require('project');
        console.log('in test.bemhtml', project);
        return applyNext();
    }),

Как результат, в консоль получаю undefined.

При этом вижу, что в бандл .benhtml.js записывается:

if (typeof modules === "object") {
  modules.define("project",["project"],function(provide, ymlib) {
    provide(ymlib);
  });
  modules.define("project",function(provide, prev) {
    provide(glob["project"] || prev);
  });
  modules.define("BEMHTML",["project"],function(provide,dep0) {
    var engine = buildBemXjst({"project":dep0});
    engine.libs = {"project":dep0};
    provide(engine);
  });
} else {
  var _libs = {};
  typeof glob["project"] !== "undefined" && (_libs["project"] = glob["project"]);
  if (Object.keys(_libs).length) {
    BEMHTML = buildBemXjst(_libs);
    exp["BEMHTML"] = BEMHTML;
    exp["BEMHTML"].libs = _libs;
  } else {
    BEMHTML= buildBemXjst(glob);
    exp["BEMHTML"] = BEMHTML;exp["BEMHTML"].libs = glob;
  }
}

-- Тут щас буду разбираться, куда оно в итоге девается.

Модуль project находится в base.blocks/project/project.js, в test.js (в рантайм) подключается вполне нормально, вот так:

modules.define('test', ['i-bem-dom', 'project'], function(provide, bemDom, project) {
provide(bemDom.declBlock(this.name, {
    onSetMod: {
        js: {
            inited: function() {
                console.log('project module', project);
            }
        }
    }
}));
});

Уровни переопределения задаются в .bemrc.js:

    levels: {
        'libs.blocks': { scheme : 'nested' },
        'base.blocks': { scheme : 'nested' },
        'common.blocks': { scheme : 'nested' },
        'desktop.blocks': { scheme : 'nested' },
        // 'pages': {},
    },

В make.js импортируются:

    srcLevels = Object.keys(require('../.bemrc.js').levels),

Версии:

$npm list enb enb-bemxjst
+-- enb@1.5.1
`-- enb-bemxjst@8.10.4

Всем привет,

Если у меня тэг <picture>, где есть несколько <source> и один <img>, всем ли элементам присваивать классы или можно присвоить класс только тэгу <picture>?

Заранее спасибо

Как правильно подговить верстку по БЭМу для использования на сайте, где контент-менеджер не использует классы для элементов (например, контент-менеджер публикует новости в блоге на сайте компании)?

Пример: я готовлю стили для блока .content и его потомков: .content h1, .content h2, .content h3, .content p, .content img. В таком случае элементы других блоков, внутри блока .content, переопределяются стилями для потомков .content, т.к. специфичность класса .content p - выше. Как правильно поступить?

Привет всем! Расскажите пожалуйста, как переопределить шаблон bem-create? просто кинуть в папочку .bem/templates/ bemhtml.js.js - магии не случилось. Так вот а как надо?)

Всем доброго! Есть форма, в ней есть как блоки input, так и блоки textarea. Можно ли получить методом findChildBlocks сразу все в одной коллекции?

<h1 class="heading-primary">
    <span class="heading-primary--main">Outdoors</span>
    <span class="heading-primary--sub">is where life happens</span>
</h1>
.heading-primary {
    color: #ffffff;
    text-transform: uppercase;
}

.heading-primary--main {
    font-size: 6rem;
}

.heading-primary--sub {
    font-size: 2rem;
}

Это - пример разметки и оформления блока-заголовка. Источник - англоязычный курс Advanced CSS and Sass авторства Jonas Schmedtmann.
Ссылка на репозиторий: https://github.com/jonasschmedtmann/advanced-css-course/blob/master/Natours/final-after-S06/index.html
Вопрос - этот пример использования модификаторов не противоречит общепринятым рекомендациям по БЭМ-наименованию селекторов? Возможно ли использование модификаторов в отрыве от модифицируемого блока\элемента при условии, аналогичном или близком по своей сути к коду выше?

Добрый вечер @tadatuta !

Помогите понять как правильно написать.

{
    elem: 'link',
    tag: 'li',
    content: [
        link.title,
        {
            block: 'modal',
            mods: { theme: 'islands', autoclosable: true },
            content: [
                {
                    block: 'card',
                    dataContent: {
                        title: link.title,
                        image: link.image,
                        text: link.text,
                        text_title: link.text_title,
                        check_list: link.check_list
                    }
                }
            ]
        },
    ]
}

Хотел открыть модал блок по клику на элемент линк и показать какой то карточный контент, но модал блок попадает куда то в корень. Как мне его потом ловить? Или как правильно обновить контент блок примерно в этой логике?

Добрый день) Подскажите дальнейший путь развития. Я понял саму методологию, научился верстать через bemjson, а дальше что...Если это шаблоны(BEMHTML,BEMTREE) то есть ли видео где более подробно про это рассказано?

@tadatuta Доброе время суток!

Не пойму в связи с чем получаю такую штуку

Uncaught Error: declMod with lazyInit prop not allowed. Your need use 'lazyInit' in data-bem params

Когда прикрепляют select блок

код блока { block: 'select', mods: { mode: 'radio', theme: 'islands', size: 'xl' }, name: 'auto', val: 1, options: [ { val: '1', text: 'BMW' } ] },

код зависимостей

({ shouldDeps: [ { elems: [ 'title' ] }, { block: 'input', mods: { theme: 'islands', 'has-clear': true, type: 'text', size: 'xl' } }, { block: 'textarea', mods: { theme: 'islands', size: 'xl' } }, { block: 'button', mods: { theme: 'islands', size: 'xl' } }, { block: 'select', mods: { mode: 'radio', theme: 'islands', size: 'xl' } }, ] })

в чем же тут дело?

Привет!

Мы сочинили пару новых пакетов:

  • bem-naming-transformations — низкоуровневый пакет про трансформации над инстансами BemEntityName. Грубо говоря, он позволяет из { block: ‘my-block’, elem: ‘some-elem’ } получить { block: ‘MyBlock’, elem: ‘SomeElem’ } и наоборот. Бонусом возможность добавить кастомный префикс блоку или задать свои собственные функции трансформации, где написать чего душе угодно.

  • postcss-css-to-bem-css — плагин для postcss, который можно запустить самостоятельно или внутри вашего любимого сборщика и превратить .my-block__some-elem { color: red } в .MyBlock-SomeElem { color: red; } (или наоборот) и использовать все прочие возможности предыдущего пакета.

Ставьте звезды и пользуйтесь во благо всех живых существ!

Сейчас посмотрел видео про БЭМ - очень понятно объясняется там же говорилось и про то что будет следующая лекция только уже где будут весь проект дорабатывать а именно подключать gulp. Как найти мне продолжение ?

Вот 1 часть. https://events.yandex.ru/lib/talks/2857/

В bem-components используется подход с использованием модификатора theme. У нас на проекте он тоже долго используется.

Простой пример на button https://github.com/bem/bem-components/blob/v6/design/common.blocks/button/_theme/button_theme_islands.post.css

Но, как показывает практика, он приносит некоторые раздувания стилей, особенно когда нужны только несколько модификаторов. И вообще проектные блоки часто без модификатора theme пишутся.

Но есть другой подход в виде уровней

common.blocks/
  button/

light.theme
  button/

dark.theme
  button/

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

При этом первый подход позволяет использовать несколько тем на одной странице (хотя не припомню, чтобы у нас больше одной было).

В общем... Кто какие подходы использует? А может кто-то их совмещает?

П.Н. Сейчас размышляю над плюсами/минусами для нас от второго подхода.

Т.к. все модификаторы блока образуют одну сущность, а выбор метода зависит от текущего модификатора, то можно писать вот такие кейсы.

const CartItem = bem.declBlock('CartItem', {
    delete() {
        console.log('Soft Delete')
    }
});

CartItem.declMod({ modName : 'obsolete' }, {
    delete() {
        console.log('Full Delete');
    }
});

cartItem = new CartItem();
cartItem.delete(); 

cartItem.setMod('obsolete');
cartItem.delete();

Результат в консоли

→ Soft Delete
→ Full Delete

Но возникает вопрос... На сколько архитектурно корректно использовать эти фичи? И использует ли кто-то их вообще?

Вроде удобно в runtime менять поведение блока в зависимости от модификатора, но с другой стороны не так явно выглядит.

@veged @tadatuta подскажите на сколько корректно использовать такой подход?

Приветствую всех!

Как могу смотрю, что происходит и появляется пару вопросов. Все идут в реакт или просто спрос рождает предложение? и когда сл. бемап?

Всем привет! Не получается обратиться к блоку text внутри блока categories. По аналогии с докой делаю:

modules.define('categories', ['i-bem-dom', 'text'], function(provide, bemDom, Text) { provide(bemDom.declBlock(this.name, {...})); });

На что получаю в консоли Error: Module "categories": can't resolve dependence "text". Если в исходном коде заменю 'text' на 'button', то ошибки нет. Помогите понять где не прав

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

web-jade@webjade-Aspire-TC-120:~/Documents/bemes$ yo bem-stub ? Enter your project name: bem-test ? Enter a name of the project owner: Nikita ? Enter an email of the project owner: web-kostrov@yandex.ru ? Choose a toolkit to build the project: ENB ? Specify additional libraries if needed: ? Choose redefinition levels to use: desktop ? Choose CSS preprocessor: Only pure CSS ? Do you want to use 'Autoprefixer'? No ? Choose technologies to be used in the project: BEMJSON, BEMTREE, browser.js ? Choose a template engine: BEMHTML ? Do you want to build static HTML? Yes ? Do you want to build 'tidy' HTML? No ? Choose types of files to be minimized: css, js create bem-test/.bowerrc create bem-test/.enb/make.js create bem-test/bower.json create bem-test/desktop.bundles/index/index.bemjson.js create bem-test/.gitignore create bem-test/package.json create bem-test/README.md

I'm all done. Running npm install for you to install the required dependencies. If this fails, try running the command yourself.

npm WARN deprecated enb-diverse-js@0.1.0: Use enb-js instead. npm WARN deprecated bem-xjst@1.2.1: v1.x is deprecated. Use v4.x or newer. See https://github.com/bem/bem-xjst/wiki/Migration-guides npm WARN deprecated coa@1.0.3: Please upgrade to 1.0.4 for node 0.10, 0.12, or to 2.0+ for node 4+ npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue npm WARN deprecated node-uuid@1.4.0: Use uuid module instead npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

bem-test@0.0.0 postinstall /home/web-jade/Documents/bemes/bem-test npm run deps

bem-test@0.0.0 deps /home/web-jade/Documents/bemes/bem-test bower install

bower bem-core#v2.8.0 cached https://github.com/bem/bem-core.git#2.8.0 bower bem-core#v2.8.0 validate 2.8.0 against https://github.com/bem/bem-core.git#v2.8.0 bower bem-core#v2.8.0 install bem-core#2.8.0

bem-core#2.8.0 libs/bem-core npm notice created a lockfile as package-lock.json. You should commit this file. npm WARN borschik-tech-cleancss@2.1.0 requires a peer of borschik@>=1.0.5 but none is installed. You must install peer dependencies yourself. npm WARN enb-modules@0.2.0 requires a peer of ym@~0.1.0 but none is installed. You must install peer dependencies yourself. npm WARN vow-node@0.3.0 requires a peer of vow@0.4.x but none is installed. You must install peer dependencies yourself.

added 295 packages from 273 contributors and audited 1111 packages in 19.615s found 41 vulnerabilities (25 low, 11 moderate, 4 high, 1 critical) run npm audit fix to fix them, or npm audit for details ✔ Done!

Привет.

Подскажите как правильно написать шаблон для элемента, который зависит от модификатора блока? Имеем:

{
    block: 'modal',
    mods: {
        theme: ['first', 'second']
    }
}

У этого блока есть елемент head, который должен иметь различную верстку в зависимости от темы модального окна. Единственный вариант, который пришел мне в голову это шаблон вида:

block('modal').mod('theme', 'first').elem('head')(
    ....
);

Но не работает. Зависимости указаны, стили приезжают, верстка не выводится.

Вопрос 2: Получается оба шаблона (для каждой темы) я должен написать в одном файле modal__head.bemtree.js? Или как-то можно разнести по разным файлам?

Есть ещё вариант писать шаблон в файле modal__head_theme_first.bemtree.js, но это неудобно, т.к. придется повторять модификатор темы для элемента head. Хм..

Добрый день. Немного разобравшись в структуре project-stub, передо мной встал простой вопрос. Нужно сделать запрос на какой-нибудь бэкенд и получить json с однотипными данными (элементами). Затем map-ом вставить кусок bemjson на основе полученных данных в bemjson.js бандла. Короче говоря динамически отрендерить какие-то однотипные элементы. Сам вопрос - где будет правильнее писать запрос и получение данных? Нормальным ли вариантом будет делать это непосредственно в коде страницы some-bundle.bemjson.js? Или есть лучший на ваш взгляд вариант. Спасибо)

Добрый день.

Блок header будет использоваться на всех страницах сайта. В бандлах, в файлах bemjson каждой страницы, кажется логично указывать только сам блок, и возможно модификаторы специфичные для этой страницы. Использую project stub.

например about.bemjson.js:

/...
content: [{
    block: 'header'
}]
/...

А в папке с блоком описать его структуру блока вместе с его элементами.

header.bemjson.js:

module.exports = [
    {
        block: 'link',
        mix: { block: 'header', elem: 'logo' },
        mods: {
            theme: 'islands',
            size: 'm'
        },
        url: 'https://bem.info/',
        content: 'bem.info'
    },
    {
        elem: 'nav'
    },
    {
        elem: 'sign-up-in-out'
    }
]

Но это не заработало. Посмотрел блоки из репозитария статьи создаём динамический БЭМ-проект там в некоторых папках с блоками, есть файл bemtree.js, вроде как решающий мою задачу.

в файле make.js раскомментировал строки с bemtree

bemtree.js:

block('header').content()(function() {
    return [
        {
            block: 'logo'
        },
        {
            elem: 'search-form'
        }
    ];
});

Сделал так же у себя, заменив содержимое на свое - тоже не заработало.

block('header').content()(function() {
    return [
      {
          block: 'link',
          mix: { block: 'header', elem: 'logo' },
          mods: {
              theme: 'islands',
              size: 'm'
          },
          url: 'https://bem.info/',
          content: 'bem.info'
      },
      {
          elem: 'nav'
      },
      {
          elem: 'sign-up-in-out'
      }
    ];
});

где я ошибся и что почитать, что бы больше так не делать?