BEM is a popular methodology for using CSS. According to the website, Block Element Modifier provides several benefits:
flexible
robust
strict
easy to use
powerful
modular
reusable
useful
easy to read
easy to understand
easy to scale
explicit
And most of all, BEM is humble :-) Having a methodology is sound. But let’s see if BEM is suitable for Angular. Just with looking at the description on the page, we can see some contradictory statements. How can something be strict and flexible at the same time?
Here is an example of a BEM notation:
.form__submit — disabled { }
The first part indicates a block (form). Second, an element (submit), and third — modifier. Also, you can notice there are fancy two underscores between block and element, and two dashes between element and modifier.
Nice, isn’t it? It looks clean and tidy. But is it suitable for Angular? Let’s see.
BEM block is often a sign of bad practice in Angular
One of BEM purposes is to avoid CSS conflicts. Say, you have two components and use the same block class for each one. Usually, it will apply the CSS to both components. You can notice it when writing vanilla websites without any framework, write Wordpress plugins. But, for example, Angular, among others, separates scopes of component CSS on default!
You can use the “header” class in multiple components at the same time without any interference whatsoever. So there is no reason to use block name in Angular CSS… or is it?
Let’s say you work on a substantial component that has multiple functional blocks. “Tom, what then?” — you ask. “I need to use block name.”. No, you should not. What you really should do is a separate component into smaller components, and use composition to separate concerns of each block. That way, your architecture will become better and flexible.
This is the Angular way of doing stuff.
And this is 100% correct. The practice also applies to a situation when you have multiple same blocks inside one component. It is a sign to move the block to a separate component. There are several benefits to this approach. The sub-component is separated, more comfortable to test, more comfortable to maintain. Other parts of the application can benefit from a component you already created, without copying HTML, CSS, or whatsoever.
This is my friend, one of the most significant benefits of Angular or any other framework. And also something that makes BEM obsolete for modern frameworks.
When you have multiple components, you have separated scopes also. Puff, the need for BEM block naming disappears? See what just happened? Using good practices makes 1/3 of BEM almost useless.
- “Ok. But what if I want to copy CSS between components?” — you’d ask. And this is also a good question. The answer is — you shouldn’t. You should not copy CSS between components. In the world of Angular, a single entity is a component (template, code, (S)CSS, and test). Not CSS separately. If you have two projects and want to copy something between these, you can use a component library instead. But if you can’t, you copy the whole component. Again, since the component keeps scoping, there won’t be any conflicts.
To sum it up, the block part of BEM is almost useless in Angular. Moreover, the need to use it is often a sign of using harmful practices.
Do you know any situations when block element can be helpful in Angular in a way it does not break Angular best practices? Write a comment below!