Will React Server Components kill CSS-in-JS? Why We Switched from Styled Components to SCSS-Modules 💀💅

Łukasz Fiuk

Jul 12 2023 9 minutes read ⏳

You might wonder... Why? 🤔😨

Before we even begin, I'd like to explain why I'm even considering switching from Styled Components to scss-modules. Over the past few years, since I first used Styled Components, I fell in love with CSS-in-JS solutions. Why? Mainly because my markup has become much more readable, and I've been able to share variables between JavaScript and my CSS. On top of that, adding dynamic styles or conditional props has been a breeze. Reusing media queries or common variables just worked, and I could use TypeScript everywhere.

So why would I even consider switching from CSS-in-JS to a more traditional approach like scss-modules? Well, there are a few reasons why some people don't like Styled Components, with the three main points of critique being:

🐌 Performance: Styled Components require a JavaScript runtime, and therefore could be slightly less performant than pure CSS.
🙆🏾‍♂️ Extra configuration / dependencies: Using Styled Components requires depending on external packages and extra configuration (not always) that doesn't work outside the React Ecosystem.
🧠 Additional abstractions: Styled Components require getting used to a new syntax, and it takes some time to become familiar with it.

I was cool with all these cons, but then Next.js 13.4 launched with React Server Components and finally stable app directory. Those Server Components bring one huge issue - we cannot render Styled Components on the server, because they rely on web APIs and React Context. That’s painful, because even though we could still use Styled Components inside “client” components, we cannot use power of RSC to its full potential as almost all of my components require some form of styling… Because of this, the Next.js team recommends using css-modules, and I'm going to stick to this recommendation.

Quick note - I know there are CSS-in-JS alternatives that could work, like Linaria, but after reading a long list of potential issues on GitHub, I decided to bite the bullet and finally go back to almost pure CSS. It's been quite a refreshing experience. 🌱

Configuration 🔧

Great, with that out of the way, let's focus on actually moving from Styled Components to scss-modules. I'm using Next.js 13.4 with an app directory, but the process should look the same if you are using older versions with pages, and it should be very similar even if you aren't using Next.js at all.

Previously, I mentioned that scss-modules doesn't require setup, but that's only partially true. You can use CSS modules in Next.js without any configuration, but I'd like to use the Sass SCSS syntax. For that, you'll need to actually install Sass as a dev dependency:

💾 >_ terminal
npm install --save-dev sass

OR if you are using yarn

💾 >_ terminal
yarn add sass --dev

Yay, you can now use scss-modules in your Next.js project! Just create files with a .module.scss extension, and import your classes into your component.

Here's a basic example:

💾 >_ txt
/1_components/
├── Button/
│   ├── Button.tsx
│   └── Button.module.scss

💾 >_ tsx
// import all classes under styles ( or different ) namespace
import styles from "./Button.module.scss"; 

const Button = ({children}) => {
  return(
    {/* apply classes */}
    <button className={styles.button}>
      {children}
    </button>
  )
}

IntelliSense Support 🤖

To make our coding lives easier, let's get IntelliSense support, so it can give us with helpful hints, such as the available CSS classes we can use. To enable this functionality, we're going to install the typescript-plugin-css-modules package.

You can install it via the npm command:

💾 >_ terminal
npm install -D typescript-plugin-css-modules

Or if you're using Yarn:

💾 >_ terminal
yarn add -D typescript-plugin-css-modules

Once installed, add this plugin to your tsconfig.json:

💾 >_ ts
{
  "compilerOptions": {
    "plugins": [{ "name": "typescript-plugin-css-modules" }]
  }
}

You'll be rewarded with these lovely auto-complete suggestions for your CSS classes: Zrzut ekranu 2023-07-13 o 19.13.40.png

Global Styles and Theming 🌐🎨

Let's start with global styles. It's as easy as creating a stylesheet and importing it into your top-level component. For me, that's the RootLayout component.

💾 >_ tsx
import “styles/globalStyles.scss”

export const RootLayout = ({children}) => {
  return(

    <body data-theme=”dark”>    {/* note data-theme attribute */}
      <main>
          {children}
      </main>
    </body>
  )
}

Theming? Piece of cake. 🍰 We'll use the data-theme attribute on our body tag. Our color palette and other constants will be stored in Sass variables, ready to be used anywhere in the project. Let's create a _palette.scss:

💾 >_ scss
/////////////////////////////////////
// Color Palette
// Names were generated by at chir.ag/projects/name-that-color/
/////////////////////////////////////

$white: #fff;
$gray: #878787;
$cod_gray: #111010;
$transparent: #00000000;

// Export the color palette to make it accessible to JS
:export {
    white: $white;
    gray: $gray;
    cod_gray: $cod_gray;
    transparent: $transparent;
}

And here's how to use these variables in our JavaScript files:

💾 >_ tsx
import variables from './_palette.scss';

Finally, let's use the power of data attributes to handle theming:

💾 >_ scss
// globalStyles.scss

body{
  [data-theme="light"] {
    --background: $white;
    --primary: $cod_gray;
    --secondary: $gray;
  }

  [data-theme="dark"] {
    --background: $cod_gray;
    --primary: $white;
    --secondary: $gray;
  }
}

And that's it! Your styles are now incredibly flexible, and it's easy to switch your design between different themes. 🎨

NOTE: I'm assigning colors to SCSS variables, so we can export our styles for usage in JavaScript. Then in the project I'm using pure css variables that will have responsive value based on current theme.

Extending Styles & Combining Classes 👪

If you've used Styled Components before, you might recognize this pattern for extending styles of certain components:

💾 >_ tsx
export const CustomButton = styled(Button)`
    color: red;
`

Good news! You can achieve similar functionality with scss-modules. However, instead of styled components, you'll pass the className prop to your components. Here's an example:

💾 >_ tsx
import clsx from "clsx"

export const Button = ({className, children}) => {
  return (
    <button className={clsx(styles.button, className)}>
       {children}
    </button>
  )
}

You might be wondering about clsx - it's a tiny utility library that allows you to construct className strings in a more intuitive way. It helps in easily combining multiple classes.

To install clsx, use the following commands:

If you are using npm:

💾 >_ terminal
npm install clsx

Or yarn:

💾 >_ terminal
yarn add clsx

Now, extending and combining classes should be super easy, just pass a className 🤓

Reusable & Consistant MediaQueries 📏

In this section, we're defining breakpoints for our layout, and creating a reusable @mixin for media queries.

💾 >_ scss
// Define your breakpoints
$tablet: 640px;
$desktop: 1024px;
$desktop-large: 1280px;

// Define your media mixin
@mixin media($breakpoint) {
  @if $breakpoint == "tablet" {
    @media (min-width: $tablet) {
      @content;
    }
  } @else if $breakpoint == "desktop" {
    @media (min-width: $desktop) {
      @content;
    }
  } @else if $breakpoint == "desktopLarge" {
    @media (min-width: $desktop-large) {
      @content;
    }
  }
}

The @mixin directive lets you create reusable chunks of CSS. In this case, we've made a mixin called media that accepts a $breakpoint parameter.

Here's how you would use this mixin:

💾 >_ scss
.example {
  font-size: 1rem;

  @include media("desktop") {
    font-size: 1.5rem;
  }
}

Please note that you'll have to import your mixins, before using them in .scss files. You can use either @import or @use but that's basic Sass so I won't explain it further.

Wrapping Up 📦

At first, leaving Styled Components behind was tough. I was a big fan of CSS-in-JS. But a few weeks into using scss-modules, I've got to say - I'm having a pretty good time. My code has gotten simpler, and it's easier to read than I first thought it would be.

I hope you had fun reading this article. If you have any questions, don't hesitate to drop them in the comments section. Cheers and happy hecking!

Comments 💬

From Bricks to Views: Hierarchical Architecture 101 🧱👨‍🏫

Why Code Structure Matters? 🤔

In the world of agile web development, code structure is the hidden hero of efficiency, maintainability, and scalability. But why architecture is it so important? Let's see:

🐣 Readability: When code is well-structured, it's easier to read and understand. This is not just beneficial for the original developer, but crucial for any one who needs to review, debug, or build upon that code.
🔁 Reusability: A good code structure promotes reusability. When we structure our code into self-contained, modular components, we can use these components in multiple places throughout our application (and beyond!).
🔧 Maintainability: You'll have to modify, fix and maintain your code. This might become a painful experience if your codebase is messy. Organized structure reduces the chance of creating bugs in seemingly unrelated parts of the application.
📈 Scalability: Clean code is easier to scale. Consistent methodology and conventions make your code predictable and therefore easy to build upon.
🧑🏻‍🤝‍🧑🏾 Collaboration: Finally a sound code structure simplifies collaboration. It's much easier to work your teammate code, if you are all working with the same patterns.

I believe that many projects suffer from a weak file structure because it's easy to overlook or ignore this aspect during the initial stages of development. However, as the project progresses, reconfiguring the structure becomes a hell of a task that nobody has the time for. ☠️

How to do it right? Quick look at Hierarchical Architecture 🤠

Here's a little sneak peek into how I like to structure my code: 📂🪄

💾 >_ txt
/src/
├── 1_components/
├── 2_sections/
├── 3_containers/
├── hooks/
├── states/
├── styles/
├── types/
├── utils/
└── anything else that you need

As you may have noticed, the first three folders are numbered. This intentional strategy aims to visually order the most critical project folders and impose a hierarchy. 👪

The core idea revolves around partitioning the project into three main blocks. Imagine constructing a house: 🏠

1_components: Components are our foundational building blocks. They should be simple, reusable, and generic. In the context of web development, a component is a reusable, self-contained piece of code that encapsulates a piece of functionality or user interface. Examples might include a Button or a Typography component.
2_sections: Sections are like the walls of our house. Each section represents a specific fragment of the page and is composed of multiple components. They are more specific than components and often contain styles and positioning unique to that section. Examples may include a Navbar, Footer, or HeroBanner.
3_containers: Containers are the rooms in our house. Each container is composed of several sections and represents a particular view, such as a HomePage, ProductPage or ProfilePage.

This approach is dead simple, readable and allows for great flexibility both for developers, and clients. In fact, it is a simplified blend of Atomic Design, and BEM methodologies - preserving their principles while emphasizing simplicity.

Rules and Definitions 🗝️

Components 🧱

Components are the basic building blocks of the application. They are self-contained, reusable pieces of code that encapsulate specific functionality or user interface elements.

No Positioning 🔺: Components shouldn't be positioned. Their placement should be determined by the parent section in which they're used.
Simplicity and Encapsulation 📐: Components should be simple and encapsulated. All things related to a single component should live within the same folder.
Generality 🐧: Components should be generic, designed to be used in multiple contexts throughout the application.
Tested 🧪: If possible, components should be tested as they will be reused in multiple places. This will help to ensure their robustness and reliability.
Extra Care ❤️: Components should be written/edited with extra care, as they are meant to be reused in many places, possibly across many projects.

Component Folder Structure Example: 🗂️

💾 >_ txt
Button/
├── Button.tsx
├── Button.styled.ts
└── Button.utils.ts

You can group components as you see fit. For example:

💾 >_ txt
Buttons/
├── PrimaryButton/
└── SecondaryButton/

Sections

Sections are larger blocks of content made up of various components arranged together.

Subfolders for Complexity 🗂️: If a section is complex, create subfolders to split code into smaller pieces.
Composition 🧩: Aim to use composition to make these blocks more versatile.
Reuse Components 🍰: Sections should be built from reusable components, and elements specific to the section, such as wrappers etc.
Uniqueness 📍: While components are generic, sections should have a specific purpose in the application.

Containers

Containers are specific views or templates within an application. They are constructed from one or more sections and if needed - wrappers.

Built from Sections🧩: Containers should be primarily built from sections, not single components. This keeps the complexity of each part manageable and enforces the hierarchy of components -> sections -> containers.
Single Responsibility 🔐: Each container should have a single responsibility. This follows the single-responsibility principle (SRP), making the code easier to maintain and understand.
Naming Convention 🗿: Containers should be named based on their functionality. For example, a container for the homepage could be named LandingPage and template for blogpost could be named ArticlePage

Component Driven Development 🦉

Building large applications or websites isn't easy because usually there are many abstract connections and concepts that you have to constantly keep in mind. With tangled pieces and large, unfocused components, things could quickly get out of hand.

Because of this, it's a good idea to focus on individual parts of your app at a time. Take your time to build generic components, and consider creating a UI library with tools such as Storybook to work in isolation. 📚 Add tests and check if your components are up to spec. If you are using Storybook you might want to check Chromatic for automated UI tests. 🧪

Once the generic components are in place, building larger parts will be much simpler, and you'll avoid a lot of frustration ( trust me! ). While I'm aware that it's not always possible, as designs may evolve as you go, I firmly believe that striving to work in this manner is the way to go. ✨

Final notes 🐸

I think that it is important to acknowledge that there is no 'one-size-fits-all' solution. Just as every digital project is unique, with its own set of goals, challenges, and scope, the structure that best supports it will vary.

While there may be no single 'perfect' structure, the importance of adopting some form of organized structure is undeniable.

I truly believe that upgrading 'small' things such as code structure or file naming conventions had one of the biggest positive impact on my coding in general. Nice, clean and consistent code brings peace and joy to my heart and I hope you'll like it too. Happy Hecking! 👋