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

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

Хотелось бы увидеть, что то вроде блока dropdown из bem-components, но чтобы попап отображался при наведении, а не при клике.

Спасибо!

Есть ли пример как организовать приложение с использованием шаблонизаторов bemhtml или bh с bemhistory на клиенте? Цель реализовать проект одностраничного приложения польность по БЭМ методологии и с использование минимального количества внешних библиотек.

Практически у каждого разработчика есть своя библиотечка с блоками, пусть и не такая качественная, как bem-components. Было бы здорово собрать информацию о таких библиотеках, или даже отдельных блоках, в одном месте. Что думаете об этом?

Подскажите, пожалуйста. На своем проекте я настроил грант и хочу подключить в проект bem-core ради фрэймворка i-bem.js, и подключить bem-components ради блока дропдауна. Скажите, можно ли будет подключить эти библиотеки, не используя ваши сборщики? Просто отдельно подключить i-bem.js не хочу, хочу именно тот, который находится в bem-core т.к. хочу использовать ym модульную систему. В чем стал вопрос? В том, что у вас парадигма уровней переопределения и, если я подключу какую-нибудь библиотеку, а та в свою очередь переопределяет js библиотеки, которая находится на уровне переопределения ниже, то как это все подключить не используя вашего сборщика? Надеюсь, вы уловили суть вопроса, если что, я дополнительно поясню, спасибо.

Есть у кого-нить готовый слайдер контента, наподобие bxslider? Нашел блок b-slider в bem-bl на уровне touch-pad, На проекте используется bem-core и, я так понимаю, что блоки из bem-bl не будут корректно работать?

Леша @zxqfox, а следом и Коля @gruzzilkin интересуются, как начать разрабатывать свою БЭМ-библиотеку.

Ответ на этот вопрос может быть разным в зависимости от того, что вы вкладываете в этот термин.

Я попробовал рассмотреть создание библиотеки от простого к сложному, постепенно добавляя фичи.

А именно:

  • Самый простой вариант, когда библиотекой является просто папка с блоками
  • Разделение библиотеки по уровням переопределения
  • Вид библиотеки после добавления документации
  • Пример файловой структуры с тестами и линтерами
  • Оформление своей библиотеки

А в конце поделился рецептом, как быстро получить себе всю инфраструктуру, которую мы используем для bem-библиотек. TL;DR

Любая папка с блоками — библиотека

В самом простом случае любая папка, в которой лежат файлы с реализацией блоков, может служить библиотекой.

Например, вот так может выглядеть полезная библиотека с блоком clearfix:

my-library/
    clearfix/
        clearfix.css

Конечно, просто копировать ее из проекта в проект не очень удобно. Поэтому стоит воспользоваться любимой системой контроля версий и опубликовать библиотеку, скажем, на github. На проекты ее удобно будет доставлять через bower.

Получим:

my-library/
    .git/
    bower.json
    clearfix/
        clearfix.css

Теперь представим, что у нас в библиотеке появился блок ua, который будет помогать с feature detection.

Хозяйке на заметку: не стоит бояться класть в библиотеку блоки, которые не будут востребованы во всех ваших проектах, ведь сборщик соберет только нужные вам блоки в каждом конкретном проекте.

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

Самый простой — поступить по аналогии с clearfix и положить реализацию в соответствующую папку:

my-library/
    .git/
    bower.json
    clearfix/
        clearfix.css
    ua/
        ua.js

Однако, очевидно, что для разных платформ будут нужны разные данные. Например, на мобильном устройстве нас интересует ориентация устройства, для десктопа это знание не нужно. Тогда как часть информации о user agent будет нужна на всех платформах.

Как можно избежать дублирования кода и при этом не тянуть лишний код туда, где он заведомо не нужен?

Разделение блоков по уровням переопределения

Можно воспользоваться концепцией уровней переопределения. Это может выглядеть так: один блок представляем «слоями», а каждый новый слой до- переопределяет либо какую-то часть визуальных свойств, либо доопределяет поведение блока.

В результате структура библиотеки может выглядеть так:

my-library/
    .git/
    bower.json
    common.blocks/
        clearfix/
            clearfix.css
        ua/
            ua.js
    desktop.blocks/
        ua/
            ua.js
    touch.blocks/
        ua/
            ua.js

Мы видим, что блок ua оказался разделен на общую между всеми платформами часть (она попала в common.blocks) и специфику, необходимую в конкретном окружении.

Как это работает?

Сборщик знает, какие уровни переопределения и в каком порядке мы хотим собирать для нашего проекта. Поэтому код из последующих «слоев» сможет перекрыть предыдущий.

Нагляднее всего это можно продемонстрировать на примере с CSS:

/* my-library/common.blocks/b1 */
.b1 {
    width: 150px;
    height: 50px;
}

/* my-library/desktop.blocks/b1 */
.b1 {
    font-size: 24px;
    height: 80px;
}

Здесь некий блок b1 представлен на двух уровнях: common.blocks и desktop.blocks. При этом на общем уровне ему задаются высота и ширина, на уровне desktop.blocks добавляется знание про размер шрифта, а высота переопределяется новым значением.

Если писать код определенным образом, то аналогичного эффекта можно достичь и для остальных технологий, в т.ч. JavaScript и шаблонов. Например, мы используем i-bem.js и BEMHTML(https://ru.bem.info/technology/bemhtml/), чтобы упростить себе эту задачу.

Документируем блоки библиотеки

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

Получим что-то вроде:

my-library/
    .git/
    bower.json
    common.blocks/
        clearfix/
            clearfix.css
            clearfix.md
        ua/
            ua.js
            ua.md
    desktop.blocks/
        ua/
            ua.js
            ua.md
    touch.blocks/
        ua/
            ua.js
            ua.md
    README.md
    CHANGELOG.md

Тестируем и следим за кодстайлом

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

my-library/
    .csscomb.json
    .git/
    .githooks/
        pre-commit
    .jscsrc
    .jshint-groups.js
    .travis.yml
    bower.json
    common.blocks/
        clearfix/
            clearfix.css
            clearfix.md
        ua/
            ua.js
            ua.md
            ua.spec.js
    desktop.blocks/
        ua/
            ua.js
            ua.md
            ua.spec.js
    package.json # здесь задекларируем модули для сборки и тестирования
    touch.blocks/
        ua/
            ua.js
            ua.md
            ua.spec.js
    README.md
    CHANGELOG.md

Как мы оформляем bem-библиотеки

В какой-то момент для наглядного примера работы каждого блока во всей его вариативности может потребоваться демо-страница.

Я не случайно оставил за скобками всю историю про сборку таких примеров, тестов и документации по всем уровням переопределения.

Также не стоит ограничиваться unit-тестами для JavaScript, проверки требуют и шаблоны, и верстка. А для всех видов тестов в свою очередь потребуется анализ покрытия (coverage).

Для решения всех этих задач в БЭМ-платформе существуют готовые инструменты. Их достаточно много, и каждый требует какого-то времени, чтобы с ним разобраться.

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

TL;DR

Я бы предложил поступить примерно так:

git clone https://github.com/bem/bem-components.git my-library
cd $_
rm -rf *.blocks/* design

Теперь можно пользоваться ;)

Конечно, это не самый элегантный способ, но зато быстро и работает.

Мы думаем над тем, как облегчить получение готовой инфраструктуры для своей библиотеки. Решение видится в пакете-обертке над всем необходимым с удобным и лаконичным API.

Рассказывать о ней планируем в нашем блоге. Stay BEMed!

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

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

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

И откуда начинать работу? Конечно же, со спецификации: https://github.com/bem/bem-forms/blob/dev/BLOCKS.md

Хочется понять, какие хитрые кейсы есть у вас, какого рода формы вы делаете чаще всего, чтобы сконцентрироваться и на наиболее частых кейсах учесть максимальное кол-во требований.

Но можно и просто початиться с нами в Gitter, пожелать успехов в бою, и всего такого: https://gitter.im/bem/bem-forms

С новым годом! :christmas_tree:

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

1) не знаю насколько это покажется удобным, но, думаю, по крайне мере это интересно. Представим, что мы разработали библиотеку блоков, реализовали для каждого блока все его технологи(js, css, bemhml и т.д.). Все, библиотека готова. Вспоминая своё детство, помню, как любил играть в конструктор лего, из кучи разных деталек создавать что-угодно, собирая все в одну конструкцию. Вопрос заключается в следующем, может у вас реализован или в планах следующий механизм: открываем страницу в браузере, справа в панельке у нас отображаются визуально все имеющиеся блоки и мы, перетягивая их мышкой на страницу, создаем наш сайт. Перетянув один из блоков на страницу, в октрывшемся окошке мы задаем все нужные параметры для блока. Точно также перетягиваем нужные элементы блока. Затем нажимаем сохранить страницу и у нас автоматом генерится bemjson дерево нашей страницы. Разумеется, все это можно делать и вручную в bemjson файле, но от визуального создания страницы, как игра в лего, чтоли получаешь какое-то удовольствие, как в детстве, играя в лего, ну и плюс bemjson генерировался бы автоматом и люди, которые не особо сильны во всяких json и т.д. смогли бы делать свои странички не погружаясь в дебри bemjson, i-bem и т.д.

2) хочется сделать следующее приложение: загрузилась страница в браузер. Далее после каких-либо пользовательских действий перезагружается какая-либо часть страницы, данные для которой подгружаются ajax-ом. В этих пришедших данных находятся новые блоки, которых не было изначально на странице. Скажите, есть ли у вас механизм, который бы позволил на клиенте отслеживать какие новые блоки нужно вставить в страницу и который бы запрашивал с сервера для этих блоков css, js и bemhtml шаблоны, возвращая все эти данные в одном бандле, например, в json формате, а на клиенте бы эти данные вставлялись бы на страницу и только после этого бы вставлялся html новых блоков на страницу? В этом докладке https://events.yandex.ru/lib/talks/1413/ на 39:26 парень спрашивает именно то, о чем я написал. В ответе прозвучало про технологию, которая у вас есть с участием динамического сервера, но говорится, что она не в опен сорсе. Скажите, за год что-нибудь изменилось в плане этой технологии динамической подгрузки всех технологий блока?

3) уже около месяца в свободное от работы время читаю/изучаю все технологии бэм, плюс пересмотрел не один десяток видео с различных ваших конференций и теперь, имея хорошее представление, наконец готов начать писать свой мини проект ради практики БЭМ, но увидев об анонсе bem-core 3, желание начинать что-то кодить на текущей версии подостыло. Скажите, пожалуйста, когда планируете выпустить версию 3?

4) уже ни раз в различных видео упоминалось о библиотеке bem-components и о том, что люди пишут свои библиотеки, которые можно использовать в своих проектах. Скажите, а где можно скачать/увидеть сторонние, написанные не вами библиотеки блоков? Все старания по поиску таковых в гугле с использованием ключевого запроса "БЭМ библиотеки блоков" ведут сугубо на bem.info и, в частности, на страницы с библиотеками bem-core и bem-components.

Кончились дни, когда вам нужно делать проксирование или запускать несчастную ноду для сборки страничек. Теперь это можно делать прямо в пхпшечке!

Пакет bem/bh

Делается это посредством bh.php шаблонов (почти 100% клон bh.js). Вы скажите, но кому он нужен? Ведь в bem-core и bem-components нет шаблонов для блоков? Не отчаивайтесь — PR уже стоят! И в bem-components тоже.

Огромное спасибо @tadatuda за настройку project-stub, где он создал технологий и подключил нужные веточки bem-core и bem-components, да и вообще за идеи и поддержку — project-stub + php-bem-bh. Для запуска дополнительно нужно будет поставить сам пакет в vendor/php-bem-bh (исторически так вышло, что тестовый стаб работает с php-bem-bh, когда как через composer пакет ставится в vendor/bem/bh). Здесь можно собрать index.bh.php, который при запуске выдаст переменную $bh с готовый к использованию шаблонизатором. Оптимизаций по сборке блоков в один файл пока не делалось, но если вам очень хочется, то можно допилить технологии, чтобы сборка была разной в зависимости от откружения.

От комьюнити хочется больше идей, чтобы выработать какое-то универсальное решение. Кроме того, шаблоны только 2 дня назад увидели свет и багов там немеряно, особенно в bem-components, если найдете чего — чирканите пару строчек. Спасибо ;-)

Делаю комментарии к текстовым блокам как на медиуме Использовал блок dropdown в котором popup как то так

{
    block : 'dropdown',
    mods : { switcher : 'link' },
    switcher : {
        block : 'comments-counter',
        mix : { block : 'link', mods : { pseudo : true }},
        comments : 'ololo'
    },
    popup : {
        block : 'popup',
        mods : { theme : 'comments' },
        directions : ['right-top'],
        mainOffset : 17,
        secondaryOffset : -15,
        viewportOffset : 20,
        content : 'комментарии'
    }
}

Мне нужно двинуть body в лево при нажатии на переключатель. Сдвиг делается через css добавлением к body класса. Открывается popup, все вроде бы хорошо, но после анимации сдвига и скрола мышкой popup почему то пересчитывает свою позицию не правильно.

Вот видео баги https://yadi.sk/i/RXsm_X0ycpgfn

И видео если не двигать body https://yadi.sk/i/0-hxIvVtcpqKh

В какую строну смотреть? Помогите.

Проблема невероятно чудесная. Вот здесь https://github.com/verybigman/bem-grid/blob/8218ef38503fc224219788692e7ddcd965f6428e/common.blocks/row/row.deps.js подключаю как зависимость по технологии bemhtml блоки i-bem и row. Ожидается, что шаблон row попадет в бандл с browser.js. Но не все так просто. При запуске в браузере получаю ошибку: Uncaught Error: Module "row": can't resolve dependence "BEMHTML", тесты проходят безупречно. Почему в фантоме все ок, а в живом браузере нет? Народ, помогите, я спать не могу из-за этого. Сбросить кэш не предлагать. Подключать bemhtml.js тоже не true. Сборщик bem-tools.

Предлагается написать блок для реализации сетки. Блок должен учитывать сетку из проектов Яндекса в новом дизайне, использующих bem-components. Я предлагаю взять для начала сетку реализованную мной тут. Это фактически порезанный порт сетки из Foundation. А затем следующей версией внедрить поддержку flexbox, чтобы можно было поддерживать старые браузеры. @tadatuta предлагал писать сразу, используя flexbox, а старые ie поддерживать отедльным css. Все заинтересованные лица приглашаются к обсуждению.