avatarTom Smykowski

Summary

The article discusses the relevance of using CSS BEM methodology in Angular applications, suggesting that Angular's inherent component scoping renders BEM's block naming convention largely unnecessary and potentially indicative of poor practice.

Abstract

The article "Should I use CSS BEM with Angular? part I" examines the compatibility of the BEM (Block Element Modifier) methodology with Angular development. BEM is praised for its benefits such as flexibility, robustness, and ease of use, yet the article points out that Angular's default scope isolation for component CSS diminishes the need for BEM's block naming to prevent CSS conflicts. It argues that in Angular, the use of block names may signal poor architectural decisions, as the framework encourages breaking down substantial components into smaller, reusable components through composition. This approach aligns with Angular's best practices, promoting better maintainability, testability, and scalability. The article concludes that the block aspect of BEM is almost obsolete in Angular, as the framework naturally avoids CSS conflicts and encourages the sharing of entire components rather than just CSS.

Opinions

  • The author suggests that the use of BEM's block naming in Angular is often a sign of bad practice, as it contradicts Angular's component-based architecture.
  • Angular's default scope isolation for component CSS eliminates the primary need for BEM's block naming, which is to avoid CSS conflicts.
  • The article emphasizes that Angular's method of handling CSS through component scoping makes the block part of BEM almost useless.
  • It is recommended to use Angular's component composition to create a more flexible and maintainable architecture, rather than relying on BEM's block naming.
  • The author posits that copying CSS between components is not a best practice in Angular and that component libraries should be used for sharing code across projects.
  • The article invites readers to comment on any scenarios where BEM's block element could be helpful in Angular without compromising Angular's best practices.

Should I use CSS BEM with Angular? part I

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!

CSS
Scss
Angular
Web Development
Front End Development
Recommended from ReadMedium