Styling

From my notes: inline styles are applied with the style attribute, and in React the value is a JavaScript object, not a CSS string. They're scoped to one element by definition and quick for simple cases, but they can't do pseudo-classes, media queries or other selector-based CSS, and they aren't reusable the way a class is.

The mental model: an inline style is CSS with no selector. Every rule in a stylesheet has a selector that says when it applies — .button:hover, @media (max-width: 600px) .button. An inline style only ever applies to "this element, now", so anything conditional on state the browser tracks (hover, focus, viewport width, dark mode) is out of reach.

export const MyComponent = () => {
  const buttonStyle = {
    backgroundColor: "blue", // camelCase, not background-color
    color: "white",
    padding: 10, // a number means px: "10px"
    borderRadius: "5px",
    lineHeight: 1.5, // unitless properties stay unitless
  };

  return <button style={buttonStyle}>Click me</button>;
};

// What inline styles can't do: there is no selector, so no :hover, no @media.
export const HoverAttempt = () => {
  const style = {
    backgroundColor: "blue", // works
    ":hover": { backgroundColor: "green" }, // does nothing useful
  };
  return <button style={style}>Hover me</button>;
};

Where inline styles are the right tool is values that are only known at runtime: a progress bar's width, a colour the user picked, the position of a dragged element. The modern way to combine that with real CSS is to pass the value as a CSS custom property and keep the selectors in a stylesheet:

// .chip { background: var(--accent); }
// .chip:hover { background: color-mix(in srgb, var(--accent), black 20%); }
export const Chip = ({ accent, children }) => (
  <span className="chip" style={{ "--accent": accent }}>
    {children}
  </span>
);

From my notes: this is the traditional way. You write CSS in a .css file and import it into a component; the bundler adds it to the page and the styles apply globally, exactly like a <link rel="stylesheet"> in plain HTML. It's simple, everyone understands it, and every CSS feature works. The cost is that every class name lives in one global namespace, so two files that both define .button fight, and the winner is whichever loads last.

The mental model: import "./styles.css" doesn't attach the CSS to the component that imports it. It's a side effect that adds the stylesheet to the whole document, once. The import only decides when it's loaded and in what order, never where it applies.

/* styles.css: global, every .button on the page gets this */
.button {
  background-color: blue;
  color: white;
  padding: 10px;
  border-radius: 5px;
}

/* Card.css, written by another team: also global! */
.button {
  background-color: hotpink;
}

import "./styles.css";
import "./Card.css";

export const MyComponent = () => <button className="button">Click me</button>;

Global CSS is still the right tool for things that should be global: a reset (box-sizing, margins), base typography, CSS variables for the design tokens (:root { --brand: … }), and styles for third-party widgets. For component styles, teams that use plain global CSS protect themselves with naming conventions such as BEM (.card__button--primary), or with cascade layers (@layer reset, base, components, utilities;), which make the order of precedence explicit instead of depending on import order.

From my notes: CSS Modules solve the global-scope problem by scoping class names to the file. You write normal CSS in a *.module.css file; at build time every class gets a unique generated name, and importing the file gives you an object that maps your names to the generated ones. The styles are encapsulated by default, and it's still plain CSS.

The mental model: a CSS Module is a CSS file with its own namespace, like a JavaScript module whose top-level variables don't leak. .button in MyComponent.module.css and .button in Card.module.css are different classes, because neither file's class is actually called button in the browser.

.button {
  background-color: blue;
  color: white;
  padding: 10px;
  border-radius: 5px;
}

.primary {
  composes: button; /* reuse another class from this file */
  font-weight: bold;
}

.button:hover {
  background-color: navy; /* pseudo-classes work: it's real CSS */
}

@media (max-width: 600px) {
  .button {
    width: 100%;
  }
}

:global(.dark) .button {
  background-color: black; /* .dark stays unhashed */
}

import styles from "./MyComponent.module.css";

export const MyComponent = () => <button className={styles.button}>Click me</button>;
export const PrimaryButton = () => <button className={styles.primary}>Save</button>;

Correcting my notes: they list "extra setup required (configuring Webpack for non-CRA projects)" as the main con. That was true of hand-rolled Webpack setups, where you enabled modules in css-loader. Today Vite, Next.js, Parcel and Rspack support *.module.css with no configuration. The real trade-offs are elsewhere: styles live in a separate file from the component; dynamic values still need inline styles or CSS variables; class names are strings, so a typo (styles.buton) is undefined at runtime unless you add TypeScript declarations for the module; and there's no built-in theming beyond CSS variables.

Sass is a CSS preprocessor: a language that adds variables, nesting, mixins, functions and loops on top of CSS, and is compiled to plain CSS at build time. The browser never sees Sass. It doesn't run on the server when a page is requested, and it doesn't run in the browser: your build tool (Vite, webpack, Next.js) runs the Sass compiler once while building, and what ships is an ordinary .css file. A common misconception is that Sass is "executed on the server"; the only place it runs is your machine or CI during the build (and the dev server, which compiles on the fly while you work).

Sass has two syntaxes. SCSS (.scss) is a superset of CSS: braces and semicolons, and any valid CSS file is valid SCSS. The older indented syntax (.sass) uses indentation instead of braces. Nearly everyone uses SCSS, and "Sass" usually means the language and its compiler. The compiler today is Dart Sass, published on npm as sass (pure JavaScript) and sass-embedded (a faster native binary); the old node-sass/LibSass is deprecated.

The mental model: Sass is a recipe that gets cooked before serving. You write with shortcuts (variables, reusable mixins, loops) and the build turns it into the finished, plain CSS dish. Whatever Sass computed, such as 4px * 2, is a fixed number by the time the browser gets it.

Setup with Vite is one command and no config: Vite has built-in support for .scss, .sass and .module.scss files, and only needs the compiler installed.

npm i -D sass            # or: npm i -D sass-embedded (faster; Vite tries it first)

Without it, the first .scss import fails the build with Vite 8's message: Preprocessor dependency "sass-embedded" not found. Did you install it? Try `npm install -D sass-embedded`.

A partial with shared tokens, and a Sass module that uses it:

// A partial: the leading underscore means "only for @use, never compiled on its own"
$brand: #2563eb;
$radius: 6px;
$variants: (
  "danger": #dc2626,
  "success": #16a34a,
);

@function space($n) {
  @return $n * 4px;
}

@mixin focus-ring($color: $brand) {
  outline: 2px solid $color;
  outline-offset: 2px;
}

@use "tokens" as t;

.button {
  background: t.$brand;
  color: white;
  padding: t.space(2) t.space(4);
  border-radius: t.$radius;

  &:focus-visible {
    @include t.focus-ring;
  }

  .icon {
    margin-right: t.space(1);
  }
}

@each $name, $color in t.$variants {
  .#{$name} {
    background: $color;

    &:focus-visible {
      @include t.focus-ring($color);
    }
  }
}

import styles from "./Button.module.scss";

export function Button({ variant, children }) {
  const className = variant ? `${styles.button} ${styles[variant]}` : styles.button;
  return (
    <button className={className}>
      <span className={styles.icon}>★</span>
      {children}
    </button>
  );
}

The CSS that vite build (Vite 8.3, Sass 1.105) actually produced, unminified:

._button_ycdfx_1 {
  background: #2563eb;
  color: white;
  padding: 8px 16px;
  border-radius: 6px;
}
._button_ycdfx_1:focus-visible {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}
._button_ycdfx_1 ._icon_ycdfx_11 {
  margin-right: 4px;
}

._danger_ycdfx_15 {
  background: #dc2626;
}
._danger_ycdfx_15:focus-visible {
  outline: 2px solid #dc2626;
  outline-offset: 2px;
}

._success_ycdfx_23 {
  background: #16a34a;
}
._success_ycdfx_23:focus-visible {
  outline: 2px solid #16a34a;
  outline-offset: 2px;
}

How much of Sass modern CSS now covers. Since about 2023 browsers support much of what people originally reached for Sass to get:

When Sass is still worth it: a design system or codebase that already uses it (Bootstrap's source is Sass), when you need mixins with arguments, loops or maps to generate many classes, or a namespaced module system for tokens. When to skip it: a new app with CSS Modules and custom properties already has scoping, variables and nesting, with one less build dependency; and with Tailwind (whose v4 docs advise against combining it with Sass) or CSS-in-JS, JavaScript already does what Sass would. Many teams now use Sass only for its mixins and keep tokens as CSS custom properties, so themes can change at runtime.

From my notes: styled-components is a CSS-in-JS library: you write real CSS inside JavaScript using tagged template literals, and the result is a React component with those styles attached. It keeps styles scoped to the component, supports dynamic styling based on props, and gives you the full range of CSS. My notes add that it's "super powerful" because you can pass props, inherit styles, and use pseudo-classes and media queries — those three examples were screenshots that didn't survive, so the ones below are new and run against styled-components 6.5.

The mental model: styled.button is a component factory. When the component renders, styled-components evaluates the template (calling any ${(props) => …} functions with the current props), hashes the resulting CSS into a class name, inserts the rule into a <style> tag if it isn't there yet, and renders a <button> with that class. Different CSS text → different class.

import styled, { css, ThemeProvider, createGlobalStyle } from "styled-components";

// 1. The basic example: a <button> with these styles attached.
export const Button = styled.button`
  background-color: blue;
  color: white;
  padding: 10px;
  border-radius: 5px;

  /* 2. Pseudo-classes: & means "this component's generated class" */
  &:hover {
    background-color: navy;
  }
  &:disabled {
    opacity: 0.5;
  }

  /* 3. Media queries, nested right inside */
  @media (max-width: 600px) {
    width: 100%;
  }
`;

// 4. Props: a $-prefixed ("transient") prop is read by the styles but never reaches the DOM.
export const PropsButton = styled.button`
  padding: 10px;
  color: white;
  background-color: ${(props) => (props.$variant === "danger" ? "crimson" : "blue")};
  ${(props) =>
    props.$large &&
    css`
      font-size: 1.25rem;
      padding: 16px 24px;
    `}
`;

// 5. Inheritance: extend an existing styled component; only the differences are written.
export const OutlineButton = styled(Button)`
  background-color: transparent;
  color: blue;
  border: 2px solid blue;
`;

// 6. Theme: values come from the nearest <ThemeProvider>.
export const ThemedButton = styled.button`
  background-color: ${({ theme }) => theme.colors.primary};
  color: ${({ theme }) => theme.colors.onPrimary};
`;

export const GlobalStyle = createGlobalStyle`
  body { margin: 0; font-family: system-ui, sans-serif; }
`;

export const theme = { colors: { primary: "#1976d2", onPrimary: "white" } };

export function App() {
  return (
    <ThemeProvider theme={theme}>
      <GlobalStyle />
      <Button>Click me</Button>
      <PropsButton $variant="danger" $large>
        Delete
      </PropsButton>
      <OutlineButton>Cancel</OutlineButton>
      <ThemedButton>Themed</ThemedButton>
      {/* 7. "as": keep the styles, render a different element */}
      <Button as="a" href="/docs">
        Docs link
      </Button>
    </ThemeProvider>
  );
}

import { renderToString } from "react-dom/server";
import { ServerStyleSheet } from "styled-components";
import { Button } from "./Styled";

const sheet = new ServerStyleSheet();
try {
  const html = renderToString(sheet.collectStyles(<Button>Buy</Button>));
  const styleTags = sheet.getStyleTags(); // a string of <style> tags for <head>
  // send `<head>${styleTags}</head><body><div id="root">${html}</div>…`
} finally {
  sheet.seal(); // free the sheet
}

Pros and cons, from my notes and updated: component-scoped styles, full CSS support, dynamic styling with props, theming and no separate CSS file are the pros. The cons in my notes — a learning curve and "larger bundle size if not optimized" — are real but small (about 13 kB gzipped); the bigger cost is runtime work on every render and the friction with server rendering, covered in CSS-in-JS: costs and alternatives.

Correcting my notes: they say styled-components is "most commonly used… highly popular in modern React projects". That was true around 2018–2022. Since then the ecosystem has moved towards zero-runtime approaches (Tailwind, CSS Modules, compile-time CSS-in-JS), the React team discourages runtime style injection, and styled-components' own README notes it is largely maintained by one person. It's still everywhere in existing codebases — so know it well for interviews and maintenance — but it's rarely the default choice for a new React 19 app.

From my notes: Tailwind is a utility-first CSS framework: instead of writing custom CSS, you style elements by combining small predefined classes directly in your JSX. The pros in my notes still hold — no custom CSS required, responsive design built in, highly customisable, consistent — and so does the con: "class name soup", long className strings that are unfamiliar to people used to writing their own styles. My notes' summary of where it fits also stands: projects where rapid development and consistency matter, in teams that prefer utilities to custom class names.

The mental model: Tailwind is a design system expressed as class names. px-4 isn't "padding 16px", it's "horizontal padding of 4 steps on the spacing scale"; bg-blue-500 is "the 500 shade of the palette's blue". Because everyone picks from the same scale, spacing and colours stay consistent without a style guide. And a build-time scanner reads your source files and generates CSS only for the classes it finds, so the stylesheet contains exactly what you use.

export const MyComponent = () => {
  return <button className="bg-blue-500 text-white py-2 px-4 rounded">Click me</button>;
};

// Variants are prefixes: hover:, focus-visible:, md: (min-width 48rem), dark:, disabled:
export const ResponsiveCard = ({ selected }) => (
  <div
    className={[
      "rounded-lg p-4 shadow",
      "flex flex-col md:flex-row", // stacked on phones, side by side from md up
      "bg-white dark:bg-slate-800",
      selected ? "ring-2 ring-brand" : "ring-0", // full class names in both branches
    ].join(" ")}
  >
    <button className="bg-brand hover:bg-brand/80 disabled:opacity-50 px-3 py-1">Save</button>
  </div>
);

@import "tailwindcss";

@theme {
  --color-brand: #7c3aed; /* creates bg-brand, text-brand, ring-brand, ... */
}

Setting it up in a Vite project, per the Tailwind 4 docs: npm install tailwindcss @tailwindcss/vite, add tailwindcss() to the Vite plugins, and put @import "tailwindcss"; at the top of your main CSS file. There's no content array to configure any more; the scanner finds your source files automatically (with @source to add paths it would skip).

When class lists get long, teams extract components, not CSS: a <Button variant="primary"> that owns its classes, often with a helper like clsx for conditions and tailwind-merge to resolve conflicts (px-2 vs px-4) when callers pass extra classes. Avoid recreating the old world with @apply everywhere; it works, but you lose the point of utilities.

A component library gives you finished, accessible components — buttons, dialogs, date pickers, data grids — with a consistent design and a theming system. From my notes: MUI (Material UI) implements Google's Material Design, and you theme it by creating a theme with createTheme and providing it to the app with ThemeProvider.

The mental model: a component library is a design system you rent. You get months of work on keyboard handling, focus traps, ARIA attributes and edge cases for free, and you pay in two ways: your app looks like the library unless you put real effort into theming, and you take on its styling engine and bundle size. The theme object is the contract between them — change palette.primary.main once and every component that uses "primary" follows.

The examples from my notes, updated for Material UI v9 (MUI isn't installed in the sandbox, so this code wasn't executed; it follows the v9 docs):

// npm install @mui/material @emotion/react @emotion/styled
import Button from "@mui/material/Button";
import CssBaseline from "@mui/material/CssBaseline";
import { ThemeProvider, createTheme } from "@mui/material/styles";

const theme = createTheme({
  palette: {
    primary: {
      main: "#1976d2",
    },
  },
  colorSchemes: { dark: true }, // light is on by default; this adds a dark palette
  shape: { borderRadius: 8 },
});

function MyComponent() {
  return (
    <Button variant="contained" color="primary" sx={{ mt: 2, px: 4 }}>
      Click Me
    </Button>
  );
}

export function MyApp() {
  return (
    <ThemeProvider theme={theme}>
      <CssBaseline /> {/* MUI's global reset + base typography */}
      <MyComponent />
    </ThemeProvider>
  );
}

Both import { createTheme, ThemeProvider } from "@mui/material" (as in my notes) and from "@mui/material/styles" (as in the current docs) work; the root package re-exports the styles entry. Other theming tools worth knowing: theme.components.MuiButton.styleOverrides / defaultProps to change a component everywhere, styled() from @mui/material/styles to build your own themed components, and cssVariables: true to emit the theme as CSS variables, which the docs recommend to avoid a light-mode flash on server-rendered dark-mode pages.

Other libraries interviewers mention, by approach:

My notes mark "Potential issues with CSS-in-JS approach" as IMPORTANT, followed by "Mitigate performance issues" — both were screenshots that didn't survive. So the issues and mitigations below are written fresh, and the first one is measured.

The idea to hold on to: runtime CSS-in-JS (styled-components, Emotion, MUI's default engine) does at runtime, in the browser, on every render what other approaches do once at build time. To render a styled component, the library evaluates the template with the current props, serialises the CSS, hashes it, checks whether that class exists, and if not, parses and inserts a new rule into the stylesheet. That's flexible — any prop can change any style — and it's work the browser repeats for every user, on every render, on the main thread.

import styled from "styled-components";

// Interpolating a fast-changing value: every distinct value = a new class + a new CSS rule.
export const BarInterpolated = styled.div`
  height: 8px;
  background: teal;
  width: ${(p) => p.$percent}%;
`;

// Same look, static CSS: the changing value goes through a CSS variable instead.
const StaticBar = styled.div`
  height: 8px;
  background: teal;
  width: var(--percent);
`;
export const BarWithVariable = ({ percent }) => <StaticBar style={{ "--percent": `${percent}%` }} />;

The costs, in the order interviewers usually ask about them:

• Runtime work on every render — serialising and hashing styles costs time on the main thread; in large trees and frequent updates (animations, typing) it shows up in the profiler.
• Style insertion during rendering — every new rule makes the browser recalculate styles. React added useInsertionEffect for library authors so rules can be inserted before layout effects read the DOM (Emotion uses it); styled-components 6 inserts while rendering (its bundle doesn't reference the hook). Either way the recalculation still happens.
• Bundle size — the library itself ships to every user (about 13 kB gzipped for styled-components, similar for Emotion), and styles are JavaScript, which is more expensive to download and parse than the same CSS.
• Server rendering — styles must be collected during SSR and sent in the HTML (ServerStyleSheet, Emotion's cache), and streaming SSR makes this harder because styles for later chunks arrive later.
• React Server Components — context-based theming can't run on the server, so historically every styled component needed 'use client'. styled-components 6.3+ now handles RSC natively, but Emotion (and so MUI's default engine) still needs client components.
• Unbounded rule growth — as measured above, dynamic interpolations create rules that are never cleaned up.

How to mitigate if you're staying on runtime CSS-in-JS:

• Define styled components at module level, never inside another component's body. Inside a component, each render creates a brand-new component type, so React unmounts and remounts the subtree (losing state) and the library generates new classes.
• Move fast-changing values out of interpolations into CSS variables or .attrs(() => ({ style: { … } })), as the warning suggests.
• Prefer a few variants over arbitrary values: $variant="danger" produces one extra class; $color={anyString} produces one per colour.
• Memoise expensive subtrees (React.memo, the React Compiler) so unchanged styled components don't re-render at all.
• Use the SSR integration so first paint isn't unstyled.

And the alternatives, which avoid the runtime entirely:

• CSS Modules and Tailwind — static CSS generated at build time; zero runtime.
• Compile-time CSS-in-JS — write styles in JavaScript/TypeScript with types and theme tokens, and the build extracts them into static .css files: vanilla-extract, Linaria, Panda CSS, Meta's StyleX, and MUI's Pigment CSS. You keep the colocation and type safety without paying per render.

function ProductCard({ product }) {
  const Title = styled.h2`
    color: ${product.onSale ? "crimson" : "black"};
  `;
  const [expanded, setExpanded] = useState(false);
  return (
    <article onClick={() => setExpanded(!expanded)}>
      <Title>{product.name}</Title>
      {expanded && <p>{product.description}</p>}
    </article>
  );
}

There's no single right answer, but there is a sensible default and a clear set of trade-offs. The questions that decide it: Does styling work happen at build time or runtime? (performance, server rendering, Server Components.) Where do styles live? (next to the component or in a separate file.) How are dynamic values handled? (props, variants, CSS variables.) How is theming done? (CSS variables, a theme object, a design scale.)

How I'd answer "how would you style a new React 19 app?":

• Default: Tailwind or CSS Modules for component styles, plus a thin global layer (reset, CSS variables for tokens, typography). Both are zero-runtime and work with SSR and Server Components.
• Design-heavy product with its own brand: Tailwind + headless primitives (Radix/React Aria, or shadcn/ui), or compile-time CSS-in-JS if the team wants typed style objects.
• Internal tool or dashboard: a full component library such as MUI, accepting its runtime cost for speed of delivery.
• Existing styled-components codebase: don't rewrite for its own sake. Fix the hot spots (dynamic interpolations, components defined inside components), use transient props, and adopt CSS variables for theming.
• Everywhere: dynamic values through CSS variables, not by generating new CSS.