Tales from the Library, Part 2

With Special Guest, Hairy Styles

This is the second in a series of mini-articles about a component library we recently completed. If you missed the first article, you can get caught up here.

A brief recap: we’re making a component library for a 3rd party, and we need to optimize for reusability and code clarity. We took some time to lay out tools, namely SCSS, a beefed-up CSS that gives your stylesheets some serious power. We’re talking features like variables, functions, and loops — powerful constructs that aren’t available in traditional stylesheets.

In this installment, we’ll cover a few best practices for stylesheets when creating or adding to a component library.

Keeping Stylesheets Sassy

If you’re new to the language, it’s important to know that SCSS actually gets translated into plain old CSS when your website gets built. This means that even if you’ve already written a ton of CSS, you can start integrating SCSS on top of your solution right now.

The SCSS GitHub page has helpful steps to add the compiler to your build process via Webpack or similar.

metaphor

Naming, Hierarchy, Composition

On this project, we chose to name DOM classes using the Block, Element, Modifier (BEM) methodology. This does wonders to mitigate naming conflicts. Since we’re building components to be used elsewhere, we need to make sure our stylesheets don’t have any impact on their surroundings.

It’s not strictly required by BEM standards, but we also recommend keeping selectors in a flat hierarchy. It’s far easier to reason about a single level of rules than to follow a chain of cascading styles.

What’s more, by adhering to BEM and a flat stylesheet, you naturally end up keeping all of a selector’s rules in one place. So you spend less time Ctrl+Fing for bugs!

Colors and Typefaces

Colors and typefaces can be defined during the design phase. System-wide style definitions like colors or fonts should be centralized and generically named. There’s a quote from this killer article by our friends at thoughtbot:

Name your reusable color variables — or functions, for that matter — based on their semantic role. For instance use names such as primary,brand-color, and border-colorinstead of light-gray, darker-red, and gray-2.

SCSS lets us define named variables right in the stylesheet, and we do just that with color names in a separate file, called a partial.

Media Queries as Mixins

To handle responsiveness, we like to build to at least three different screen sizes, which of course are handled through media queries and breakpoints.

Here’s a bit of CSS to resize text based on screen width. Notice how we have to split the class into three selectors:

Now let’s upgrade to SCSS! With clever use of mixins, traditional media queries can be abstracted into size classes. We can call those size classes small and large, and put them in their own partial:

Elsewhere, in component stylesheets:

What screen sizes you define are up to you, but we’re fans of the Foundation screen sizes by the folks at ZURB. With centralized and reusable breakpoint selectors, screen sizes are super configurable, and it’s a breeze to add more.

Another Chapter

Join us for our next installment, where we’ll talk about a package called Storybook, and how you can use it to make a nice little house for your carefully crafted components.

Tales from the Library, Part 3: The Neverending Storybook

Find us on Facebook, Twitter, and Instagram or get in touch at thirteen23.com.