React and You: A Designer’s Point of View
Have you or a loved one been exposed to React? You may be entitled to psychological compensation.
What does a designer need to know about React?
I rode off into the night to try to get a better handle on React on my glistening steed (Google). I was faced with oodles of articles that did nothing to ease my mind. Buzz words like “virtual DOM” that may not even be buzz words, just words that made me crabby, settled like sand at the bottom of the ocean of my sad soul. I was excited to use React, but I realized that there must be other confused designers and front-end coders out there. There aren’t many resources out there for us. Documentation usually targets the ones writing the JS, not the HTML and CSS.
Once I did some more research, I found out that the problem was perhaps not a lack of resources for designers using React, but too many contrasting opinions. Information overload, at least for me, yields paralysis. If you find yourself in these shoes, here is a non-comprehensive list of the things you need to know as a designer in the React world:
- Your HTML is now called JSX
- Use classNames instead of class
Don’t question it! The big React man said we gotta do it! A simple guide to debugging: Step 1. Are you refreshing your staging instead of your localhost? Step 2: Did you type class instead of className again?
- Components need an outermost div
Don’t take it away! Your team will be sad! And you’ll probably get an error. This can make complex flexbox layouts tricky if you’re using them. But once you find ways to deal, it’s nice for organization’s sake.
- Stuff will get weird
This is the biggest given.
So once you’ve figured out how React allows you to combine everything into happy components, what’s the holdup? Well, it can be quite the predicament to figure out what to do with those gosh darn CSS stylesheets.
The React people seem to want CSS in the React component itself so that HTML, JS, and CSS can all be together and they can benefit from each other. Good design practices say something like Sass should be used to organize styles down to separate partials. Where does that leave a lone designer who just wants to make everyone and her Mama proud? How could I disappoint my designer friends and the designer within myself by using inline CSS of all things, after I’ve worked so hard to learn best CSS practices?
Pick your poison
React can be scary. It seems to go against all the CSS best practices we’ve built up as front-end coders. I thought Sass solved all my problems, but I was blind to the ways of the world. It turns out some people question the entire concept of CSS. GEEZ.
So, there’s no more avoiding the problem even though I’ve tried. Where do we actually put those pesky styles? Here are the three options I’ve found:
- Inline (CSS in JS)
This method makes the React people happy. This can be done in a few ways, but the main principle here is that your styles exist in your JSX file. These CSS properties can be written as JS objects and imported into each component OR all the way inline using something that looks like this:
<div style="margin: 20px; background-color: black;">
Pros: You’re doing things the real React way, which unlocks the power of JS in your styles.
Cons: It feels strange, can be hard for other designers and developers to follow, and can make certain CSS features like media queries less straight-forward.
- Business as usual CSS (Sass, Less, plain ol’ CSS files)
If you’re using this method, your stylesheets will most likely look like they normally do in their comfy little folder. If you use a preprocessor like Sass, stylesheets might be split into partials. If you prefer vanilla CSS, that’s cool too.
Pros: You can use your pre-processor of choice (I like Sass) and you won’t have to change much about your styling workflow.
Cons: While your HTML and JS will live in harmony, your CSS will be on an island by itself and you won’t get to unlock all the power of JS.
- CSS Modules (Somewhere in between inline and business as usual CSS)
“Modular” can be a vague word to get a grip on. In this situation, it basically means that your CSS is split into parts corresponding to each component and used specifically just for that component. This method is the one that seems the most open-ended to me. The part that is open-ended is where these styles actually go (in their own CSS files, in a JS file, or what) and how specific they need to be to their corresponding component.
Pros: It seems to be the best of both worlds.
Cons: I can’t think of a whole lot.
Sass + BEM + React = ?
Here’s what we did in my most recent project. We used Sass and BEM alongside a “traditional” file structure i.e. no CSS within JS. To me, it felt like a blend of CSS modules and business as usual method. While we did split our CSS into files that corresponded to the .jsx components, they were not scoped only to their respective components. Every Sass partial imported into the application.scss file, which was accessible by every component. Since we were using React AND Rails, the compiled CSS was imported into the main Rails view, as was the React. So basically, no CSS was written into JS directly.
This is the breakdown of our file structure:
base/ - Foundational CSS. These files flow into everything else. This includes fonts, variables, mixins, resets, transitions, typography, and utilities.
components/ - Code corresponding to specific React components. This excludes chunks of code that already exist in the base/ or modules/ folders, which tend to be styles that are used throughout the app.
modules/ - Sections of CSS that will be used in multiple places. This includes buttons, cards, forms, horizontalrule, links and select styles.
pages/ - Page-specific styles. The only single page we have is a style guide.
vendor/ - CSS from other people or frameworks.
I might try something more like the inline method in the future, but I was satisfied with my workflow doing the route that I did. I liked how each .jsx component had it’s own Sass partial with the same name, which helped keep things separate and straightforward.
There are many right ways
My biggest takeaway has been this: there are many right ways to do something. Different codebases require different solutions. Don’t exhaust yourself probing the Internet looking for someone to tell you the one correct way, because it doesn’t exist. It’s okay to break the rules if your situation warrants it.
For the philosopher:
For the CSS in JSer:
For the modular fellow:
For the Sassy:
For the CSS purist:
For the BEM fanatic:
For the tool obsessed: