3 Ways to write better Styled Components

Bring order into style chaos.

There are many ways to add styles to your frontend applications. One of the most popular ones right now is Styled Components. It not only promises us fast, non-render blocking styles, but also solving our scoping and naming issues.

While working with styled-components over the last years, I gained some more insights about said promises and how to get more out of Styled Components. Here are my Top 3.

1. Use Babel to generate better readable class names

Why should you care? I am a big fan of automating issues away to minimise repeating tasks and human error possibilities. Letting Styled Components generate class names for you is fantastic. It reduces errors by typing class a combination wrong and saves you from the need to find names for every decorative line on your website.

But the problems start evolving once you have to bug fix or change components with unreadable, always changing class names.

How to fix it: Needed is a way to identify where this component is styled, something like a prefix. There are two ways of solving.

a) use a data-attribute e.g. ‘data-componentId’ to add this information to the rendered component.

b) Let Babel add the prefix, which is the recommended way in the Styled Components documentation. Therefore you have to configure a Babel plugin.

yarn add babel-plugin-styled-components --dev

So far so good, but what if you don’t want to or can not configure babel by yourself, because you did not want to eject your create-react-app?

You still can benefit from this when using babel-macros.

yarn add babel-plugin-macro --dev

and then change your imports of styled

import styled from ‘styled-components/macro’;

2. Use a Naming Convention

Why should you care? Even though Styled Components generates the class name for you, you still have to find some name for the Component itself.

If you have many components, after a while you will get confused. Because with the automatic capsulation of your styles, you might end up with several components that have the same name.

<Button active={state} />

To add more to the confusion it could be that components with the same name are sometimes a styled component and sometimes a functional component, which both receive props.

<Button onClick={()=>{}} />

How to solve: Use a naming convention and make it a rule within in your team. For example prefix all Styled Components with the word styled; in this way, the components name already tells you what to expect.

<StyledButton active={state} />
<Button onClick={()=>{}} />

3. Choose a Clear Structure

Why should you care? No matter if you prefer SMACSS, BEM, Atomic Design or any combination of it, but when it comes to your folder structure, you should have an idea where each component is and what it does. There is no right way of structuring your application, but you should find and define rules per team and per project. Take into account the size and purpose of the project, e.g. if it is a blog, a shop or a questionnaire.

How to solve: I found the most helpful following structure for feature-focused applications like a shop.

Folder Structure suggestion

The components are divided into Library Components that are universal and partial components that are only necessary for one feature. In a Micro-Frontend Architecture, the Library folder would probably be an npm package from where the universal Styled Components will be delivered.

By not having the definition of the Styled Components inside your functional component you are making sure that your files are staying small and unit-testable. Just imagine having a snapshot test on a component which fails every time you update a single colour.

Summary

Styled Components can speed up your development process, but to be able to also maintain them as easy it is helpful to apply also rules and patterns of frontend architecture.