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.
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
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
large, and put them in their own partial:
Elsewhere, in component stylesheets:
What screen sizes you add 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.
Join us for our next installment of library hacks, 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.