Hello, <% = habrauser%>!
I really like the Ruby on Rails framework, it’s really very, very cool. It allows you to realize your plans in the shortest possible time. I used to write a lot on it, but today I am a front-end developer. When I learned about the BEM methodology, I was delighted, because somehow you yourself come to something similar. Well, when the Zen process is reduced significantly. You can read about BEM
here and
here . Recently, the last
BEMup finally put everything in its place. I just needed the tools to work with BEM in projects on Ruby on Rails. Specific solutions did not exist, and bem-tools does not fit, for obvious reasons, described below. I decided to write a bem-tools in ruby.
What for?
Once, many expressed the idea of how to use BEM on rails, but apart from correctly naming classes in css, I did not learn anything useful. Moreover, I don't want to write such classes with pens. No specific tools were proposed. And BEM is not only css and javascript. I wanted to have something like a BEMHTML template inside a rail. To use it one could plug into V8 rails and compile the templates. But then there is not much left of the rails and this is not a Ruby way. I used to write HAML templates and use the SASS preprocessor. I really didn’t want the use of BEM on rails to introduce serious difficulties for understanding and to force developers to perform actions unusual for them. In addition, there is a pipeline in the rails that assembles and compiles assets, which means the floor has already been done. After much deliberation, there are clear requirements for what is necessary to have in the form of tools:
')
- One directory with blocks for all projects on Ruby on Rails. Ideally, not just RoR.
- Rendering of blocks and elements in views.
- Convenient creation / deletion / viewing of blocks / elements / modifiers.
- Integration with pipeline.
- Maximum similarity with bem-tools.
Why not bem-tools
First of all, using bem-tools in rails application you get some kind of thing on the side that doesn’t obey you, you are not a JavaScript developer? Secondly, the bem-tools are pulling for themselves another kind of tools through npm, which is beyond your control. And the rail developer has a bundler and a gemfile. Why do I need more package managers? Using the bundler, I can always create gemsets for different projects in the usual way for myself. All dependencies come with the project in the usual way. Nothing extra is needed. I install gems and everything works for me. There are no additional directories in the root of the project, except for the block library itself. Thirdly, the assembly process in the rails is somewhat different, it has already been implemented and I would not like to change it. It would have been possible to use bem-tools only for working with the file system, but this would not have canceled the writing of independent code for rendering. In addition, it would not be possible to use templates for scammers. It is quite possible to think about the described tools as a way of organizing parshals in a rails application.
How?
Create / Delete / View
In order to create / delete / view blocks, I wrote a number of Thor tasks. I also thought that it would be useful to be able to distribute the blocks into groups. Not with pens, but from the console, and then render the blocks from the desired group:
thor bem:create -b filter -G search
And now it’s possible to create blocks / elements / modifiers in such a way, and modifiers can be with or without values:
thor bem:create -b test thor bem:create -b test -e icon thor bem:create -b test -m large thor bem:create -b test -m color -v red thor bem:create -b test -e icon -m file thor bem:create -b test -e icon -m size -v small thor bem:create -b test -e icon -m size -v small -T sass
Deletion is similar:
thor bem:remove -b test ...
View existing blocks:
thor bem:list thor bem:list -G search thor bem:list -b test ...
For myself, I decided to change the block file structure slightly. I decided to place the block elements in the / elements directory, and the modifiers in / mods. It seemed to me more convenient than keeping everything in one directory. You can go back at any time. Now the block directory is automatically created in the root of the application rails and looks like this:
File structureblocks
- block_name
- elements
- __element_name
- __element_name.html.haml
- __element_name.css.sass
- __element_name.coffee
- __element_name.md
- mods
- _mod_name
- _mod_name.css.sass
- _mod_name.coffee
- _mod_name.md
- block_name.html.haml
- block_name.css.sass
- block_name.coffee
- block_name.md
- group_name
It is also quite good to have a description for each block / element / modifier, and in the usual markdown. Regardless of the technologies that I personally use, you can use your own, those that have long been accustomed to. For this, I created an initializer in which I defined all the BEM settings. There you can edit everything for yourself, including prefixes for blocks / elements / modifiers.
Rendering
Fortunately there are helpers in the rails. Thanks to them and hashes, it’s possible to render blocks in HAML views like this:
= b "test", mods: [{color: "red"}], content: [{ elem: "icon", elemMods: [{size: "small"}] }] = b "test", mods: [{color: "red"}], content: [{ block: "yeah", content: ["Hello, BEM!"] }] = b "test", group: "name", mods: [:large, {color: "red"}], content: [] = b "test", cls: "custom", attrs: {"data-toggle": "modal"}, content: [] = b "test", tag: "article", content: []
In my opinion it looks like BEMHTML and this is good news. For the slim, haml, sass, coffee, md technologies I created the templates. After creating the block, the haml template (for example) will become the implementation of the block on the haml technology. In the image and likeness, you can create templates for all technologies that interest you.
And assets?
With Assets, everything is solved very simply. You can add any directory to the scop, where style files and scripts will be searched. When creating a block / element / modifier, the lines with the definition are added to the application.css.sass and application.js files, for example:
The rest of the work is done by Sprockets. For everything to work well, it is highly recommended not to write styles and scripts in the application.css.sass and application.js files. Use them as configs, only for a list of what is used. It is convenient and without BEM. This approach allows you to forget about the declaration of the used blocks / elements / modifiers in principle. Everything happens automatically. You can forget about deps.js. Try it!
Production
You can try using this toolkit now. I designed them in the form of a heme, which you can set to your project and use BEM today. Link to githab: bem
-on-rails .
Plans
- Flags bem and js.
- Mixing blocks and elements.
- Modifiers with a block structure change. So far, only style and javascript.
- Bem from the command line. Running tasks through Thor has its drawbacks.
Profit
Having a directory with blocks as a git repository, you can connect your blocks to any projects. The implementation of a block / element / modifier can be either on the familiar technologies for rails or on the usual for PHP. You can use the same block repository in all of your projects on Ruby on Rails (which I would really like), and in any other projects involving the use of BEM. This toolkit is designed to expand the sphere of influence of BEM on such a wonderful framework as Ruby on Rails.
I would welcome any comments and any help. Thanks for attention!
Stay BEMed!