EN
webtehnology
webtehnology
19 января 2017

Всем привет!
Пользовался только css и проблем не было, но решил попробовать блок форм bem-forms.
При сборке enb все собирается на ура и формы отображаются как нужно, а вот если через gulp, то обычный css собирается нормально, а конструкции как ниже уже в сборку не попадают.

`.label {

    display: inline-block;

    font-weight: 600;

    padding-bottom: 5px;



    &_disabled {

        opacity: .5;

    }

}`
karalkou
karalkou
21 ноября 2016

Проект на базе project-stub.
Используются:

  1. bem-core v 3.0.1
  2. bem-components v 3.0.1
  3. enb

Около 100 страниц накопилось. Сборка идет около 30..70 с (30 000..70 000 мс)
Можно ли что-то подкрутить для увеличения скорости?

karalkou
karalkou
18 января 2017

Нашел на форуме в одной из тем ссылку на дифф

Не понимаю пока, как осуществляется связь между обычной сборкой и сборкой merged-bundle.

Как я понял, смысл в том, чтоб собрать в одной папке все bemdecl, слить их в один файл и получить общие стили и скрипты.
Привожу кусок из документации по процессу сборки

Процесс сборки

1. Какие таргеты необходимо билдить ENB узнаёт из команды enb make [target]. 
Если вы запустили enb make без указания конкретного таргета, 
ENB будет собирать все таргеты, определенные в make.js.
2. ENB инициализирует ноды, участвующие в сборке указанных таргетов. 
В это время каждая нода спрашивает у технологий 
(которые регистрировались внутри ноды) список таргетов.
3. Запускаются технологии, которые отвечают за те таргеты, которые необходимо билдить.
4. В процессе выполнения технология может потребовать у ноды другие таргеты, 
необходимые для сборки (с помощью метода requireSources). 
В таком случае технология приостанавливается, нода запускает технологии, 
отвечающие за требуемые таргеты (если они не запущены) и после того, как технологии
 заканчивают сборку нужных таргетов, продолжает свою работу искомая технология.
5. После того, как технология выполнила свою работу по сборке таргета, 
она оповещает об этом ноду (с помощью метода resolveTarget).
6. Сборка завершается после того, как все необходимые таргеты собраны.

В конфиге настраиваются ноды. В модуле '.enb/techs/merged.js' тоже настраивается нода.

...
merged(config, pathToMergedBundle); // в этом модуле исп-ся bemdecl-файлы страниц, но откуда они? Ведь их сборка идет ниже!
...

Не вижу связи между моментом сборки всех страниц (появление bemdecl-файлов) и сборки уже merged-bundle на их основе.

DjonyBastone
DjonyBastone
20 января 2017

Структура:

common.blocks/
    menu/
        __link/                                
            menu__link.css

Стили с этого элемента не приходят при сборке. Сборка Gulp, клон проекта - project-stub , конфигурацию gulpfile не трогал.

1) Сборка Gulp'ом должна производится при схеме Nested? Настроено ли это в project-stub?

2) Если должно собираться в чем может быть ошибка? Пожалуйста помогите разобраться. Ссылка на проект - https://github.com/DjonyBastone/osipbove-bem-project

DjonyBastone
DjonyBastone
19 января 2017

Платформа/Шаблоны (BEMHTML, BEMTREE)/Быстрый старт/online demo
https://bem.github.io/bem-xjst/

В результирующем коде должен быть элемент 'image'. Но его нет.
Пытаюсь повторить блок с логотипом на своем проекте. И не могу врубиться что не так с кодом.

Подскажите - в чем дело!?

vithar
vithar
23 сентября 2016

Часто можно слышать, что в БЭМ длинные имена классов и это ОЧЕНЬ плохо. Решил проверить, что будет, если все имена классов сделать одно-/двухбуквенными.

Сделал минимизированную версию упрощённой мобильной выдачи поиска Яндекса, над которой работаю сейчас.

Итоговый код можно посмотреть на Я.Диске:

  • search.orig.html — исходный HTML
  • search.mini.html — все классы заменены на одно/двухбуквенные классы
  • search.hack.html — все классы заменены на атрибуты: было <div class="l x">, стало <div l x>; в css соответственно .l и .x заменены на [l] и [x]

Без гзипа всё красиво:

30125  search.orig.html
26105  search.mini.html
24731  search.hack.html

gzip (стандартные настройки), бессердечная сука, разницу сильно нивелирует:

 8530  search.orig.html.gzip.gz
 8258  search.mini.html.gzip.gz
 8244  search.hack.html.gzip.gz

Разница между оригиналом и валидным минимизированным вариантом — 3.2%.
Между оригиналом и невалидным «хакерским» вариантом — 3.3%.

zopfli (стандартные настройки) нивелирует ещё сильнее:

 8136  search.orig.html.zopfli.gz
 7909  search.mini.html.zopfli.gz
 7921  search.hack.html.zopfli.gz

Разница между оригиналом и валидным минимизированным вариантом — 2.7%.
Между оригиналом и невалидным «хакерским» вариантом — 2.65%. Валидный вариант жмётся лучше «хакерского».

Итог: учитывая, что по сети информация передаётся пакетами (стандартный размер пакета TCP — 1500 байт), все эти файлы укладываются в 6 пакетов и в такой минимизации нет никакого смысла. Разве что хочется максимально запутать код.

bemdev
bemdev
18 января 2017

Привет помогите пожалуйста, почему я все никак не могу получить bemhtml на клиенте вроде все ок и зависимости и все позвал. и да такой вопрос если я все пишу через bemtree (ну как bemhtml у меня чисто для тегирования и атрибутов, то есть пока там только разная мелочь) и по сути у меня нет шаблона я просто хочу использовать сам шаблонизатор на клиенте, что я делаю не так?

modules.define('manager', ['i-bem__dom', 'BEMHTML', 'menu', 'jquery'], function(provide, BEMDOM, BEMHTML, MenuEvent, $) {

    provide(BEMDOM.decl(this.name, {
        onSetMod : {
          'js' : {
            'inited' : function() {
                MenuEvent.on('update', this._taskUpd, this);
            }
          }
        },
        _taskUpd : function () {

            this.setMod(this.elem('content'), 'action', 'artAdd');

            var bemjson = {
                block: 'content',
                content: [
                ]
            };

            var html = BEMHTML.apply(bemjson);

            console.log(html);

            BEMDOM.update(this.elem('content'), html);

            return false;
        }
    }));

});

зависимости

({
  shouldDeps: [
      { elem: 'control'},
      { elem: 'content'},
      { mods: { action: 'article'} },
    { block: 'modal', mods : { theme : 'islands', autoclosable : true }},
    'button',
    'content',
    'menu',
    { block: 'i-bem', elem: 'dom' },
    { tech: 'js', mustDeps: { elem: 'content', tech: 'bemhtml' } }
  ]
})
devvk
devvk
18 января 2017

Доброго времени суток. Подскажите пожалуйста кто знает, почему в bem-components и bem-core не используется SASS, а вместо этого все манипуляции над css совершаются с помощью JS? Чем обусловлен такой подход? Хочется очень услышать аргументы.

И небольшое пожелание по поводу ваших библиотек для BEM: запилите реализацию норм грида. Спасибо

RinatMullayanov
RinatMullayanov
7 декабря 2016

Ознакомился с материалами на https://ru.bem.info/, но не могу для себя прояснить ряд моментов, объясните пожалуйста:

  1. Где должен быть описан внешний вид блока (размер, цвет и т.д.): можно в css-классе блока писать или обязательно в модификаторе блока? Можно ли писать дефолтный внешний вид прямо в в css-классе блока?
  2. Где должен быть описан внешний вид элемента: можно в css-классе элемента или обязательно в модификаторе элемента? Можно ли писать дефолтный внешний вид прямо в в css-классе блока?
  3. В методологии указано: Блок не должен влиять на свое окружение, т. е. блоку не следует задавать внешнюю геометрию (в виде отступов, границ, влияющих на размеры) и позиционирование. А где тогда указывать свойства влияющие на позиционирование(position, display, float, margin и т.д.)?
  4. Все что касается позиционирования элемента я могу писать в css-классе элементе?
awinogradov
awinogradov
11 января 2017

Историческая справка

До недавнего времени мы работали над возможностью генерации Virtual DOM на основе BEMHTML-шаблонов. Мы разработали специальный движок для bem-xjst – xjst-ddsl, который может превращать шаблоны в некий DDSL, который с помощью дополнительного хелпера – ddsl-react превращался в React. Это было сделано для того, чтобы отделить специфику React и сделать закладку на тот случай, если захочется другую реализацию Virtual DOM. Об этом рассказывал я, например, на Я.Субботнике. Мы выдвинули и даже математически доказали гипотезу об эффективности этого метода, поскольку он позволял в 10 раз ускориться на сервере относительно нативного рендеринга на React, ведь на сервере мы можем использовать стандартный рендер в HTML, так как шаблоны одни.

Спустя некоторое время

Все это время мы делали подход в опенсоре – react-bl и внутри на реализацию компонентов для React на BEMHTML-шаблонах. Внутри мы попробовали очень большой объем компонентов, в том числе и составные/сложные с попапами и модальными окнами.

В чем разница открытой версии и внутренней?

В react-bl мы пробовали писать React-код для клиента "сверху" верстки и шаблонов, чтобы не трогать сами шаблоны и пробрасывать биндинги через пропсы компонентов. То есть получался "настоящий" React-компонент, где только разметка генерировалась с помощью BEMHTML. Такой подход нёс в себе несколько проблем. Во-первых, не работали уровни переопределения для клиентского кода, только для верстки в шаблонах. Во-вторых, добавлял иногда большие трудности при пробрасывании пропсов во вложенные элементы, тем более, если они строились динамически и имели вариативность.

Основываясь на этом опыте внутри мы попробовали писать клиентский код прямо в BEMHTML шаблонах. Например так:

block('link')(
   tag()('a'),
   js()(function() {
      return {
        onClick: () => console.log('hi there')
      };
   })
);

Это позволило решить проблемы с уровнями переопределения. И декларацией клиентского кода для вложенных элементов. Но... Нам пришлось добавить немного магии в ddsl-react (тот самый хелпер, что превращает DDSL в React). Мы добавили автоматический биндинг контекста. Ведь клиентский код в шаблонах ничего не знал про инстанс React-компонента и мы сделали это автоматически.

Кроме того, скорее всего вы спросите...

Как же было дело со вложенными компонентами?

Вопрос о том, что если кнопка использует иконку, а иконка тоже компонент? Ведь вызов иконки описан в BEMHTML и это просто BEMJSON, а не какой ни React-component. Мы решили эту проблему полуавтоматически: во время обьявления класса мы используем хелпер (ddsl-react), который первым аргументом принимает обьект с матчингом блоков на React-компоненты. Внутри во время рендера, когда встречается блок из матчинга он подменяется на React-компонент. Ведь разработчик знает, что за блоки используется в составном среди BEMHTML.

Что стало?

К сожалению, мы не учли несколько нюансов, и как мы ни пытались их обойти, сделать это эффективно у нас не получилось. А именно:

  • проблема автоматического биндинга контекста: это очень большая магия и возникают неоднозначности при обращении к элементам из блока или к другим элементам из элемента
  • проблема проставления refs, в 99% случаев все хорошо, но только не когда нужен ref на вложенный элемент в блоке, который вложен в другой блок
  • слишком строгие правила для написания шаблонов чтобы серверный рендер работал действительно быстро. То есть клиентский код должен быть вынесен в другой уровень относительно верстки и это надо учитывать в сборке. В противном случае среди рендера BEMHTML функции React по прежнему выполнялись, что сильно замедляло процесс

Всё прям плохо?

На самом деле нет. В 99% случаев решение работает и работает хорошо. Просто ожидаемый профит показался недостаточным. Нам хотелось быстрый рендер на сервере и удобное написание React-компонентов. Опытным и трезвым умом нам показалось что мы этого не достигли. Тем не менее использовать BEMHTML-шаблоны в React можно, но базировать на этом библиотеку с компонентами не стоит. Если у вас есть желание работать с этим решением, я с радостью помогу разобраться и раздам прав. Мейнетейнеры нынче в цене.

Что дальше?

Мы проверяем новую гипотезу в bem-react-core. Это очень маленькая по обьему библиотека, которая позволяет декларировать React-компоненты в BEMHTML подобном синтаксисе, писать на последнем стандарте, собираться чем угодно(webpack, gulp, rollap, babel), поддерживает уровни переопределения и все все, что мы так любим. В репозитории есть набор примеров, которые можно посмотреть и понять. Мы работаем над новым набором компонентов в bem-react-components. Внутри мы так же попробовали очень много компонентов и кажется все очень хорошо. У нас уже почти готова документация и скоро она появится в репозитории. И так же скоро появится поддержка i18n ;) Приходите с PR и хейтерством. Все что мы запланировали пока, кажется отражено в issues.

Код для привлечения внимания

ilyar
ilyar
31 июля 2016

@tadatuta рассказал как использовать , презентация.

~Осталось не понятно, как это использовать. Покажите минимальный кейс использования bem-lib-site и расскажите где читать про остальное.~

UPD

git clone git@github.com:ilyar/bem-lib-site-test.git
cd bem-lib-site-test && npm install
npm test
open docs/index.html

Работает, хак внутри (может быть он уже не нужен).
Сборку можно посмотреть тут ilyar.github.io/bem-lib-site-test/.

UPD 1/1/17

Убрал один хак https://github.com/ilyar/bem-lib-site-test/commit/a18e4849d46ed3ec370823080b204b3e14041877, добавил автотест генерации доки:

*nix status
windows Status

belozer
belozer
23 ноября 2016

Предыстория

По просьбам желающих выкидываю свой опыт внедрений gulp сборки в свой проект. До этого была связка gulp + enb. Всё работало, но как-то через костыли. Особенно с browserify (в блоках была технология .source.js, которая gulp'ом трансформировалась в .browser.source.js, а потом собиралась enb). Но вот я наткнулся на то, что gulp сборка уже есть в project-stub(bem-starter-kit //cc @tadatuta) и решил что пора перенастроить сборку проекта :)

На адаптацию gulp сборки под мой проект у меня ушёл вечер. Всё стало круто. Я избавился от кучи костылей, в частности связанных с синхронизацией перезагрузки сервера и browserify, с наличием 2 систем сборки в проекте.

Минусы

Что мне не понравилось, так это скорость сборки... К моему сожалению она уступает сборке с ENB пример в ~1.5-2 раза, но это только первые шаги gulp-bem ;) Дальше всё будет шустро. Не оказалось обёрток над BEMTREE и BEMHTML для YM из-коробки (но эта проблема оказалась легко решаема). Также наткнулся на баг(не кретичный), но его скоро профиксят.

Плюсы

  • одна система сборки
  • удобство внедрения
  • куча gulp плагинов в сети
  • pipe
  • более низкий порог вхождения, чем ENB
  • лёгкость подключения sourcemaps

Оптимизации/Ускорение/Рекомендации

Всё началось с того что мой gulpfile стал выглядеть так.
Меня очень напрягают длинные файлы с кодом и я задумался над оптимизацией процесса сборки.

Шаг 1. Пресеты

Я прям очень рад от идеи пресетов. Изначально я просто разбил модули по каталогам в своём проекте, чтобы не раздувать gulpfile. И подключал их... Но потом мне пришла идея, что это то, что нужно! Пресеты стали развитием моей идеи о стандартных конфигах для gulp сборки. Их основная идея в том, чтобы можно было с лёгкостью переносить конфиги из проекта в проект, без лишнего заграмаждения кодом. А также можно делиться своими пресетами ;) Так стал выглядеть мой gulpfile.

Свои наборы выложил на GitHub.

Шаг 2. Кэш

Меня стала очень сильно напрягать скорость пересборки проекта... ~7-8 секунд очень медлено. Но плагины gulp-cached и gulp-remember немного решили мою проблему. Скорость сборки увеличилась и стала занимать ~3-4 секунды (есть в пресетах browserjs и css начиная с версии 0.1.0).

Шаг 3. Разбивка бандла на таски.

Меня стало напрягать то, что при сохранении стилей пересобиравется весь bundle! И стили, и JS, и шаблоны... Пустая трата моего времени и реусурсов ноута. Разбил всё на несколько тасков и пересобираю только нужные части бандла. В результате скорость пресборки бандла увеличилась ещё больше и теперь занимает ~1.2сек, что уже становится весьма приемлемо. Текущий gulpfile также выложил на gist таким, какой он есть сейчас (не приглаживал).

Рекомендации по стилям

Не использовать глобальные переменные через блоки. Чтобы всё работало нормально нужно сконкатить все файлы, а потом только прогонять через процессоры... Это отрицительно сказывается на скорости сборки. Лучше в стилях явно использовать импорты. Тогда кэшировать можно каждый блок по отдельности + понятно откуда те или иные переменные (у меня на данный момент не так, из-за чего страдаю)

Пробуйте gulp-bem, он классный :)

DjonyBastone
DjonyBastone
15 января 2017

Добрый вечер.

В конфиге уровни определены:

const builder = Builder({
    levels: [
        'node_modules/bem-core/common.blocks',
        'node_modules/bem-core/desktop.blocks',
        'node_modules/bem-core/touch.blocks',
        'node_modules/bem-components/common.blocks',
        'node_modules/bem-components/desktop.blocks',
        'node_modules/bem-components/touch.blocks',
        // 'node_modules/bem-components/design/common.blocks',
        // 'node_modules/bem-components/design/desktop.blocks',
        'common.blocks',
        'desktop.blocks',
        'touch.blocks'
    ],

Вопросы:

1) Означает ли что с данной настройкой - desktop.bundles/index/index.html соберет в себя уровень touch ?

2) У меня собирает уровень touch для desktop. так и должно быть? Необходимо в конфиге закомментировать "не нужное" находящееся на одном уровне с "нужным"?

kompolom
kompolom
12 января 2017

Привет всем! Начал разбираться с bem-config. Крутецкая, между прочим, штуковина! Жаль, только примеров использования крайне мало.
Хотелось бы узнать, как предполагается использовать секции libs и levels?

DjonyBastone
DjonyBastone
14 января 2017

Клонирован шаблонный репозиторий - Project-stub, установлен ym

Команда - $ bem create desktop.bundles/page/page.bemjson.js создает пустой page.bemjson.js. В readme Project-stub говорится о начальном заполнении содержимым.

Как bem-tools дать понять, что необходимо *.bemjson.js заполнить содержимым, и где это содержимое найти?

По данному запросу найдены посты в архиве:
Перейти в архив

Сортировка

Метки