In the previous post in this two-part series, we explored the CSS-in-JS landscape and, we realized not only that CSS-in-JS can produce critical styles, but also that some libraries don’t even have a runtime. We saw that user experience can significantly improve by adding clever optimizations, which is why this series focuses on developer experience (the experience of authoring styles).
In this part, we’ll explore the tools for "plain ol’ CSS" by refactoring the Photo component from our existing example.
Controversy and #hotdrama
One of the most famous CSS debates is whether the language is fine just the way that it is. I think this debate stays alive because there is some truth to both sides. For example, while it’s true that CSS was initially designed to style a document rather than components of an application, it’s also true that upcoming CSS features will dramatically change this, and that many CSS mistakes stem from treating styling as an afterthought instead of taking time to learn it properly or hiring someone who’s good at it.
I don’t think that CSS tools themselves are the source of the controversy; we’ll probably always use them to some extent at the very least. But approaches like CSS-in-JS are different in that they patch up the shortcomings of CSS with client-side JavaScript. However, CSS-in-JS is not the only approach here; it is merely the newest. Remember when we used to have similar debates about preprocessors, like Sass? Sass has features, like mixins, that aren’t based on any CSS proposal (not to mention the entire indented syntax). However, Sass was born in a much different time and has reached a point where it’s no longer fair to include it in the debate because the debate itself has changed — so we started criticizing CSS-in-JS because it’s an easier target.
I think we should use tools that let us use proposed syntax today. Let’s use JavaScript Promises as an analogy. This feature isn’t supported by Internet Explorer, so many people include a polyfill for it. The point of polyfills is to enable us to pretend like the feature is supported everywhere by substituting native browser implementations with a patch. Same goes for transpiling new syntax with tools, like Babel. We can use it today because the code will be compiled to an older, well-supported syntax. This is a good approach because it allows us to use future features today while pushing JavaScript forward the way preprocessing tools, like Sass, have pushed CSS forward.
My take on the CSS controversy is that we should use tools that enable us to use future CSS today.
Preprocessors
We’ve already talked a bit about CSS preprocessors, so it’s worth discussing them in a little more details and how they fit into the CSS-in-JS conversation. We have Sass, Less and PostCSS (among others) that can imbue our CSS code with all kinds of new features.
For our example, we’re only going to be concerned with nesting, one of the most common and powerful features of preprocessors. I suggest using PostCSS because it gives us fine-grained control over the features we’re adding, which is exactly what we need in this case. The PostCSS plugin that we’re going to use is postcss-nesting because it follows the actual proposal for native CSS nesting.
The best way to use PostCSS with our compiling tool, webpack, is to add postcss-loader after css-loader in the configuration. When adding loaders after css-loader, it’s important to account for them in the css-loader options by setting importLoaders to the number of succeeding loaders, which in this case is 1:
{
test: /\.css$/,
use: [
'style-loader',
{
loader: 'css-loader',
options: {
importLoaders: 1,
},
},
'postcss-loader',
],
}
This ensures that CSS files imported from other CSS files will be processed with postcss-loader as well.
After setting up postcss-loader, we’ll install postcss-nesting and include it in the PostCSS configuration:
yarn add postcss-nesting
There are many ways to configure PostCSS. In this case, we’re going to add a postcss.config.js file at the root of our project:
module.exports = {
plugins: {
"postcss-nesting": {},
},
}
Now, we can write a CSS file for our Photo component. Let’s call it Photo.css:
.photo {
width: 200px;
&.rounded {
border-radius: 1rem;
}
}
@media (min-width: 30rem) {
.photo {
width: 400px;
}
}
Let’s also add a file called utils.css that contains a class for visually hiding elements, as we covered in the the first part of this series:
.visuallyHidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
white-space: nowrap;
}
Since our component relies on this utility, let’s include utils.css to Photo.css by adding an @import statement to the top:
@import url('utils.css');
This will ensure that webpack requires utils.css, thanks to css-loader. We can place utils.css anywhere we want and adjust the @import path. In this particular case, it’s a sibling of Photo.css.
Next, let’s import Photo.css into our JavaScript file and use the classes to style our component:
import React from 'react'
import { getSrc, getSrcSet } from './utils'
import './Photo.css'
const Photo = ({ publicId, alt, rounded }) => (
<figure>
<img
className={rounded ? 'photo rounded' : 'photo'}
src={getSrc({ publicId, width: 200 })}
srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
sizes="(min-width: 30rem) 400px, 200px"
/>
<figcaption className="visuallyHidden">{alt}</figcaption>
</figure>
)
Photo.defaultProps = {
rounded: false,
}
export default Photo
While this will work, our class names are way too simple and they will most certainly clash with others completely unrelated to our .photo class. One of the ways of working around this is using a naming methodology, like BEM, to rename our classes (e.g. photo_rounded and photo__what-is-this--i-cant-even) to help prevent clashes from happening, but components quickly get complex and class names tend to get long, depending on the overall complexity of the project.
Meet CSS Modules.
CSS Modules
Simply put, CSS Modules are CSS files in which all class names and animations are scoped locally by default. They look a lot like regular CSS. For example, we can use our Photo.css and utils.css files as CSS Modules without modifying them at all, simply by passing modules: true to css-loader’s options:
{
loader: 'css-loader',
options: {
importLoaders: 1,
modules: true,
},
}
CSS Modules are an evolving feature and could be discussed at even greater length. Robin’s three-part series on it is a good overview and introduction.
While CSS Modules themselves look very similar to regular CSS, the way we use them is quite different. They are imported into JavaScript as objects where keys correspond to authored class names, and values are unique class names that are auto-generated for us that keep the scope limited to a component:
import React from 'react'
import { getSrc, getSrcSet } from './utils'
import styles from './Photo.css'
import stylesUtils from './utils.css'
const Photo = ({ publicId, alt, rounded }) => (
<figure>
<img
className={rounded
? `${styles.photo} ${styles.rounded}`
: styles.photo}
src={getSrc({ publicId, width: 200 })}
srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
sizes="(min-width: 30rem) 400px, 200px"
/>
<figcaption className={stylesUtils.visuallyHidden}>{alt}</figcaption>
</figure>
)
Photo.defaultProps = {
rounded: false,
}
export default Photo
Since we’re using utils.css as a CSS Module, we can remove the @import statement at the top of Photo.css. Also, notice that using camelCase to format class names makes them easier to use in JavaScript. If we had used dashes, we’d have to write things out in full, like stylesUtils['visually-hidden'].
CSS Modules have additional features, like composition. Right now, we’re importing utils.css into Photo.js to apply our component styles, but let’s say that we want to shift the responsibility of styling the caption to Photo.css instead. That way, as far as our JSX code is concerned, styles.caption is just another class name; it just so happens to visually hide the element, but it might be styled differently in the future. Either way, Photo.css will be making those decisions.
So let’s add a caption style to Photo.css to extend the properties of the visuallyHidden utility using composes:
.caption {
composes: visuallyHidden from './utils.css';
}
We could just as well add more rules to that class, but this is all we need in this case. Now, we no longer need to import utils.css into Photo.js; we can simply use styles.caption instead:
<figcaption className={styles.caption}>{alt}</figcaption>
How does this work? Do the styles from visuallyHidden get copied over to caption? Let’s examine the value of styles.caption — whoa, two classes! That’s right: one is from visuallyHidden and the other one will apply any other styles we add to caption. CSS-in-JS makes it too easy to duplicate styles with libraries, like polished, but CSS Modules encourage you to reuse existing styles. No need to create a new VisuallyHidden React component to only apply several CSS rules.
Let’s take it even further by examining this uncomfortable class composition:
rounded
? `${styles.photo} ${styles.rounded}`
: styles.photo
There are libraries for these situations, like classnames, which are useful for more complex class composition. In our example, though, we can keep on using composes and rename .rounded to .roundedPhoto:
.photo {
width: 200px;
}
.roundedPhoto {
composes: photo;
border-radius: 1rem;
}
@media (min-width: 30rem) {
.photo {
width: 400px;
}
}
.caption {
composes: visuallyHidden from './utils.css';
}
Now we can apply the class names to our component in a much more readable fashion:
rounded ? styles.roundedPhoto : styles.photo
But wait, what if we accidentally place the .roundedPhoto ruleset before .photo and some rules from .photo end up overriding rules from .roundedPhoto due to specificity? Don’t worry, CSS Modules prevent us from composing classes defined after the current class by throwing an error like this:
referenced class name "photo" in composes not found (2:3)
1 | .roundedPhoto {
> 2 | composes: photo;
| ^
3 | border-radius: 1rem;
4 | }
Note that it’s generally a good idea to use a file naming convention for CSS Modules, for example using the extension .module.css, because it’s common to want to apply some global styles as well.
Dynamic styles
So far, we’ve been conditionally applying predefined sets of styles, which is called conditional styling. What if we also want to be able to fine-tune the border radius of the rounded photos? This is called dynamic styling because we don’t know what the value is going to be in advance; it can change while the application is running.
There aren’t many use cases for dynamic styling — usually we’re styling conditionally, but in cases when we need this, how would we approach this? While we could get by with inline styles, a native solution for this type of problems is custom properties (a.k.a. CSS variables). A really valuable aspect of this feature is that browsers will update styles using custom properties when JavaScript changes them. We can set a custom property on an element through inline styles, which means that it will be scoped to that element and that element only:
style={typeof borderRadius !== 'undefined' ? {
'--border-radius': borderRadius,
} : null}
In Photo.css, we can use this custom property by using var() and passing the default value as the second argument:
.roundedPhoto {
composes: photo;
border-radius: var(--border-radius, 1rem);
}
As far as JavaScript is concerned, it’s only passing a dynamic parameter to CSS, then when CSS takes over, it can apply the value as-is, calculate a new value from it using calc(), etc.
Fallback
At the time of this writing, the browser support for custom properties is... well, you decide for yourself. Not supporting these browsers is (probably) out of the question for a real-world application, but keep in mind that some styles are less important than others. In this case, it’s not a big deal if the border radius on IE is always 1rem. The application doesn’t have to look the same way on every browser.
The way we can automatically provide fallbacks for all custom properties is to install postcss-custom-properties and add it to our PostCSS configuration:
yarn add postcss-custom-properties
module.exports = {
plugins: {
'postcss-nesting': {},
'postcss-custom-properties': {},
},
}
This will generate a fallback for our border-radius rule:
.roundedPhoto {
composes: photo;
border-radius: 1rem;
border-radius: var(--border-radius, 1rem);
}
Browsers that don’t understand var() will ignore that rule and use the previous one. Don’t let the name of the plugin fool you; it only partially improves the support for custom properties by providing static fallbacks. The dynamic aspect can’t be polyfilled.
Exposing values to JavaScript
In the previous part of this series, we explored how CSS-in-JS allows us to share almost anything between CSS and JavaScript, using media queries as an example. There is no possible way to achieve this here, right?
Thanks to Jonathan Neal, you can!
First, meet postcss-preset-env, the successor to cssnext. It’s a PostCSS plugin that acts as a preset similar to @babel/preset-env. It contains plugins like postcss-nesting, postcss-custom-properties, autoprefixer etc. so we can use future CSS today. It splits the plugins across four stages of standardization. Some of the features I’d like to show you aren’t included in the default range (stage 2+), so we’ll explicitly enable the ones we need:
yarn add postcss-preset-env
module.exports = {
plugins: {
'postcss-preset-env': {
features: {
'nesting-rules': true,
'custom-properties': true, // already included in stage 2+
'custom-media-queries': true, // oooh, what's this? :)
},
},
},
}
Note that we replaced our existing plugins because this postcss-preset-env configuration includes them, meaning our existing code should work the same as before.
Using custom properties in media queries is invalid because that’s not what they were designed for. Instead we’ll use custom media queries:
@custom-media --photo-breakpoint (min-width: 30em);
.photo {
width: 200px;
}
@media (--photo-breakpoint) {
.photo {
width: 400px;
}
}
Even though this feature is in the experimental stage and therefore not supported in any browser, thanks to postcss-preset-env it just works! One catch is that PostCSS operates on a per-file basis, so this way only Photo.css can use --photo-breakpoint. Let’s do something about that.
Jonathan Neal recently implemented an importFrom option in postcss-preset-env, which is passed to other plugins that support it as well, like postcss-custom-properties and postcss-custom-media. Its value can be many things, but for the purpose of our example, it’s a path to a file that will be imported to the files PostCSS processes. Let’s call this one global.css and move our custom media query there:
@custom-media --photo-breakpoint (min-width: 30em);
...and let’s define importFrom, providing the path to global.css:
module.exports = {
plugins: {
'postcss-preset-env': {
importFrom: 'src/global.css',
features: {
'nesting-rules': true,
'custom-properties': true,
'custom-media-queries': true,
},
},
},
}
Now we can delete the @custom-media line at the top of Photo.css and our --photo-breakpoint value will still work, because postcss-preset-env will use the one from global.css to compile it. Same goes for custom properties and custom selectors.
Now, how to expose it to JavaScript? When experimental features like custom media queries get standardized and implemented in major browsers, we will be able to retrieve them natively from CSS. For example, this is how we would access a custom property called --font-family defined on :root:
const rootStyles = getComputedStyle(document.body)
const fontFamily = rootStyles.getPropertyValue('--font-family')
If custom media queries get standardized we will probably be able to access them in a similar way, but in the meantime we have to find an alternative. We could use the exportTo option to generate a JavaScript or JSON file, which we would import into JavaScript. However, that option wasn’t designed for this workflow because webpack would try to require it before it’s generated. Even if we generated it before running webpack, every update to global.css would cause webpack to re-compile twice, once to generate the output file, and once more to import it. I wanted a solution that’s unencumbered by its implementation.
For this series, I’ve created a brand new webpack loader called css-customs-loader just for you! It makes this task easy: all we need to is include it in our webpack configuration before css-loader:
{
test: /\.css$/,
use: [
'style-loader',
'css-customs-loader',
{
loader: 'css-loader',
options: {
importLoaders: 1,
},
},
'postcss-loader',
],
}
This exposes custom media queries, as well as custom properties, to JavaScript. We can access them simply by importing global.css:
import React from 'react'
import { getSrc, getSrcSet } from './utils'
import styles from './photo.module.css'
import { customMedia } from './global.css'
const Photo = ({ publicId, alt, rounded, borderRadius }) => (
<figure>
<img
className={rounded ? styles.roundedPhoto : styles.photo}
style={
typeof borderRadius !== 'undefined'
? { ['--border-radius']: borderRadius }
: null
}
src={getSrc({ publicId, width: 200 })}
srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
sizes={`${customMedia['--photo-breakpoint']} 400px, 200px`}
/>
<figcaption className={styles.caption}>{alt}</figcaption>
</figure>
)
Photo.defaultProps = {
rounded: false,
}
export default Photo
That’s it!
I created a repository demonstrating all of the concepts discussed in this series. Its readme also contains some advanced tips about the approach described in this post.
Conclusion
It’s safe to say that tools like CSS Modules and PostCSS and upcoming CSS features are up to the task of dealing with many challenges of CSS. Whichever side of the CSS debate you’re on, this approach is worth exploring.
I have a strong CSS-in-JS background, but I’m very susceptible to hype, so keeping up with that world is hard. Which library should I use now, styled-components or emotion? Also, while having styles next to the behavior can be succinct, it’s also mixing two very different languages — CSS is very verbose compared to JavaScript. This incentivized me to write less CSS because I wanted to avoid getting the file too crowded. This may be a matter of personal preference, but I didn’t want that to be an issue. Using a separate file for CSS finally gave my code some air.
While mastering this approach may not be as straightforward as CSS-in-JS, I believe it's more rewarding in the long run. It will improve your CSS skills and make you better prepared for its future.
Article Series:
- CSS-in-JS
- CSS Modules, PostCSS and the Future of CSS (This post)
The post Bridging the Gap Between CSS and JavaScript: CSS Modules, PostCSS and the Future of CSS appeared first on CSS-Tricks.
from CSS-Tricks https://ift.tt/2G0Rb7z
via IFTTT
No comments:
Post a Comment