Stilisering

Moderne komponentbiblioteker trenger fleksible systemer for styling som kan håndtere komplekse krav uten å gå på bekostning av utvikleropplevelsen. Kombinasjonen av Tailwind CSS og intelligent sammenslåing av klasser har vist seg å være et kraftfullt mønster for å bygge tilpassbare komponenter.

Denne tilnærmingen løser den grunnleggende spenningen mellom å tilby fornuftige standarder og å tillate full tilpasning — en utfordring som har plaget komponentbiblioteker i mange år.

Problemet med tradisjonell styling

Tradisjonelle CSS-tilnærminger fører ofte til spesifisitetskriger, stilkonflikter og uforutsigbare overskrivinger. Når du sender className="bg-blue-500" til en komponent som allerede har bg-red-500, hvilken vinner?

Uten riktig håndtering vil begge klassene anvendes og resultatet avhenger av mange faktorer - CSS-kildeorden, klassenes spesifisitet, bundlerens algoritme for sammenslåing av klasser osv.

Intelligent sammenslåing av klasser

Biblioteket tailwind-merge løser dette ved å forstå Tailwinds klassestruktur og intelligent løse konflikter. Når to klasser målretter samme CSS-egenskap, beholder det bare den siste.

Without tailwind-merge

// Both bg-red-500 and bg-blue-500 apply - unpredictable result
<Button className="bg-blue-500" />
// Renders: className="bg-red-500 bg-blue-500"

With tailwind-merge

import { twMerge } from 'tailwind-merge';

// bg-blue-500 wins as it comes last
const className = twMerge('bg-red-500', 'bg-blue-500');
// Returns: "bg-blue-500"

Dette fungerer for alle Tailwind-utilities:

twMerge('px-4 py-2', 'px-8'); // Returns: "py-2 px-8"
twMerge('text-sm', 'text-lg'); // Returns: "text-lg"
twMerge('hover:bg-red-500', 'hover:bg-blue-500'); // Returns: "hover:bg-blue-500"

Biblioteket forstår også Tailwinds modifikatorsystem:

// Modifiers are handled correctly
twMerge('hover:bg-red-500 focus:bg-red-500', 'hover:bg-blue-500');
// Returns: "focus:bg-red-500 hover:bg-blue-500"

Betingede klasser

Ofte trenger du å anvende klasser betinget basert på props eller state. Biblioteket clsx tilbyr et rent API for dette:

Using clsx

import clsx from 'clsx';

// Basic conditionals
clsx('base', isActive && 'active');
// Returns: "base active" (if isActive is true)

// Object syntax
clsx('base', {
  'active': isActive,
  'disabled': isDisabled,
});

// Arrays
clsx(['base', isLarge ? 'text-lg' : 'text-sm']);

// Mixed
clsx(
  'base',
  ['array-item'],
  { 'object-conditional': true },
  isActive && 'conditional'
);

Et vanlig mønster er å slå sammen et forhåndsdefinert sett med klasser med innkommende props, samt eventuelle egendefinerte regler vi har:

component.tsx

const Component = ({ className, ...props }: ComponentProps) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div
      className={cn(
        "rounded-lg border bg-white shadow-sm",
        isOpen && "bg-blue-500",
        className
      )}
      {...props}
    />
  );
};

cn-hjelpefunksjonen

Funksjonen cn, popularisert av shadcn/ui, kombinerer clsx og tailwind-merge for å gi deg både betinget logikk og intelligent sammenslåing:

lib/utils.ts

import { type ClassValue, clsx } from 'clsx';
import { twMerge } from 'tailwind-merge';

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs));
}

Kraften kommer fra rekkefølgen - basisstiler først, betingelser deretter, brukeroverstyringer sist. Dette sikrer forutsigbar atferd samtidig som det opprettholder full tilpasningsmulighet.

Class Variance Authority (CVA)

For komplekse komponenter med mange varianter blir det uhåndterlig å styre betingede klasser manuelt. Class Variance Authority (CVA) tilbyr et deklarativt API for å definere komponentvarianter.

For eksempel, her er et utdrag fra Button-komponenten fra shadcn/ui:

@/components/ui/button.tsx

const buttonVariants = cva(
  "inline-flex items-center justify-center gap-2 whitespace-nowrap rounded-md text-sm font-medium transition-all disabled:pointer-events-none disabled:opacity-50 [&_svg]:pointer-events-none [&_svg:not([class*='size-'])]:size-4 shrink-0 [&_svg]:shrink-0 outline-none focus-visible:border-ring focus-visible:ring-ring/50 focus-visible:ring-[3px] aria-invalid:ring-destructive/20 dark:aria-invalid:ring-destructive/40 aria-invalid:border-destructive",
  {
    variants: {
      variant: {
        default: "bg-primary text-primary-foreground hover:bg-primary/90",
        destructive:
          "bg-destructive text-white hover:bg-destructive/90 focus-visible:ring-destructive/20 dark:focus-visible:ring-destructive/40 dark:bg-destructive/60",
        outline:
          "border bg-background shadow-xs hover:bg-accent hover:text-accent-foreground dark:bg-input/30 dark:border-input dark:hover:bg-input/50",
        secondary:
          "bg-secondary text-secondary-foreground hover:bg-secondary/80",
        ghost:
          "hover:bg-accent hover:text-accent-foreground dark:hover:bg-accent/50",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "h-9 px-4 py-2 has-[>svg]:px-3",
        sm: "h-8 rounded-md gap-1.5 px-3 has-[>svg]:px-2.5",
        lg: "h-10 rounded-md px-6 has-[>svg]:px-4",
        icon: "size-9",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
)

Beste praksis

1. Rekkefølgen er viktig

Bruk alltid klassene i denne rekkefølgen:

Basisstiler (alltid anvendt)
Variantstiler (basert på props)
Betingede stiler (basert på state)
Brukeroverstyringer (className-prop)

className={cn(
  'base-styles',            // 1. Base
  variant && variantStyles, // 2. Variants
  isActive && 'active',     // 3. Conditionals
  className                 // 4. User overrides
)}

2. Dokumenter variantene dine

Bruk TypeScript og JSDoc for å dokumentere hva hver variant gjør:

type ButtonProps = {
  /**
   * The visual style of the button
   * @default "primary"
   */
  variant?: 'primary' | 'secondary' | 'destructive' | 'ghost';

  /**
   * The size of the button
   * @default "md"
   */
  size?: 'sm' | 'md' | 'lg';
};

3. Trekk ut gjentatte mønstre

Hvis du oppdager at du skriver samme betingede logikk gjentatte ganger, trekk det ut:

utils/styles.ts

export const focusRing = 'focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-blue-500';
export const disabled = 'disabled:pointer-events-none disabled:opacity-50';

// Use in components
className={cn(focusRing, disabled, className)}

Migrasjonsguide

Hvis du migrerer fra en annen stylingtilnærming, her er hvordan du kan tilpasse vanlige mønstre:

Fra CSS Modules

Before - CSS Modules

import styles from './Button.module.css';

<button className={`${styles.button} ${styles[variant]} ${className}`} />

After - cn + Tailwind

import { cn } from '@/lib/utils';

<button className={cn(
  'px-4 py-2 rounded-lg',
  variant === 'primary' && 'bg-blue-500 text-white',
  className
)} />

Fra styled-components

Before - styled-components

const Button = styled.button<{ $primary?: boolean }>`
  padding: 8px 16px;
  background: ${props => props.$primary ? 'blue' : 'gray'};
`;

After - cn + Tailwind

function Button({ primary, className, ...props }) {
  return (
    <button
      className={cn(
        'px-4 py-2',
        primary ? 'bg-blue-500' : 'bg-gray-500',
        className
      )}
      {...props}
    />
  );
}

Ytelsesbetraktninger

Både clsx og tailwind-merge er kraftig optimalisert, men husk disse tipsene:

Definer varianter utenfor komponenter - CVA-varianter bør defineres utenfor komponenten for å unngå gjenskapning ved hver render.
Memoiser komplekse beregninger - Hvis du har kostbar betinget logikk, vurder å memoise:

const className = useMemo(
  () => cn(
    baseStyles,
    expensiveComputation(props),
    className
  ),
  [props, className]
);

Bruk CSS-variabler for dynamiske verdier - I stedet for å generere klasser dynamisk, bruk CSS-variabler:

Prefer CSS variables

// Good
<div
  className="bg-[var(--color)]"
  style={{ '--color': dynamicColor } as React.CSSProperties}
/>

// Avoid
<div className={`bg-[${dynamicColor}]`} />

Kombinasjonen av Tailwind CSS, intelligent sammenslåing av klasser og variant-API-er gir et robust grunnlag for komponentstyling. Denne tilnærmingen skalerer fra enkle knapper til komplekse designsystemer samtidig som den opprettholder forutsigbarhet og en god utvikleropplevelse.

Stilisering

On this page