What is CSS-in-JS?
- The library you’re using, at runtime in the browser, compiles this into real CSS and manages the insertion (and perhaps removal) of CSS classes for you.
- You receive the generated names for these CSS classes, and you can use them in your UI library just like normal.
The usual benefits are touted to be things like the ability to:
- Side-step the entire CSS specificity rule disaster
- Co-locate your CSS with your React components
To be sure, these benefits are awesome in their own right. However, plenty of other resources around the web have covered them, so I’m going to focus on two others that have really won me over.
Type Checking and Inline Documentation
Right away, we’re able to see:
- Whether we correctly spelled the name of the CSS property
- If the value is roughly correct
- Inline documentation from MDN!
- Browser compatibility info
- All our code is loaded incrementally as the user navigates to different pages, which improves the experience of loading and using the app.
- When we do a production build, webpack prunes out dead code.
Naturally, it’s also possible to auto-complete the names of CSS properties and their values, or to hover over existing code to see documentation. It’s extremely helpful.
On our project, we are co-locating our styles with our React components and using Material-UI’s new styles package to leverage their new Hooks-based API. This is great for several reasons, but it also allows us to compute our CSS from props that are passed in to our React components. In general, our CSS isn’t even compiled (or inserted into the DOM) until it is needed to render a given component.
The net effect of all this is that you don’t need to worry about your old crufty CSS accumulating in your codebase, too afraid to delete it for fear that it will cause subtle visual bugs.