Choosing A Styling Method with for my React based Design System
There a bunch of new tools to add styles to your react component. Being relatively new to React, and getting an opportunity to create a design system, I started to scour the inter-webs for information.
Methods to include styles:
- css stylesheets (good old css, scss, sass, or less)
- inline styles (css-in-js)
- css modules (css, scss, sass, or less)
- styled-components (css-in-js)
This article does a great job of showing the differences: Four ways to style react components
Tools to Implement react Styling Methods:
Note: these are just some of the tools out there
My Design System Choice: Css Modules
I personally opted for using css modules using scss.
Reasons included:
- it’s faster (see this Use CSS Modules instead of inlining styles in React they test the rendering of 10,000 squares)
- less learning curve and abstraction
- less code duplication (Generated code often create new css from merging styles to avoid naming conflicts. Traditional css just uses priority instead of generating new css for every combination use case.)
- I don’t have to write css-in-js (The syntax is quite annoying, getting things like pseudo-element support sometimes isn’t supported. As well as the fact that if your IDE doesn’t have css-in-js autocomplete, it just slows you down)
- it’s included in with react-create-app (see here)
- lastly at the end of the day everything compiles down to css. By keeping things close to the basics, you know you can use the latest features. Tools might take time to be able to compile JavaScript into the new css.
Gajus Kuizinas, the author of react-css-modules also mentions a bunch of reasons in Stop using CSS in JavaScript for web development.
At the end of the day there’s no wrong answer. If you can get a project up and running and it works for you do it.
Another thing about design systems is that your components are like a black-box. You can change the wiring from one tool set to another at anytime. If a better tool comes out, you can change to it. The users don’t care so long as it continues to work. Just make sure to test it, and not change the API for your component.
Ideally you shouldn’t need customize a design system component you imported into your code base. But that’s often not the case. Therefore, I try to design my components to be compatible with other tool sets I know we use. Ex: one project uses emotion’s css prop, therefore I made sure that the class name generated by emotion gets added to the classNames prop in the component. (note: things like position and margin should be applied to a wrapper around your component, things like style, that remain the same per use case should be coded into your design system)
