Understanding the CSS Modules Methodology

In the ever-changing world of front-end development, it is quite hard to find a concept that actually makes a difference, and to introduce it correctly enough so that other people are actually willing to try it.

When we look at CSS, I would say the last big shift that happened in the way we write CSS (on the tooling side) would have to be the arrival of CSS processors, mostly Sass, probably the most well-known one. There’s also PostCSS, which has a slightly different approach but ends up essentially in the same basket – browser-unsupported syntax goes in, browser-supported syntax goes out.

Now a new kid has joined the block under the name CSS Modules. In this article, I’d like to introduce this technique, tell you why it has some good points, and how you can get started with it.

What is a CSS Module?

Let’s start with the explanation from the official repository:

A CSS Module is a CSS file in which all class names and animation names are scoped locally by default.

Now, it is a little more complex than that. Because class names are scoped locally by default, it involves some setup, a build process, and a bit of magic that is sometimes hard to grasp.

But eventually, we can appreciate CSS Modules for what they are: a way to scope CSS to a component and escape the global namespace hell. No more struggling to find a good way to name your components, because the build step is doing that for you!

How does it work?

CSS Modules need to be piped in a build step, which means they do not work by themselves. See this as a plugin for either webpack or Browserify. It basically works this way: when you import a CSS file inside a JavaScript module (such as, but not necessarily, a React component), CSS Modules will define an object mapping class names from the file to dynamically scoped/namespaced class names that can be used as strings in JavaScript. Allow me to illustrate with an example:

Below is a very simple CSS file. The .base class does not have to be unique on the project as it is not the actual class name that will be rendered. It is just a kind of alias inside the stylesheet to be used in the JavaScript module.

[code language="css"]
.base {
color: deeppink;
max-width: 42em;
margin: 0 auto;
}
[/code]

And here is how you would use it in a dummy JavaScript component:

[code language="javascript"]
import styles from './styles.css';

element.innerHTML = `<div class="${styles.base}">
CSS Modules are fun.
</div>`;
[/code]

Eventually, this will generate something like this (when using it through webpack with the default setup):

[code language="html"]
<div class="_20WEds96_Ee1ra54-24ePy">CSS Modules are fun.</div>
[/code]

[code language="css"]
._20WEds96_Ee1ra54-24ePy {
color: deeppink;
max-width: 42em;
margin: 0 auto;
}
[/code]

The way class names are generated can be configured to make them shorter, or to follow a specific pattern. It doesn’t really matter in the end (although shorter class names mean shorter stylesheets) because the point is that they are dynamically generated, unique, and mapped to the correct styles.

Continue reading %Understanding the CSS Modules Methodology%

by Hugo Giraudel via SitePoint