BEM, next level
Based on the article on Habré and the flame around it. The article is written for those who want to try BEM, but do not know which side to take it for. When you first look at BEM, it seems logical and incredibly convenient. But when trying to realize the user is faced with obstacles that level all the advantages. I do not know how and why this methodology was created, it does not soar me, if used correctly, then it’s cool, but I don’t wonder why I once built a car or a plane, but now it’s convenient to use, it's just a handy tool. I only know that when creating, no one was going to write styles and classes in one canvas.
I will try to consider one of the many options for applying the BEM methodology in practice, which not only corresponds to the spirit, but also the recommendations of the creators.
In my opinion, the main problem of BEM is not in complex and long names, or in the absence of a cascade (which by the way is not always true). And in the misunderstanding of many why they need it. Writing the already difficult readable HTML code with your hands, adding monstrous class names thereby even more piling up the code, oh, I didn’t want to. And CSS with a length of more than 3,000 lines generally caused emetic urges. And only after becoming acquainted with the BEM infrastructure, I realized all the delights of this approach. Here we consider the approach itself, leaving aside the tools developed by the BEM creators, in order to focus on the implementation itself and to better understand the whole process.
')
For this, I used Node.js, the Express framework, installing it with the standard Jade templating system and the Stylus CSS preprocessor.
The project itself is here: github.com/jchouse/bem-school_type_middle
Instructions for launching the readme.
If you carefully read the articles on BEM , you can see that BEM is not only long classes, but also a certain file structure. First of all we will create a folder where we will store BEM blocks.
I think it is not necessary to describe the whole way of creating this project in stages, this can be seen by commits. I will only draw your attention to the basic concepts that I was guided by.
Prepare a simple object with information (of course it can be collected from a database, or be hard-coded):
routes / index.js
ATTENTION: the information is hardcoded, when changed, you need to restart the server. For a clean layout, you can write the text in the Jade block, and give the client the generated HTML.
Minimum code in the page template, only the most necessary.
views / index.jade
If possible, the entire block description code should be placed inside the block itself.
This is a page wrapper that remains unchanged (header, footer, etc.):
blocks / page / page.jade
Main menu:
blocks / main-menu / main-menu.jade
In general CSS, we write only imports, the styles themselves are in the appropriate folder of the block.
Common styles, used to import all blocks:
public / stylesheets / style.styl
Styles of one block, there is a description of the block itself, as well as import styles of modifiers and elements.
blocks / main-menu / main-menu.styl
Styles of one block:
The complex name of the class indicates first of all the place where you can find this style, without using the document search or scrolling the entire document.
To make it all work, I applied internal elements of import, writing all dependencies by hand.
Prefixes are optional. But it is possible for blocks that have no visual presentation or for auxiliary blocks. For example, a block with variables or a block cleaning flow from floats. By themselves, prefixes were born in order to distinguish a block from a block element at first glance, in such implementations as XSL. Since we prescribe the name of the style entirely - there is no need for them.
And yes! This approach gives a real reusability, copy and paste into the new project a folder of the block and, voila, it is already in your project. Moreover, the blocks used in all documents can be placed in blocks-common and copied between projects all together. And if we also enter into a preliminary agreement with the designer and the backend, life in general appears in pink.
Minuses:
All problems are solved by bem-bl + bem-tools. How to use these two tools for an ordinary project, we will tell in the next article.
UPD: Comrades minus, I understand that my writing skills are far from perfect, and I welcome any constructive criticism. Just do not forget to leave it in the comments to the article. Thank :)
I will try to consider one of the many options for applying the BEM methodology in practice, which not only corresponds to the spirit, but also the recommendations of the creators.
In my opinion, the main problem of BEM is not in complex and long names, or in the absence of a cascade (which by the way is not always true). And in the misunderstanding of many why they need it. Writing the already difficult readable HTML code with your hands, adding monstrous class names thereby even more piling up the code, oh, I didn’t want to. And CSS with a length of more than 3,000 lines generally caused emetic urges. And only after becoming acquainted with the BEM infrastructure, I realized all the delights of this approach. Here we consider the approach itself, leaving aside the tools developed by the BEM creators, in order to focus on the implementation itself and to better understand the whole process.
')
For this, I used Node.js, the Express framework, installing it with the standard Jade templating system and the Stylus CSS preprocessor.
The project itself is here: github.com/jchouse/bem-school_type_middle
Instructions for launching the readme.
If you carefully read the articles on BEM , you can see that BEM is not only long classes, but also a certain file structure. First of all we will create a folder where we will store BEM blocks.
I think it is not necessary to describe the whole way of creating this project in stages, this can be seen by commits. I will only draw your attention to the basic concepts that I was guided by.
Prepare a simple object with information (of course it can be collected from a database, or be hard-coded):
routes / index.js
res.render('index', { title: 'BEM ', menu: [ { url: '#home', content: '' }, { url: '#port', content: '' }, ........... ATTENTION: the information is hardcoded, when changed, you need to restart the server. For a clean layout, you can write the text in the Jade block, and give the client the generated HTML.
Minimum code in the page template, only the most necessary.
views / index.jade
extends ../blocks/page/page block content include ../blocks/content/content If possible, the entire block description code should be placed inside the block itself.
This is a page wrapper that remains unchanged (header, footer, etc.):
blocks / page / page.jade
doctype 5 html include ../head/head body.page div.page__wrapper include ../main-menu/main-menu block content include ../footer/footer Main menu:
blocks / main-menu / main-menu.jade
ul.main-menu.main-menu_type_horiz each item in menu li.main-menu__item a(href='#{item.url}')= item.content In general CSS, we write only imports, the styles themselves are in the appropriate folder of the block.
Common styles, used to import all blocks:
public / stylesheets / style.styl
@import '../../blocks/page/page' @import '../../blocks/main-menu/main-menu' @import '../../blocks/footer/footer' Styles of one block, there is a description of the block itself, as well as import styles of modifiers and elements.
blocks / main-menu / main-menu.styl
.main-menu margin: 0; padding: 0; text-align: center; list-style-type: none; // @import '_type/main-menu_type_horiz' // @import '__item/main-menu__item' Styles of one block:
The complex name of the class indicates first of all the place where you can find this style, without using the document search or scrolling the entire document.
To make it all work, I applied internal elements of import, writing all dependencies by hand.
Prefixes are optional. But it is possible for blocks that have no visual presentation or for auxiliary blocks. For example, a block with variables or a block cleaning flow from floats. By themselves, prefixes were born in order to distinguish a block from a block element at first glance, in such implementations as XSL. Since we prescribe the name of the style entirely - there is no need for them.
And yes! This approach gives a real reusability, copy and paste into the new project a folder of the block and, voila, it is already in your project. Moreover, the blocks used in all documents can be placed in blocks-common and copied between projects all together. And if we also enter into a preliminary agreement with the designer and the backend, life in general appears in pink.
Minuses:
- All information is stored in one object, one for the whole page, so the blocks are not completely independent. It is necessary to closely monitor the keys. And it’s better to document everything all at once;
- Of course, it’s very disturbing that small repeating blocks (buttons, for example), which are many on the page, but in different environments, will have to be imported very carefully. Maybe a screen to use ...
- All dependencies are written with pens. Of course, you can write a script for this;
- Now modifiers do not affect HTML markup and JS.
All problems are solved by bem-bl + bem-tools. How to use these two tools for an ordinary project, we will tell in the next article.
UPD: Comrades minus, I understand that my writing skills are far from perfect, and I welcome any constructive criticism. Just do not forget to leave it in the comments to the article. Thank :)
Source: https://habr.com/ru/post/152939/
All Articles