I’ve been riding the CSS-in-JS train for years (I was even a significant contributor to the “movement”). It’s awesome. I’ve never been so productive working with CSS than when I added a real programming language to it.
I’m still a fan of CSS-in-JS, and in recent years, the CSS spec has evolved and improved a lot and modern browsers have too (unfortunately, Internet Explorer is NOT a modern browser in this or any context). Often I’d use a ThemeProvider (like those found in emotion), but turns out there aren’t a whole lot of advantages to that kind of component for many use cases and there are several disadvantages.
Let’s look at a simple example of “Dark Mode” and compare differences in API (developer experience) and performance (user experience). We’ll keep the example simple, and in both the before/after, we’ll be using emotion’s styled utility. Keep in mind that with the ThemeProvider you can consume the values using the useTheme hook, with a styled component, or with the css prop. With CSS Variables, you can get the values in your CSS with var(--css-variable-name) and in your JavaScript using getComputedStyle(element).getPropertyValue('--css-variable-name') (which you really don’t need to do…)
Ok, let’s look at some code. Here’s an approach to using emotion’s ThemeProvider:
import * as React from ‘react’
import styled from ‘@emotion/styled’
import {ThemeProvider} from ’emotion-theming’
const themes = {
light: {
colors: {
primary: ‘deeppink’,
background: ‘white’,
},
},
dark: {
colors: {
primary: ‘lightpink’,
background: ‘black’,
},
},
}
const PrimaryText = styled.div(({theme}) => ({
padding: 20,
color: theme.colors.primary,
backgroundColor: theme.colors.background,
}))
function ThemeToggler({theme, onClick}) {
const nextTheme = theme === ‘light’ ? ‘dark’ : ‘light’
return (
<button onClick={() => onClick(nextTheme)}>
Change to {nextTheme} mode
</button>
)
}
function App() {
const [theme, setTheme] = React.useState(‘light’)
return (
<ThemeProvider theme={themes[theme]}>
<PrimaryText>This text is the primary color</PrimaryText>
<ThemeToggler
theme={theme}
onClick={(nextTheme) => setTheme(nextTheme)}
/>
</ThemeProvider>
)
}
export default App
What’s cool about this is it’s “just JavaScript” so you get all the benefits of variables etc. But we’re not really doing all that much with this other than passing it around through the ThemeProvider. (To be clear, the way the ThemeProvider works is it uses React’s Context API to make the theme accessible to all emotion components without having to pass props all over the place).
Let’s compare this with the CSS Variables approach. But before we get to that, I need to mention that there’s no “ThemeProvider” for this. Instead, we define the variables in regular CSS that will get applied based on a data attribute we apply to the body. So here’s that css file:
body[data-theme=‘light’] {
–colors-primary: deeppink;
–colors-background: white;
}
body[data-theme=‘dark’] {
–colors-primary: lightpink;
–colors-background: black;
}
Alright, so with that, here’s the implementation of the exact same UI:
import * as React from ‘react’
import ‘./css-vars.css’
import styled from ‘@emotion/styled’
const PrimaryText = styled.div({
padding: 20,
color: ‘var(–colors-primary)’,
backgroundColor: ‘var(–colors-background)’,
})
function ThemeToggler() {
const [theme, setTheme] = React.useState(‘light’)
const nextTheme = theme === ‘light’ ? ‘dark’ : ‘light’
React.useEffect(() => {
document.body.dataset.theme = theme
}, [theme])
return (
<button onClick={() => setTheme(nextTheme)}>
Change to {nextTheme} mode
</button>
)
}
function App() {
return (
<div>
<PrimaryText>This text is the primary color</PrimaryText>
<ThemeToggler />
</div>
)
}
export default App
Let’s first compare what it’s like to use these values:
const PrimaryText = styled.div(({theme}) => ({
padding: 20,
color: theme.colors.primary,
backgroundColor: theme.colors.background,
}))
const PrimaryText = styled.div({
padding: 20,
color: ‘var(–colors-primary)’,
backgroundColor: ‘var(–colors-background)’,
})
There’s not really much of a difference from a DX (development experience) standpoint here. One point for the CSS Variables approach is not having to create a function that accepts the theme and returning styles (and no need to even learn about that API).
One point for the ThemeProvider approach is if you’re using TypeScript you could get type safety on your theme… But ummm… Check this out:
const theme = {
colors: {
primary: ‘var(–colors-primary)’,
background: ‘var(–colors-background)’,
},
}
export {theme}
import {theme} from ‘theme’
const PrimaryText = styled.div({
padding: 20,
color: theme.colors.primary,
backgroundColor: theme.colors.background,
})
BOOM. Static typing-friendly.
Either way, that’s really the only significant DX difference. Let’s consider the UX (user experience) difference. Why don’t you play around with it:
You’ll notice there’s not really any observable UX difference, and there’s not for this simple example. But why don’t you try this with me:
- pop open the React DevTools Profiler
- Start a profiling session (click the little circle)
- Click the toggle button for each
- Stop the profiling session
- Compare the two commits
Here’s what I see:
ThemeProvider:
CSS Variables:
I don’t want you to get hung up on the number of milliseconds to rerender. This isn’t a controlled benchmark (we’re in React’s dev mode for one thing). The thing I want you to consider is how many components needed to re-render for this change. Let’s consider the ThemeProvider approach first. The main reason for this is the way we’ve structured our state (we could restructure things and improve it a little bit). But even if we restructured things, when the theme changes, every emotion component needs to be re-rendered to account for the theme change.
Turning to the CSS Variables approach, you’ll notice the only component that re-rendered was our ThemeToggler component responsible for updating the body. And yet the user experience works perfectly! This is the magic behind CSS variables. With the ThemeProvider approach, we have to update the styles of every component, and then the browser paints those updates. But with the CSS Variables approach, we update the styles to a single component (the body) and then the browser paints those updates. The browser paint should theoretically take the same amount of work on the part of the browser, so the only difference is how much work we’re making the browser do to have React re-render all our components and get emotion to update the styles of every component.
This can have negative performance implications as your app grows. Considering the DX isn’t objectively better or worse either way, but the UX is quite possibly better with CSS Variables, I feel comfortable recommending CSS Variables over using Context to share a theme like this.
Oh, and consider also that CSS Variables are part of the browser spec and the ThemeProvider isn’t. That’s another solid point for CSS Variables ????
This is one standard I’d suggest you embrace.
One last piece of nuance here. What if you not only want to change styles but also want to change component implementations based on the theme? In this case… YOU CAN DO BOTH! The benefit of doing this is the only components that need to consume the context value are those that need to render differently based on the theme (which is likely a small subset). Most components can use the css variables for styling purposes only, so you’ll still get the aforementioned benefits. If you don’t need components to render differently based on the theme then I wouldn’t bother with this, but if you do, then it’s pretty simple to do. There are several ways to accomplish this, I’ve done one implementation in the codesandbox. Enjoy exploring that.
CSS variables (custom properties) are awesome. Give them a look. Good luck!
