CSS can be challenging at scale. This fact is evident based on the number of
solutions people have come up with to make it easier to deal with. The biggest
challenge with CSS is this:
How can you be sure your CSS changes aren’t having an unexpected impact?
This is due to the “C” part of CSS: “Cascading Style Sheets”. I’ve been doing
this web dev thing since around 2013. I’ve been through just about every
solution for this CSS challenge you can think of. From regular CSS with good
naming conventions, through pre-processors, css-modules, css-in-js, and utility
css classes.
In my post
How I built a modern website in 2021,
I explain that this website uses Tailwind CSS for
styling. I couldn’t be happier with this because it makes it so easy for me to
have a maintainable and consistent styling solution all in around 12kbs of CSS
for the whole site.
So my site isn’t really taking advantage of the feature I’m about to show you,
but I want to tell you all about it anyway because it’s a brilliantly simple
feature unique to Remix that has a profound impact on developer productivity and
performance.
Ok, so let’s say that on my About Me page, I wanted to customize the
styling of something. For example, what if I wanted to make all the h1s blue?
If you wanted to do that on your own about page, how would you do it? If you’re
using CSS-in-JS, let’s imagine for a moment that you’re not. So you’d probably
want to do something like this:
.about-page h1 {
color: blue;
}
And then you’d make sure you have the about-page class name applied somewhere
high in your DOM tree.
Why the about-page class name? To namespace it right? You wouldn’t want to
have h1s on other pages to suddenly all be blue. But let’s think about the
problem here. We only need this CSS to be on the page when the user’s on the
/about page right? So why do we even have the CSS on the other pages? Wouldn’t
it be better if we just… like… don’t have the CSS on any page other than the
/about page?
And I’m not talking about just lazy-loading the CSS or anything. That’s not
enough. We need the CSS to not only arrive in the browser when the user gets to
the /about page but also make sure it’s removed from the page when the user
navigates away from the /about page.
And that is the magic ingredient of Remix’s anti-clash potion. Observe:
Allow me to describe what’s happening in this gif. We start on the /about page
and there’s a <link /> tag for a about-[hash].css file. That file’s making
our h1 title blue. Then when we navigate to the homepage, that <link /> tag
is removed from the page and the h1 is restored to its regular white color.
Pretty simple right? When I first saw this I just sat there processing what I
was seeing. It’s almost too simple and I’m almost mad I never thought about it.
I expect Remix isn’t the first to ever have this idea, but it’s certainly not a
popular idea. I don’t know of any other frameworks or tools that enable this.
Let me take it a step further though. Just in case it’s not clear how profound
this is. Here’s how this works from a code standpoint:
import type {LinksFunction} from 'remix'
import aboutStyles from '~/styles/routes/about.css'
export const links: LinksFunction = () => {
return [{rel: 'stylesheet', href: aboutStyles}]
}
export default function AboutScreen() {
return <stuff />
}
In remix, when you import a .css file, it gives you back a URL.
What this route module does is tell Remix: “When this route is active on the
page, here are the link tags I need on the page.” And Remix ensures that those
link tags are on the page and also that they’re removed from the page when
that route is not active.
So what does this mean in practice? It means that when you’re working in a CSS
file, you can find exactly where it’s being used (which routes it’s being used
in) and you know exactly what impact your changes will have.
In practice, you typically will have your CSS file used on a single route, so
there’s normally only one page you need to worry about. So you can freely
develop your CSS without worrying that your changes are impacting any other page
than the one you’re looking for. You don’t need to even follow a namespace
convention if you don’t want to. You don’t need a tool to auto-namespace your
CSS styles for you. And Remix isn’t doing anything to your CSS either. It’s just
loading and unloading your CSS for you.
But what about the CSS for reusable components? For these, you’ll need to make
sure their CSS files are on every page you use the component. In practice, it’s
most likely you’ll just want this on every page so you can put it in your root
route so it’s on every page. Once you do that, you have to acknowledge that when
you make a change to that file (or any other CSS file you load on the root
route) will be active on every page (which again, is what you want 😅).
In this case it’s actually less about reusable components and more about
remembering to think about the pages where the CSS file appears and ensure
you’re properly namespacing relative to the other CSS files that will be on the
pages your CSS file is active on.
The point of this post is more to call out this fact:
With Remix, it’s possible to be explicit about the pages upon which your CSS
file is active and it’s possible to statically determine those pages for a
given CSS file.
Having a predictable outcome to
the changes you’re making is a huge win for maintainability.
As mentioned, this website is using Tailwind. Before this site, I had never used
tailwind. But Stephan recommended that we go with it. I figured it
might make us productive as we got started, then I could back out of tailwind
over time later and use this feature of Remix.
By the end of it I realized that Tailwind does more than side-step the Cascade
clashing issues, it also gives you a great set of constraints to keep your UI
looking consistent. So I decided to keep it.
So what do I recommend? I suggest you skip to the end and use Tailwind. But when
you’re in need of some one-off styles (or if you really don’t want to use
Tailwind), it’s really nice to know that Remix has your back for that sort of
thing making for a stellar maintainable CSS solution.
Source link
