что такое методология бэм
Методология
Технологии
Библиотеки
Определения
Логически и функционально независимый компонент страницы, аналог компонента в Web Components. Блок инкапсулирует в себе поведение (JavaScript), шаблоны, стили (CSS) и другие технологии реализации. Независимость блоков обеспечивает возможность их повторного использования, а также удобство в разработке и поддержке проекта.
Вложенная структура
Блоки можно вкладывать в любые другие блоки.
Например, блок head может содержать логотип ( logo ), форму поиска ( search ) и блок авторизации ( auth ).
Свободное перемещение
Блоки можно перемещать в пределах одной страницы и разных проектов. Независимость блока позволяет изменять его положение на странице и обеспечивает корректную работу и внешний вид.
Так, например, логотип и форму авторизации можно поменять местами. При этом вносить изменения в CSS или JavaScript-код блоков не нужно.
Повторное использование
В интерфейсе может одновременно присутствовать несколько экземпляров одного и того же блока.
Элемент
Составная часть блока, которая не может использоваться в отрыве от него. Элементы не существуют вне блока. Каждый элемент может принадлежать только одному блоку.
Например, пункт меню вне блока меню не используется, значит является его элементом.
Модификатор
БЭМ-сущность, определяющая внешний вид, состояние и поведение блока или элемента.
Использование модификаторов опционально, количество — неограничено. Блоку или элементу нельзя одновременно присвоить разные значения модификатора.
По своей сути модификаторы похожи на атрибуты в HTML. Один и тот же блок выглядит по-разному благодаря применению модификатора.
Например, внешний вид блока меню ( menu ) может меняться в зависимости от примененного модификатора.
Модификаторы могут изменяться в процессе работы блока (например, как реакция на DOM-события блока) и по запросу из других блоков.
БЭМ-сущность
Это понятие может применяться как частное, если рассматривается отдельная БЭМ-сущность, и как собирательное для блоков, элементов и модификаторов.
Способ использования разных БЭМ-сущностей на одном DOM-узле.
совмещать поведение и стили нескольких БЭМ-сущностей без дублирования кода;
создавать семантически новые компоненты интерфейса на основе имеющихся БЭМ-сущностей.
Рассмотрим пример микса блока и элемента другого блока.
БЭМ-дерево
Представление структуры веб-страницы в терминах блоков, элементов и модификаторов. Это абстракция над DOM-деревом, которая описывает имена БЭМ-сущностей, их состояния, порядок, вложенность и вспомогательные данные.
В реальных проектах БЭМ-дерево можно выразить любым форматом, который поддерживает древовидную структуру.
Рассмотрим пример DOM-дерева:
Ему соответствует такое БЭМ-дерево:
Это же БЭМ-дерево будет иметь следующий вид в форматах XML и BEMJSON:
Реализация блока
Набор различных технологий, определяющих следующие особенности БЭМ-сущности:
дополнительные данные (например, картинки).
Технология реализации
Технология, которая используется для реализации блока.
Блоки могут быть реализованы в одной или нескольких технологиях, например:
поведение — JavaScript, CoffeeScript;
внешний вид — CSS, Stylus, Sass;
шаблоны — Pug, Handlebars, XSL, BEMHTML, BH;
документация — Markdown, Wiki, XML.
Например, если внешний вид блока задан с помощью CSS, это означает, что блок реализован в технологии CSS. А если документация к блоку написана в формате Markdown — блок реализован в технологии Markdown.
Переопределение блока
Изменение реализации блока путем добавления ему новых особенностей на другом уровне.
Уровень переопределения
Набор БЭМ-сущностей и их частичных реализаций.
Конечная реализация блока может быть разделена по разным уровням переопределения. Каждый последующий уровень добавляет или перекрывает исходную реализацию блока. Конечный результат собирается из отдельных технологий реализации блока со всех уровней переопределения последовательно в заданном порядке.
Например, в проект на отдельный уровень подключается сторонняя библиотека, которая содержит готовые реализации блоков. Проектные блоки хранятся на другом уровне переопределения.
Предположим, что необходимо изменить внешний вид одного из блоков библиотеки. Для этого не нужно менять CSS-правила блока в исходном коде библиотеки или копировать код на уровень проекта. Достаточно создать дополнительные CSS-правила для этого блока на проектном уровне. При сборке в конечную реализацию подключатся исходные стили с уровня библиотеки и новые — с уровня проекта.
Зачем нужен БЭМ
Следуете ли вы БЭМу, и насколько он востребован вне Яндекса?
БЭМ расшифровывается как: блок, элемент, модификатор. Это такой набор абстракций, на который можно разбить интерфейс и разрабатывать всё в одних и тех же терминах. Как говорит сайт bem.info, БЭМ предлагает единые правила написания кода, помогает его масштабировать и повторно использовать, а также увеличивает производительность и упрощает командную работу.
Круто, да? Но зачем вам масштабируемость и командная работа, если вы один верстальщик на проекте, который не претендует на популярность Яндекса? Чтобы ответить на этот вопрос, нужно отмотать историю лет на 10 назад, когда это подход только начали формулировать.
В основу того, что мы сейчас называем БЭМом, легла идея независимых блоков, которую Виталий Харисов сформулировал и презентовал в 2007 году на первой российской конференции по фронтенду. Это было настолько давно, что тогда даже слова «фронтенд» ещё не было, тогда это называлось клиент-сайд.
Идея была в том, чтобы ограничить возможности CSS для более предсказуемых результатов. Использовать минимум глобальных стилей и каждый отдельный элемент страницы делать блоком со своим уникальным классом и стилями, которые полностью его описывают. Селекторы по элементам и ID, хрупкие связки вложенности — всё это заменялось на простые селекторы по классам. Каждый класс в стилях — это блок. Благодаря этому блоки можно легко менять местами, вкладывать друг в друга и не бояться конфликтов или влияния.
Потом появились абсолютно независимые блоки (АНБ), где у элементов внутри есть свой префикс с именем родителя, а состояния блоков снова дублируют класс, но уже с постфиксом. Подход обрёл черты современного БЭМа, одна из которых — многословность классов.
Эта многословность гарантирует уникальность элементов и модификаторов в рамках одного проекта. За уникальностью имён блоков вы следите сами, но это довольно просто, если каждый блок описан в отдельном файле. Глядя на такой класс в HTML или CSS, можно легко сказать, что это, и к чему оно относится.
Изначально АНБ, а потом и БЭМ, решали задачу важную для вёрстки любых масштабов: предсказуемое поведение и создание надёжного конструктора. Вы же хотите, чтобы ваша вёрстка была предсказуемой? Вот и Яндекс тоже. Ещё это называется «модульность» — о ней хорошо написал Филип Уолтон в «Архитектуре CSS», ссылка на перевод в описании.
Через пару лет в Яндексе окончательно сформулировали нотацию БЭМ. Любой интерфейс предлагалось разделять на блоки. Неотделимые части блоков — элементы. У тех и других есть модификаторы.
Например, блок поиска по сайту. Он может быть в шапке и в подвале — значит это блок. В нём есть обязательные части: поле поиска и кнопка «найти» — это его элементы. Если поле нужно растянуть на всю ширину, но только в шапке, то блоку или элементу, который отвечает за это растягивание, даётся модификатор.
Для полной независимости блоков мало назвать классы правильно или изолировать стили, нужно собрать всё, что к нему относится. В проекте по БЭМу нет общего script.js или папки images со всеми картинками сайта. В одной папке с каждым блоком лежит всё, что нужно для его работы. Это позволяет удобно добавлять, удалять и переносить блоки между проектами. Потом, конечно, все ресурсы блоков при сборке объединяются в зависимости от задач проекта.
Когда БЭМ вышел за пределы Яндекса, сначала его воспринимали как магию и старались воспроизводить дословно, вплоть до префиксов b- у каждого блока. Такой смешной карго-культ.
Некоторые неверно понимали идею и появлялись даже элементы элементов. Потом за нотацию взялись энтузиасты и появилась одна из самых популярных: блок отделяется двумя подчёркиваниями, а модификатор — двумя дефисами. Наглядно и просто — сам так пишу.
А зачем вообще все эти нотации — я ведь один верстальщик на проекте, помните? Помню. А ещё помню, как сам верстал до БЭМа: в каждом проекте придумывал что-нибудь такое новенькое. А потом открывал код годичной давности и удивлялся — какой идиот это написал?
Возьмём, к примеру, русский язык. Мы же пишем с прописной имена людей, названия и прочее такое? Пишем. Чтобы легко потом считывалось: это Надя или надежда на лучшее? Уж не говоря про знаки препинания и другие полезные договорённости. Вот буква «ё», например, смягчает… так, о чём мы? Да, БЭМ.
До БЭМа были проекты с портянками стилей, которые нельзя трогать. Они копились годами, слой за слоем, как обои в древней коммуналке. Их просто подключали первыми, а потом перезаписывали что мешало. Когда у вас есть div < font-size: 80% >— это даже уже не смешно.
БЭМ продолжил развиваться в Яндексе и вырос за пределы вёрстки: появились уровни переопределения, богатый инструментарий, JS-библиотека для работы с БЭМ-классами, шаблонизаторы и целый БЭМ-стэк. БЭМу даже жест придумали, но это совсем другая история, специфичная для Яндекса.
Были и другие методологии: OOCSS Николь Салливан, SMACSS Джонатана Снука, вариации БЭМа и целые фреймворки. Даже у нас на продвинутом интенсиве можно было выбрать любую методологию для вёрстки учебного проекта.
Но выжил только БЭМ и его вполне можно назвать стандартом де-факто современной разработки интерфейсов. И что — это финальная ступень эволюции? Нет конечно. Как ни автоматизируй, многое в БЭМе приходится делать руками, и возможны конфликты.
Модульность и изоляцию стилей блока можно решить ещё лучше. Есть веб-компоненты, CSS-модули, куча решений CSS-в-JS и даже, прости господи, атомарный CSS. Но нет единого решения накопившихся проблем на следующие 10 лет, каким когда-то стал БЭМ. Что это будет? Посмотрим. Я ставлю на веб-компоненты.
А пока, если вы опишете интерфейс по БЭМу — код будет организован, предсказуем, расширяем и готов для повторного использования. Не только для вас, но и для других.
Зачем нужен БЭМ
Следуете ли вы БЭМу, и насколько он востребован вне Яндекса? — спрашивает наша ученица Евгения. Следуем, Евгения, и БЭМ вполне применим не только в Яндексе. Давайте разберёмся.
БЭМ расшифровывается как: блок, элемент, модификатор. Это такой набор абстракций, на который можно разбить интерфейс и разрабатывать всё в одних и тех же терминах. Как говорит сайт bem.info, БЭМ предлагает единые правила написания кода, помогает его масштабировать и повторно использовать, а также увеличивает производительность и упрощает командную работу.
Круто, да? Но зачем вам масштабируемость и командная работа, если вы один верстальщик на проекте, который не претендует на популярность Яндекса? Чтобы ответить на этот вопрос, нужно отмотать историю лет на 10 назад, когда это подход только начали формулировать.
В основу того, что мы сейчас называем БЭМом, легла идея независимых блоков, которую Виталий Харисов сформулировал и презентовал в 2007 году на первой российской конференции по фронтенду. Это было настолько давно, что тогда даже слова «фронтенд» ещё не было, тогда это называлось клиент-сайд.
Идея была в том, чтобы ограничить возможности CSS для более предсказуемых результатов. Использовать минимум глобальных стилей и каждый отдельный элемент страницы делать блоком со своим уникальным классом и стилями, которые полностью его описывают. Селекторы по элементам и ID, хрупкие связки вложенности — всё это заменялось на простые селекторы по классам. Каждый класс в стилях — это блок. Благодаря этому блоки можно легко менять местами, вкладывать друг в друга и не бояться конфликтов или влияния.
Потом появились абсолютно независимые блоки (АНБ), где у элементов внутри есть свой префикс с именем родителя, а состояния блоков снова дублируют класс, но уже с постфиксом. Подход обрёл черты современного БЭМа, одна из которых — многословность классов.
Эта многословность гарантирует уникальность элементов и модификаторов в рамках одного проекта. За уникальностью имён блоков вы следите сами, но это довольно просто, если каждый блок описан в отдельном файле. Глядя на такой класс в HTML или CSS, можно легко сказать, что это, и к чему оно относится.
Изначально АНБ, а потом и БЭМ, решали задачу важную для вёрстки любых масштабов: предсказуемое поведение и создание надёжного конструктора. Вы же хотите, чтобы ваша вёрстка была предсказуемой? Вот и Яндекс тоже. Ещё это называется «модульность» — о ней хорошо написал Филип Уолтон в «Архитектуре CSS», ссылка на перевод в описании.
Через пару лет в Яндексе окончательно сформулировали нотацию БЭМ. Любой интерфейс предлагалось разделять на блоки. Неотделимые части блоков — элементы. У тех и других есть модификаторы.
Например, блок поиска по сайту. Он может быть в шапке и в подвале — значит это блок. В нём есть обязательные части: поле поиска и кнопка «найти» — это его элементы. Если поле нужно растянуть на всю ширину, но только в шапке, то блоку или элементу, который отвечает за это растягивание, даётся модификатор.
Для полной независимости блоков мало назвать классы правильно или изолировать стили, нужно собрать всё, что к нему относится. В проекте по БЭМу нет общего script.js или папки images со всеми картинками сайта. В одной папке с каждым блоком лежит всё, что нужно для его работы. Это позволяет удобно добавлять, удалять и переносить блоки между проектами. Потом конечно все ресурсы блоков при сборке объединяются в зависимости от задач проекта.
Когда БЭМ вышел за пределы Яндекса, сначала его воспринимали как магию и старались воспроизводить дословно, вплоть до префиксов b- у каждого блока. Такой смешной карго-культ.
Некоторые неверно понимали идею и появлялись даже элементы элементов. Потом за нотацию взялись энтузиасты и появилась одна из самых популярных: блок отделяется двумя подчёркиваниями, а модификатор — двумя дефисами. Наглядно и просто — сам так пишу.
А зачем вообще все эти нотации — я ведь один верстальщик на проекте, помните? Помню. А ещё помню, как сам верстал до БЭМа: в каждом проекте придумывал что-нибудь такое новенькое. А потом открывал код годичной давности и удивлялся — какой идиот это написал?
Возьмём, к примеру, русский язык. Мы же пишем с прописной имена людей, названия и прочее такое? Пишем. Чтобы легко потом считывалось: это Надя или надежда на лучшее? Уж не говоря про знаки препинания и другие полезные договорённости. Вот буква ё, например смягчает… так, о чём мы? Да, БЭМ.
До БЭМа были проекты с портянками стилей, которые нельзя трогать. Они копились годами, слой за слоем, как обои в древней коммуналке. Их просто подключали первыми, а потом перезаписывали что мешало. Когда у вас есть div < font-size: 80% >— это даже уже не смешно.
БЭМ продолжил развиваться в Яндексе и вырос за пределы вёрстки: появились уровни переопределения, богатый инструментарий, JS-библиотека для работы с БЭМ-классами, шаблонизаторы и целый БЭМ-стэк. БЭМу даже жест придумали, но это совсем другая история, специфичная для Яндекса.
Были и другие методологии: OOCSS Николь Салливан, SMACSS Джонатана Снука, вариации БЭМа и целые фреймворки. Даже у нас на продвинутом интенсиве HTML Академии можно было выбрать любую методологию для вёрстки учебного проекта.
Но выжил только БЭМ и его вполне можно назвать стандартом де-факто современной разработки интерефейсов. И что — это финальная ступень эволюции? Нет конечно. Как ни автоматизируй, многое в БЭМе приходится делать руками, и возможны конфликты.
Модульность и изоляцию стилей блока можно решить ещё лучше. Есть веб-компоненты, CSS-модули, куча решений CSS-в-JS и даже, прости господи, атомарный CSS. Но нет единого решения накопившихся проблем на следующие 10 лет, каким когда-то стал БЭМ. Что это будет? Посмотрим. Я ставлю на веб-компоненты.
А пока, если вы опишете интерфейс по БЭМу — код будет организован, предсказуем, расширяем и готов для повторного использования. Не только для вас, но и для других.
БЭМ — методология развешивания костылей
Впервые я узнал о БЭМ лет 5 назад. В то время все ненавидели IE6, ждали возможности полноценно использовать CSS2 и благополучно забывали табличную верстку. В то время казалось, что когда исчезнет IE6, жизнь верстальщика станет увлекательной и беззаботной. Именно IE6 был основной причиной костылей в верстке. Кто бы мог подумать, что во времена HTML5 и CSS3, когда нет особых проблем с развитием популярных браузеров, ситуация станет еще хуже.
Недавно я обнаружил, что многие существующие проекты уже внедрили БЭМ, а некоторые новые проекты требуют от верстальщика обязательной разработки по БЭМ. То есть профессиональные разработчики уже ставятся перед фактом и не имеют выбора. Раз ситуация складывается таким образом, давайте попробуем разложить все по полочкам без рекламы и приукрашивания.
Сопровождаемость и повторное использование кода
Очень важные показатели для любой разработки, известные нам в основном по языкам программирования. Вся суть и прелести БЭМ сводятся именно к этим показателям. Если программисту долго рассказывать про их важность, а потом предложить купить слона, сделка скорее всего состоится. Чтобы понять, улучшает ли БЭМ что-то в этом направлении, надо сначала определиться по отношению к чему будем проверять улучшения. Если сверстать страничку таблицами, как это было во времена IE6, то улучшения от перехода на БЭМ с такой верстки определенно будут. Но найти проекты, которые все еще страдают от табличной верстки, сейчас уже непросто. Посмотрим лучше на актуальные практики, которые идут из спецификации HTML/CSS.
Таких практик всего одна. Это семантическая верстка с разделением структуры данных и оформления. Много лет разработчики самого HTML развивали язык, подразумевая именно эту практику. В концепции разделения структуры данных и оформления заложена одна очень важная идея на тему сопровождаемости. HTML-разметка создается таким образом, чтобы любые последующие изменения можно было вносить, меняя только CSS-код. Эта концепция очень изящно решает все задачи сопровождаемости. В итоге, если БЭМ что-то и улучшает в плане сопровождаемости, то явно не по отношению к семантической верстке.
БЭМ существенно облегчил жизнь разработчиков в Яндекс
Много раз видел что-то вроде этой фразы в качестве убедительного аргумента в пользу БЭМ. Проверить качество жизни разработчиков в Яндекс после перехода на БЭМ будет непросто. Зато можно посмотреть код их проектов. Так вот, это очень похоже на правду. Ведь в верстке некоторых проектов Яндекса все еще используются некоторые практики табличной верстки. К примеру, чтобы расположить логотип и горизонтальное меню сбоку от него, кто-то из разработчиков Яндекса впендюривает одну общую таблицу. Неудивительно, что БЭМ улучшает жизнь в Яндекс, ведь хуже БЭМ только табличная верстка.
Проблема в том, что свою борьбу с таблицами эта компания разнесла по всему рунету под видом некой эффективной методологии. Сейчас даже новые проекты, разработчики которых даже не знают про табличную верстку, вынуждены использовать эту топорную практику борьбы с таблицами. Бороться с табличной версткой нужно, если проблема еще где-то имеет место. Вот только не надо менять одни костыли на другие. Есть хорошие готовые практики, которые давно решают все задачи сопровождаемости. И уж точно не стоит выгонять с Хабра всех, кто высказывается против использования методологии БЭМ. Если бы БЭМ был так прекрасен, как описывают авторы, не было бы срача.
БЭМ — это жесткий и очень топорный свод правил, который не несет никакой практической пользы, если не брать в расчет проблемы устаревшей табличной верстки. БЭМ уродует код и разрушает все прекрасное, что есть в процессе верстки. Любое соприкосновение с БЭМ напоминает бессмысленное и утомительное развешивание костылей.
Перед тем как внедрять у себя БЭМ, стоит несколько раз подумать, почитать спецификацию HTML/CSS, изучить другие практики. Только после реального понимания практической полезности разных практик и различий между ними можно принимать решение в пользу использования БЭМ, но лучше в этот момент еще раз подумать. В ином случае можно стать жертвой агрессивного маркетинга и соучастником в распространении говнокода.
Сайт с нуля на полном стеке БЭМ-технологий. Методология Яндекса
На прошлой неделе BBC рассказала, что для новой версии главной страницы использовала методологию БЭМ, созданную в Яндексе. По такому случаю мы решили поднять материалы мастер-класса «Разрабатываем сайт с нуля на полном стеке БЭМ-технологий» и рассказать вам, как начать использовать полный стек БЭМ-технологий в своих проектах.
БЭМ упрощает разработку сайтов, которые нужно быстро создавать и долго поддерживать. Эту технологию используют во фронтенде почти всех сервисов Яндекса, и она уже успела обрасти множеством библиотек и инструментов, которыми мы хотим с вами поделиться.
В статье мы расскажем, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомимся с готовыми библиотеками блоков и инструментами для автоматизации сборки. Покажем, как разные инструменты — например, autoprefixer, css-препроцессор Stylus или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки по БЭМ.
На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельно остановимся на декларативных шаблонах BEMHTML и BEMTREE, которые позволяют преобразовывать данные в БЭМ-дерево, описанное в формате BEMJSON и, затем в HTML. Рассмотрим в деталях, как написать серверную часть приложения по БЭМ-методологии.
Мы будем использовать API Twitter’а для создания нашего проекта. В результате получим работающий сайт на полном стеке БЭМ-технологий и пошаговое статью-руководство, как все это можно воспроизвести.
Специально для мастер-класса мы написали мини-сервис, который занимается поиском по различным социальным сетям и выводит результат в упорядоченном виде. Мы выложили его на github в репозитории github.com/bem/sssr — смотрите, знакомьтесь.
А мы пойдём по порядку.
Теория
Каждый блок лежит в своей папке в файловой системе, в которой сложены все технологии, описывающие блок, его элементы и модификаторы.
Если вам интересны подробности о том, как и почему появился БЭМ, читайте статью Виталия Харисова «История БЭМ» и смотрите видеозаписи доклада.
Подробное описание методологии БЭМ можно найти на нашем сайте.
Создание заготовки проекта
После чего запустим сам генератор:
Отвечая на вопросы, касающиеся используемых технологий, получим собранную и сконфигурированную для сборки заготовку.
Пройдемся по вопросам:
Уровень переопределения
Это набор реализаций блоков. Проект может иметь несколько уровней, на каждом из которых добавляется или изменяется реализация блоков. Конечная реализация блока собирается со всех уровней последовательно в заданном порядке.
Мы можем доопределять и переопределять стили, шаблоны, JavaScript-реализацию блоков на уровне переопределения своего проекта. При этом, мы ничего не меняем в исходных файлах библиотеки, позволяя сохранять наши изменения в случае её обновления.
Приведём пример, как это выглядит в файловой системе:
Итак, наша заготовка проекта готова. Перейдем в каталог проекта:
Вёрстка
Для начала создадим статический прототип нашей страницы. Для описания её структуры воспользуемся технологией BEMJSON.
В BEMJSON описывается БЭМ-дерево: порядок и вложенность блоков, названия и состояния БЭМ-сущностей, дополнительные произвольные поля.
Cоберём сгенерированный проект и посмотрим, что получилось. Для удобной работы с локально установленым пакетом ENB нужно выполнить следующую команду:
Теперь страницу можно открыть по адресу: http://localhost:8080/desktop.bundles/index/index.html.Наш сборщик соберёт все необходимые зависимости, а по ним соберёт файлы нужных блоков и технологий.
В шапке, в свою очередь, будет расположена поисковая форма и название сайта с логотипом:
Добавим необходимые блоки в BEMJSON:
В BEMJSON можно использовать произвольные JavaScript-выражения. Добавим в поле content элемента filter конструкцию map для повторяющихся блоков checkbox :
Полный файл index.bemjson.js :
И для блока user — desktop.blocks/user/user.styl :
Не будем останавливаться на вопросах CSS-вёрстки очень подробно, пойдём дальше.
Нам осталось добавить блоки с найденными сообщениями. Опишем их в index.bemjson.js и для прототипирования воспользуемся возможностями JavaScript.
Давайте посмотрим на результат:
Шаблонизатор BEMHTML
Декларативная шаблонизация
В Яндексе очень любят декларативность — не только в CSS, но в шаблонах и в JavaScript’е.
Как выглядит декларативность в CSS:
Мы отбираем все узлы DOM-дерева, соответствующие условию, и применяем к ним тело шаблона.
Для декларативной шаблонизации в Яндексе написали свой шаблонизатор BEMHTML. Подробнее о его архитектуре можно узнать из статьи Шаблонизация данных в bem-core.
Пример декларативного шаблона на BEMHTML:
Отбираются все блоки БЭМ-дерева, соответствующие нашим условиям, потом к ним применяется тело шаблона:
BEMHTML написан на JavaScript. Его синтаксис — это чистый JavaScript. Можно использовать JavaScript-функции в подпредикатах и теле шаблона. Для production-режима шаблоны будут скомпилированы в оптимизированный JavaScript.
BEMHTML отвечает за то, как БЭМ-дерево преобразуется в HTML-строку. Входными данными является БЭМ-дерево или его фрагмент, описанный в технологии BEMJSON. На этот BEMJSON накладывается BEMHTML-шаблон. А выходные данные – это HTML-строка.
В общем виде шаблон выглядит следующим образом:
Подпредикаты — это условия, при выполнении которых применяется шаблон. Например:
Мода — это шаг генерации выходного HTML. Каждая мода отвечает за свой кусочек получающегося HTML-кода. Мода default описывает набор и порядок прохождения остальных мод. На этой схеме видно, за что отвечает каждая мода:
Рекомендуем вдумчиво прочитать документацию по BEMHTML, описанную в Cправочном руководстве по шаблонизатору BEMHTML.
Теперь мы можем редактировать шаблон блока в одном месте, переносить и реиспользовать этот блок с легкостью.
Мы описали то, как должны преобразовываться наши БЭМ-блоки в HTML. Теперь давайте рассмотрим, как будут получены и обработаны данные twitter’а
Архитектура приложения
Двухэтапная шаблонизация
BEMTREE
Сразу в бой. Напишем BEMTREE-шаблон для модификатора < type: 'twitter' >, блока island :
desktop.blocks/island/_type/island_type_twitter.bemtree
На сервере
Наше приложение будет работать на фреймворке express — отдавать HTML в ответ на поисковый запрос.
Блок service_type_twitter
Для простоты работы с twitter’ом используем модуль twit. Установим его с помощью npm :
Авторизационные данные, необходимые для работы с twitter’ом, мы вынесли в отдельный файл. Скопируем его содержимое себе в одноименный файл.
Это приложение выполняет поиск по ключевому слову #b_ и выводит результат в консоль.
Пересоберем наш проект и запустим его с помощью node.js
Результатом выполнения должен быть список твитов в консоли.
Теперь нам нужно как-то передать результаты выполнения для дальнейшей работы — шаблонизации и передачи на клиент.
Для асинхронной работы с помощью промисов мы используем библиотеку vow.
Для организации серверного и клиентского JS-кода — модульную систему YModules.
Модульная система
Библиотека bem-core использует модульную систему ymodules.
Она позволяет обернуть код нашего блока в обертку-модуль и вызывать его при необходимости из других модулей.
Отредактируем файл service_type_twitter.node.js в соответствии с этими дополнениями:
Блок server
Теперь все нужные нам блоки попадут в сборку. Пересоберем проект и запустим сервер:
Теперь добавим преобразование этих данных в BEMJSON с помощью BEMTREE. Отредактируем server.node.js :
После того, как выполнятся все промисы, массив результатов склеивается в плоский список и сортируется по дате.
Затем в BEMTREE.apply() передается этот массив, каждый элемент которого преобразуется в объект с полями, описывающими БЭМ-сущность и данные, которые мы теперь можем использовать в наших BEMTREE-шаблонах.
Пересоберем проекта и снова откроем страницу http://localhost:3000/search?query=%23b_&twitter=on. В браузере должен отображаться BEMJSON, сформированный с помощью BEMTREE.
Если обновить нашу страницу в браузере, мы получим HTML, который и будем в дальнейшем использовать на клиенте — подгружать с помощью AJAX.
Если использовать ключ json=on — откроется содержимое BEMJSON-файла — http://localhost:3000/search?query=%23b_&twitter=on&json=on.
Клиентский JavaScript с i-bem.js
О том, что такое i-bem.js и как он работает можно прочитать в подробном Руководстве пользователя.
Блоки с js-представлением
Поле js позволяет использовать как булевы значения, так и объект параметров, которые можно будет использовать при написании js-реализации блока. Наш пример будет отрендерен в подобный HTML:
Класс i-bem говорит о том, что на этом узле DOM-дерева есть блок с js-представлением. А в дата-атрибуте data-bem
передается объект, ключами которого являются имена блоков с js-представлением, а значениями — параметры, передаваемые этим блокам.
Пишем клиентский js
Блок form
Блок sssr
Теперь создадим блок, который будет загружать запрашиваемые данные и отображать их на странице.
./desktop.blocks/sssr/sssr.js :
Итак, мы получили первую, пока очень примитивную и недоработанную версию нашего приложения. Для его запуска нужно собрать файлы с помощью нашего сборщика и запустить файл index.node.js из собранного бандла:
Теперь мы можем протестировать его работу. Для этого перейдем на страницу localhost:3000, введем что-нибудь в поле ввода, отметим нужные чекбоксы и попробуем отправить форму. Если все сделано верно, то под шапкой мы увидим результаты поиска по заданному запросу.
И запустим сборку в режиме production :
Отрыв страницу в браузере мы можем убедиться что картинки на странице заработали.
Добавим интерактивности. Блок spin
Мы выставили булевый модификатор spin_visible в значение true и должны увидеть вращающийся спинер рядом с полем ввода.
Проверка полей формы
Сейчас, если оставить пустое поле ввода и убрать чекбоксы сервисов, форма все равно отправится. Давайте изменим это поведение и добавим метод isEmpty() :
./desktop.blocks/form/form.js :
Мы проверяем значение поля input и модификатор checkbox_checked и возвращяем результат проверки.
Теперь нужно добавить проверку, которую мы только что написали, в блок sssr перед отправкой запроса:
./desktop.blocks/sssr/sssr.js :
Мы добавили в _doRequest() дополнительную проверку формы на заполненность полей ввода.
Автообновление при изменении полей ввода
Давайте сделаем так, чтобы при изменении поискового запроса или чекбоксов, наш сервис сам отправлял запрос и
обновлял содержимое. Для этого отредактируем блок form и добавим обработчик события change на блоке input :
Можно проверить отправку запросов при изменении формы с помощью консоли браузера:
И добавим метод-обертку для задержанной отправки запроса. Обратите внимание, что мы добавили functions__debounce в зависимости модульной системы и получаем его в виде debounce :
Открыв страницу приложения в браузере мы можем убедиться, что запросы уходят с задержкой. Это хорошо — мы оптимизировали код и уменьшили количество запросов к серверу.
Автообновление
Давайте протестируем наше приложение. Оно должно обновляться каждые 10 секунд.
Оптимизация и рефакторинг
Кэширование поиска блоков
Отложенная инициализация
В нашем случае нет небоходимости инициализировать блоки sssr и form сразу, они могут быть проинициализированы по требованию. Давайте выразим это в коде:
./desktop.blocks/sssr/sssr.js :