2-4 июля в Яндексе проходил внутренний хакатон по БЭМ-инструментам. Наша команда занималась не совсем обычной задачей - сделать БЭМ-инфраструктуру для платформы .NET (ASP.NET MVC). Хотя это и нельзя будет использовать в Яндексе (в связи с отсутствием веб-проектов на .NET), задача кажется важной, т.к. без этого многие люди не могут использовать БЭМ.

Для возможности использования БЭМ-инструментов на .NET нужно две вещи:

1. написать .NET библиотеку для BEMHTML-шаблонизации на стороне сервера
2. сделать что-то вроде project-stub для .NET проектов - заготову файловой структуры проекта и преднастроенную сборку БЭМ-бандлов.

Для серверной шаблонизации мы использовали библиотеку edgejs, с помощью которой внутри .NET процесса запускается node.js и для шаблонизации используется полноценный bem-xjst. Это круто, потому что на сервере можно использовать те же самые шаблоны, что и на клиенте. Для сборки бандлов мы использовали enb, а распространять всё это планировали с помощью менеджера пакетов NuGet.

Задачи на хакатон

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

Отладка шаблонов

Самой сложной оказалась часть с отладкой шаблонов - к сожалению, эту задачу решить не получилось. Мы попробовали использовать в качестве отладчика Visual Studio и Node Inspector. В Visual Studio получилось остановиться в нужном месте и даже видеть значения переменных, но при этом не показывался исходный код. При подключении через Node Inspector возникала странная, абсолютно не информативная ошибка. Несмотря на неудачу и скудную документацию про отладку в EDGE.js, мы не оставим этот вопрос и обязательно что-нибудь придумаем.

Тестирование производительности

Помимо отладки, мы попробовали померить производительность серверной шаблонизации. Интересно было сравнить шаблонизацию BEMHTML на .NET с JavaScript реализацией и с шаблонами на Razor. В качестве тестовых данных использовали объект с 3 уровнями вложенности: корневой объект → внутри 100 групп → внутри каждой группы 3 элемента (вот полный json). Тестовые шаблоны должны были вывести корневой элемент как div, группы как ul и элементы групп в тэге li. Вы можете посмотреть шаблоны для BEMHTML и шаблоны для Razor. Во время тестов шаблонизацию запускали 1000 раз подряд. Результаты:

• самый быстрый - Razor (~380ms),
• BEMHTML в 6 раз медленнее (~2300ms)
• BEMHTML, запускаемый через .NET - еще в 1.5 раза медленнее (~3500ms)

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

Демо-приложение

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

Результат можете посмотреть по адресу http://bemtest.ecm7.ru, исходный код - здесь. Пример демонстрирует основные моменты: серверную шаблонизацию, отправку данных формы на бэкенд, подключение bem-components.

Релиз

И, наконец, последняя по порядку, но не по важности задача - выпустить релизную версию пакета. За время хакатона мы сделали много мелких доработок, исправили несколько багов, переписали неудобные места и написали документацию (почитайте, вроде классно получилось). В результате мы опубликовали новую версию в NuGet и её уже можно попробовать!

Команда

В заключение скажу пару слов о нашей команде. Если честно, я не был уверен, что эта тема интересна кому-то, кроме меня (всё же задача, мягко говоря, необычная для Яндекса). Но, несмотря на это, у нас собралась отличная команда: Костя Гладких, Саша Потапенко и Рома Ширин. Костя занимался тестами производительности и отладкой шаблонов, Рома и Саша писали демо-приложение, а я помогал Косте с тестами и писал документацию. Ребята, я вам очень благодарен за то, что поддержали меня. Вы очень круты!

Что дальше?

Конечно же на этом мы останавливаться не собираемся. В ближайших планах:

• разобраться с отладкой;
• перевести хелп на английский;
• причесать демо-приложение: сделать верстку формы поприятнее и выпилить лишние стили со страницы визитки, написать readme с кратким пояснением, что где смотреть;
• написать пост на хабр и, вообще, рассказать про эту штуку другими способами.

Спасибо за внимание!

Задача научиться рендерить Virtual DOM из текущих шаблонов на bemhtml

Состав команды: @nik-kor @amel-true @khvostov @voischev @awinogradov. Все супер котаны!)

Результат

1. Написали движок для рендера bemhtml шаблонов и положили аккуратно в PR https://github.com/bem/bem-xjst/pull/235. Экспортит атрибуты в виде массива вида ['div', {...attrs}, content, ...anotherContent].
2. Сделали адаптер для React https://github.com/bem-contrib/react-xjst, который использует бандл из шаблонов в bemhtml и инстанс React для создания Virtual DOM , с помощью библиотеки react-dom.
3. Начали доставлять bem-components в React, используя bemhtml шаблоны и стили. Собирается с помощью Webpack и специального лоадера для него https://github.com/alfa-bank-dev/bem-loader, который резолвит все нужное по депсам через bem-deps. Можно дописывать bemhtml шаблоны на уровне проекта как и раньше;)
4. Запилили песочницу для bem-xjst с переключателем движков: BEMHTML, BEMTREE, VIDOM – https://github.com/bem/bem-xjst/pull/238. Одни шаблоны на все времена, тестить, сравнивать, все, что душе угодно можно делать.
5. Так же планировали поработать над интеграцией с Redux. Но так сложилось, что задача решилась автоматически. На уровне React ничего не изменилось, поэтому данные как и раньше доезжают до компонентов, где формируется bemjson для функции рендера.

Превью готовых компонентов http://awinogradov.github.io/react-xjst-example/ и песочницы http://vladkhvo.github.io/.

Далее

Зарелизить react-components – библиотеку, которая использует шаблоны и стили из bem-components, но логику React в БЭМ-терминах.

Ура?;) Теперь мы имеем одни шаблоны и стили для параллельных стеков. Поддерживаем в одном месте и в ус не дуем! Предположительно можно написать подобных адаптеров и для других технологий;)

Вот в этом посте о результатах хакатона по инструментам сборки, Виталя упоминал созданный нами инструмент bem-tools-find.

Спешу сообщить, что мне удалось довести этот инструмент до того состояния в котором его не стыдно показать BEM сообществу.

• Написаны тесты
• Есть CI
• Есть достаточный объем документации по использованию этого инструмента

В конце концов выпущена версия 0.0.1 пакета bem-tools-find.

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

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

Со мной в команде были Сергей Бережной, Вадим Яловенко , Алексей Хлебаев и Александр Потапенко.

В мире JS и CSS написано достаточное количество линтеров кода, которые делают нашу разработку более удобной и надежной, но до сих пор не было реализовано ни одного линтера, который что-то знает про БЭМ.

И вот это послужило основной причиной для написания БЭМ-линтера, который из коробки знает про специфику БЭМ-проектов.

За несколько дней на хакатоне мы реализовали ядро линтера – bemhint, предоставляющее API для написания внешних плагинов, через которые реализуются проверки БЭМ-сущностей проекта.

Реализованные плагины:

1.Два плагина, которые позволяют интегрировать jshint и jscs в БЭМ-проект через bemhint:

• bemhint-plugins-jshint
• bemhint-plugins-jscs

Эти два плагина позволяют через конфиг bemhint-а конфигурировать и запускать соответственно jshint и jscs. Зачем? Ответ очень прост: jshint и jscs не дают возможности написать отдельный конфиг для проверки, например, *.deps.js-файлов и отдельный конфиг для проверки *.js-файлов. В свою очередь bemhint предоставляет возможность конфигурировать не маски файлов, а технологии, то есть в данном случае технологии deps.js и js.

2.Плагин для проверки ненужных технологий в проекте – bemhint-plugins-redundant-techs.

Плагин будет полезен для тех проектов, которые мигрируют с одной технологии на другую, например, bemhtml → bemhtml.js или css → styl.

3.Плагин, который умеет проверять наличие неправильных селекторов в технологии styl – bemhint-plugins-check-file-entity (у плагина появилась документация, поэтому подробнее можно почитать на github).

Мы создали тестовый репозиторий bemhint-test-prj, который демонстрирует работу bemhint и выше описанных плагинов.

В конце хочу поблагодарить всех ребят из нашей команды и организаторов хакатона. Было очень интересно :)

Привет, пришла и моя очередь рассказать о содеянном на минувшем хакатоне.

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

Несмотря на невнятную речь, ко мне присоединились очень крутые ребята, без которых мы бы не продвинулись так далеко: @arikon, @zxqfox, @awinogradov, спасибо вам огромное!

Ставь задачу правильно

Утверждение «сборка БЭМ-проектов с помощью любого инструмента» звучит слишком абстрактно.

В двухдневный формат хакатона такая задача совсем не укладывалась. Надо было сформулировать что-то более конкретное. Поэтому мы решили, что критерием успеха будет сборка project-stub с помощью gulp.

Сам gulp был выбран практически случайно. Важно было доказать гипотезу о сборке с помощью любого инструмента. На эту роль gulp подходит как нельзя лучше: он популярен, прост, да и ребята из соседней команды уже решили делать сборку с помощью webpack.

Готовь сани летом

На самом деле основная работа была сделана заранее.

Специфика сборки БЭМ проектов заключается в организации уровней переопределения и использовании зависимостей блоков. Подробнее об этом можно почитать на bem.info.

Необходимость модульной сборки была сформулирована уже давно. На прошлогоднем хакатоне мы решили задачу интроспекции уровней — bem-walk.

Кроме того, к этому хакатону я написал прототип модуля для работы с зависимостями блоков — bem-deps.

Работа оказалась проделанной не зря. Модуль для работы с зависимостями пригодился не только нам, но и команде, занимающейся сборкой с помощью webpack. А интроспекция и вовсе оказалась нужна каждой команде.

Результаты

Проект: @bem/gulp.

Сборка project-stub: ветка feature/gulp

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

import gulp from 'gulp';
import bem from '@bem/gulp';
import concat from 'gulp-concat';
import merge from 'gulp-merge';
import bemhtml from 'gulp-bemhtml';
import stylus from 'gulp-stylus';
import postcss from 'gulp-postcss';
import postcssUrl from 'postcss-url';

// Создаём хелпер для сборки проекта
var project = bem({
    bemconfig: {
        /* загружаем информацию об уровнях с помощью `bem-config` */ 
    }
});

// Создаём хелпер для сборки бандла
var bundle = project.bundle({
    path: 'desktop.bundles/index',
    declPath: 'index.bemdecl.js'
});

gulp.task('css', function () {
    return bundle.src({tech: 'css', extensions: ['.css', '.styl']})
        .pipe(stylus())            
        .pipe(postcss([
            postcssUrl({ url: 'inline' })            
        ]))
        .pipe(concat(`${bundle.name()}.css`))
        .pipe(gulp.dest('desktop.bundles/index'));
});

gulp.task('js', function () {
    return
        merge(
            gulp.src(require.resolve('ym')),
            bundle.src({ tech: 'js', extensions: ['.js', '.vanilla.js', '.browser.js'] })
        )
        .pipe(concat(`${bundle.name()}.js`))
        .pipe(gulp.dest('desktop.bundles/index'));
});

gulp.task('bemhtml', function () {
    return bundle.src({ tech: 'bemhtml.js', extensions: ['.bemhtml.js', '.bemhtml'] })
        .pipe(concat(`${bundle.name()}.bemhtml.js`))            
        .pipe(bemhtml())
        .pipe(gulp.dest('desktop.bundles/index'));
});

gulp.task('build', gulp.series('css', 'js', 'bemhtml'));
gulp.task('default', gulp.series('build'));

По скорости в текущем состоянии сборка project-stub оказалась соизмеримой со сборкой на стеке ENB.

Что дальше?

Вначале мы приведём код в человеческий вид, покроем тестами и напишем примеры использования с минимальной документацией.

Мы уже получили массу пожеланий и предложений, которые обязательно учтём.

Как только всё будет готово, обязательно расскажем вам. А самое главное — будем внедрять в реальные проекты и реагировать на фидбэк.

Общие модули bem-walk и bem-deps оказались универсальными, и в каком-то смысле уже проверенными в бою. Поэтому, кроме использования их для сборки на gulp и webpack, мы планируем внедрить их в ENB.

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

Присылайте свои идеи и задавайте вопросы на форуме или в ишьюсах к репозиториям из организации gulp-bem.

Спасибо за внимание!

12-13 декабря у нас был хакатон по разработке инструментов БЭМ. Я участвовал в команде переосмысления и разработки прототипа bem-tools, напишу, что у нас получилось.

В нашей команде было 6 человек:

• Вова Гриненко (ментор команды)
• Виталий Харисов
• Андрей Кузнецов
• Илья Исупов
• Ваня Воищев
• Миша Баранов

Решили, что bem-tools надо делать по архитектуре «минимальное ядро + плагины». Ядро не умеет ничего, кроме общей обвязки про CLI, поиска локально или глобально установленных пакетов bem-tools-something и запуска указанной пользователем команды.

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

Плагин предоставляет JS API, которое ничего не знает про CLI (файл index.js в корне) и CLI интерфейс (файл cli.js). Это позволяет рассматривать каждый плагин, как отдельный пакет, который можно использовать независимо от всех остальных.

Мы успели сделать минимальные версии bem-tools-init, bem-tools-make, bem-tools-create и bem-tools-find. А так же вспомогательные bem-fs-scheme и bem-config. Миша Баранов делал плагин для IntelliJ IDEA для создания БЭМ-сущностей из интерфейса IDE.

Как это обычно бывает после хакатона, всё в сыром состоянии, использовать в работе это всё пока нельзя, но зато можно успеть повлиять на API и помочь нам с доработками.

Обо всём этом ниже подробнее.

Скачиваем bem-tools:

npm i bem/bem-tools#WIP
bem

Если всё прошло успешно, после запуска bem увидим:

Tools to work with files written using the BEM methodology.
See https://bem.info for more info.


Usage:
  bem [OPTIONS] [ARGS]


Options:
  -h, --help : Help
  -v, --version : Version

Установим команду init:

npm i bem-incubator/bem-tools-init

Запускаем ещё раз bem и видим, что появилась команда init:

Tools to work with files written using the BEM methodology.
See https://bem.info for more info.


Usage:
  bem COMMAND [OPTIONS] [ARGS]
  bem [OPTIONS] [ARGS]

Commands:
  init : Init

Options:
  -h, --help : Help
  -v, --version : Version

Запуск bem init my-test-project создаст my-test-project и в ней файл bemconf.json с содержимым

{
   "root": true
}

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

Для работы с конфигом сделали простую библиотеку bem-config (https://github.com/bem-incubator/bem-config/) и накидали примерную структуру файла конфигурации. Файл конфигурации ищется в текущей директории и выше до корня. Используется ближайший найденный, также к нему добавляется ~/.bemconf.json.

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

Следующая не менее минималистичная команда — make:

npm i bem-incubator/bem-tools-make

Просто вызывает enb :)

Ещё мы сделали прототип команды create:

npm i bem-incubator/bem-tools-create

Она поддерживает, как «классический» синтаксис bem-tools:

bem create -b b1 -t css -t js -l .
bem create -b b2 -t css -t js -l .

так и более простой:

bem create {b1,b2}.{css,js}

Есть шаблоны для технологий по умолчанию. Можно задать свои в конфиге, получаемом через bem-config. Они могут быть локальными для уровня, для проекта или браться из конфига пользователя.

Для построения имён БЭМ-сущностей используется bem-naming, для путей на файловой системе — bem-fs-scheme (пока реализована только nested схема, но легко можно добавить другие). И то, и другое можно задать в файле конфигурации.

Есть ещё что доделывать, постепенно доработаем и выпустим в рамках bem-tools 2.0.

Андрей Кузнецов и Илья Исупов написали прототип команды find (https://github.com/bem-incubator/bem-tools-find/), которая позволяет искать БЭМ-сущности и показывать их в разном виде.

Например, нам нужно найти все файлы про модификатор type для блока input:

bem find -b input -m type
/Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_password.bemhtml
/Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_password.bh.js
/Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_search.bemhtml
/Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_search.bh.js

или то же самое, но в виде дерева:

bem find -b input -m type -v tree
tree
└─┬ /Users/vitaly/sites/project-stub/libs/bem-components/common.blocks
  └─┬ input
    └─┬ _type
      ├─┬ password
      │ ├── bemhtml: /Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_password.bemhtml
      │ └── bh.js:   /Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_password.bh.js
      └─┬ search
        ├── bemhtml: /Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_search.bemhtml
        └── bh.js:   /Users/vitaly/sites/project-stub/libs/bem-components/common.blocks/input/_type/input_type_search.bh.js

Миша Баранов делал плагин для Intellij IDEA (WebStorm, PhpStorm, etc), который будет позволять создавать БЭМ-сущности из контекстного меню (https://github.com/bem-incubator/bem-tools-intellj-plugin).

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

Что же дальше? А дальше --Новый год-- у нас есть хитрый план: довести всё перечисленное до рабочего состояния, покрыть тестами и написать документацию. А потом... не останавливаться на достигнутом, а реализовать ещё bem rm, bem cp, bem mv, а там, глядишь, и сообщество подтянется со своими плагинами. ;)

Привет,

хочу рассказать о результатах нашей команды на минувшев хакатоне в рамках Я 12-13 декабря.

Наша команда состояла из Бориса Сердюкова, Константина Гладких, Евгения Константинова и меня и в рамках хаккатона мы решили попробовать собрать бэм-проект project-stub на webpack. Забегая вперед, могу сказать, что это получилось и результат можно посмотреть здесь: https://github.com/just-boris/project-stub/blob/webpack/webpack.config.js

Так как webpack - модульный сборщик, который рассчитан на работу с JavaScript модулями и умеет подключать сторонние технологии как js-модули, то мы решили, что в качестве входной точки для сборки у нас будет статический bemjson файл, а на выходе было желание получить список реальных файлов, которые участвуют в сборке. Все вот это удалось свести к цепочке лоадеров:

{
  test: /\.bemjson.js$/,
  loader: 'bemdecl-to-fs!deps!bemjson?-stringify'
}

которые на выходе возвращают вот такой результат:

require('./libs/../b.js');
require('./libs/../b.styl');
// and etc

На мой взгляд, это довольно крутой результат, так нам удалось свести всю специфичность БЭМ методологии, связанную с депсами, к простой композиции лоадеров, что позволяет использовать стандартные решения для популярных технологий. Например, стили собрать можно как-то так: http://webpack.github.io/docs/stylesheets.html

Так как мы собирали проект на bem-core, то для JS модулей мы использовали ymodules-loader. Вопрос с шаблонизатором решили частично, остановились на bh и решили попробовать написать плагин для webpack, который будет превращать исходный bemjson в статический html, что сейчас работает.

БЭМ предметную область свели к общей декларации bem в рамках конфига, которая содержит информацию об уровнях переопределений с блоками и нужными технологиями.

Также в проекте есть webpack-dev-server, который вотчит изменения и кэширует результаты сборки.

Сам конфиг получился такой: https://github.com/just-boris/project-stub/blob/webpack/webpack.config.js Также решили сгруппировать наши технологии в рамках организации https://github.com/bempack

Скажу сразу, что текущие реализации лоадеров еще не готовы к использованию в продакшене, но мы работаем над этим. В планах, есть желание дополнить project-stub примерами с локализацией, дополнить лоадеры тестами и документацией. Также хочется поддержать шаблонизацию на bemhtml, когда это будет возможно.

В конце хочу поблагодарить ребят из тулзов и лего, которые консультировали нас по бэм-предметной области и создали довольно много интересных инструментов, которые упростили нам жизнь, и ребят из своей команды. Было весело :)

p.s. для интересующихся по webpack'у есть довольно хороший скринкаст: https://learn.javascript.ru/webpack-screencast

Добре!

Есть идейка продвинуть застоявшиеся анклавы задач в БЭМ проектах.

Может организуем хакатончик с одной целью сделать за сутки задачи которые давно подвисли на проектах БЭМ?

Нужены будут кураторы из мантейнеров проектов И конечно добровольцы!

Кто за?

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

На протяжении двух дней разработчики БЭМ из Яндекса и других компаний будут создавать инструменты и говорить о будущем БЭМ и фронтенда. Проекты, созданные в рамках хакатона, обязательно попадут в продакшн!

Если у вас есть комментарии или предложения, не стесняйтесь делиться ими здесь.

Подробности и форма регистрации.