CSS – 3 things about a component approach

Managing our stylesheets in teams, even with Sass or LESS, isn’t as easy as you might think. More developers involved in the project = more shitty code and more mess produced. But how can we improve and maintain this in a better way? Sass can be helpful, but on its own it isn’t enough.

Working on big projects with raw CSS can be a pain in the ass, so, as front-end developers, we always look for tools and solutions that improve our design process. Sass is one of them – we love working with it and nowadays cannot imagine stylesheets without pre-processors, but a true key for reusable and readable CSS is a consistent component approach.

1. Modularity

To keep our code more reusable, scalable, and generally better structured it is extremely important to write our classes using a component (modular) approach. The most common problem with our stylesheets is “page based coding” – during development we mainly focus on the page currently being developed, completely forgetting about modularity. The results can be deadly for our project – boilerplate code, repetitions, problems with extending, wrong semantics, and much much more…

So, what is the key to good modularity? Thinking outside the bubble – think globally, not locally. Most of the design components should end up as modules and should be designed to stand alone for greater flexibility. We always have to remember – Front-end doesn’t work alone, we should work with our graphic designer in order to achieve consistent components.

2. Kitchen sink

Speaking of the modular approach. “Kitchen sink” is a term closely connected with component based styling. In brief, it represents a place where we collect all components written during the project development phase. Let me demonstrate with a simple workflow example:

1. create new component directly in the kitchen sink;
2. comment it – describe it using sample HTML structure;
3. add it to the project;
4. love your kitchen sink – your team will love you too.

Of course making and maintaining additional pages requires extra work, but believe me – it’s worth burning the midnight oil, especially when you stand in front of a big project.

One Page to rule them all, One Page to find them. One Page to bring them all and in the light bind them

Yup, we love fixing someone’s CSS…

3. Consistent methodology

An inconsistent coding style can be frustrating – for you and your team. There are many methodologies that were created to help front-ends build a better web. We have Object Oriented CSS (OOCSS), Scalable and Modular Architecture for CSS (SMACSS) and Block Element Modifier (BEM). Describing each of them in turn could take quite a while, so I will quickly sum them up – none are perfect. Speaking of the component approach, especially for teams, the BEM methodology is probably the most suitable in this case. It helps you achieve reusable components and code sharing in the front-end, but not only in CSS… Let’s try to describe it in few sentences;

The methodology is based on 3 highly connected parts: blocks, elements and modifiers:

Block is basically treated as an entity which can contain other entities. The official BEM documentation describes it more detail:

Block encapsulates a standalone entity that is meaningful on its own.

I think the last part of this quote is the key to good modularity. Properly structured and named components streamline the front-end developing process and help new people enter into the project.

Elements are semantically connected with blocks, which perform certain functions. We have to keep in mind that most of the elements are context dependent so removing them breaks a built block.

Modifiers are used for creating modifications to currently available blocks. In real projects, we can use them to change some parts of their appearance, behaviours or even states.

In practical CSS in could look like this:

.block { 
   // entity styles
}

.block__element { 
   // entity elements styles
}

.block--modifier { 
    // entity modifications
}

If I was to go into details, it could easily be a separate book, so, if you’re genuinely interested in this subject in more detail, check out the official BEM documentation.

Should we follow style guides?

Definitely, but they are only intended as direction. In the real process, we can incorporate some of the rules and extend them into our personal workflow. Following strict guides is good for the beginning, but after several projects we should start detecting new, better ways that fit our development process.

Józef Flakus

Front End Developer