Häufige Fehler bei React Server Components

Sie haben den Next.js App Router übernommen. Server Components sind der Standard. Alles sollte schneller, einfacher und effizienter sein.

Stattdessen debuggen Sie um 2 Uhr morgens Hydration-Mismatches, fragen sich, warum Ihr Bundle gewachsen ist, und zweifeln daran, ob die 'use client'-Direktive dort hingehört, wo Sie sie platziert haben.

React Server Components stellen einen grundlegenden Wandel in der Funktionsweise von React-Anwendungen dar. Die Server/Client-Grenze ist nicht mehr nur eine Deployment-Überlegung – sie ist eine architektonische Entscheidung, die Sie bei jeder Komponente treffen. Wenn Sie dies falsch machen, führt das zu subtilen Bugs, Performance-Regressionen und Code, der gegen das Framework arbeitet, anstatt es zu nutzen.

Dieser Artikel behandelt die häufigsten Fehler bei React Server Components, die ich in Produktions-Codebasen gesehen habe, und wie Sie diese vermeiden können.

Server vs. Client Components verstehen

Bevor wir uns den Fallstricken widmen, lassen Sie uns die Grundlagen klären. Im App Router sind Komponenten standardmäßig Server Components. Sie laufen auf dem Server, haben keinen Zugriff auf Browser-APIs und liefern null JavaScript an den Client.

Client Components erfordern die 'use client'-Direktive. Sie können Hooks wie useState und useEffect verwenden, auf Browser-APIs zugreifen und Benutzerinteraktionen verarbeiten.

Die Grenze zwischen ihnen ist der Ort, an dem die meisten Fehler passieren.

Übermäßige Verwendung der ‘use client’-Direktive

Der häufigste Fehler beim Next.js App Router mit RSC ist es, zu früh zu 'use client' zu greifen. Eine Komponente benötigt useState? Markieren Sie sie als Client Component. Brauchen Sie einen onClick-Handler? Client Component.

Das Problem: 'use client' erzeugt eine Grenze. Alles, was diese Komponente importiert, wird Teil des Client-Bundles, selbst wenn diese Imports auf dem Server hätten bleiben können.

// ❌ Die gesamte Seite wird zu einer Client Component
'use client'

import { useState } from 'react'

export default function ProductPage({ product }) {
  const [quantity, setQuantity] = useState(1)
  
  return (
    <div>
      <ProductDetails product={product} />
      <ProductReviews productId={product.id} />
      <QuantitySelector value={quantity} onChange={setQuantity} />
    </div>
  )
}

// ✅ Nur das interaktive Element ist eine Client Component
import ProductDetails from './ProductDetails'
import ProductReviews from './ProductReviews'
import QuantitySelector from './QuantitySelector'

export default function ProductPage({ product }) {
  return (
    <div>
      <ProductDetails product={product} />
      <ProductReviews productId={product.id} />
      <QuantitySelector /> {/* Dies ist die einzige Client Component */}
    </div>
  )
}

Platzieren Sie 'use client' so weit unten im Component-Tree wie möglich. Isolieren Sie Interaktivität in die kleinsten Komponenten, die sie benötigen.

Import von Server-Only-Code in Client Components

Wenn eine Client Component ein Modul importiert, wird dieses gesamte Modul (und seine Abhängigkeiten) an den Browser ausgeliefert. Importieren Sie einen Datenbank-Client oder eine Datei, die Umgebungs-Secrets liest? Sie haben gerade Server-Only-Code dem Client-Graph offengelegt.

// lib/db.js
import 'server-only' // Fügen Sie dies hinzu, um versehentliche Client-Imports zu verhindern

export async function getUsers() {
  return db.query('SELECT * FROM users')
}

Das server-only-Package (bereitgestellt von Next.js) verursacht einen Build-Fehler, wenn das Modul jemals in eine Client Component importiert wird. Verwenden Sie es für jeden Code, der niemals den Browser erreichen darf.

Übergabe nicht-serialisierbarer Werte über die Grenze

Server Components übergeben Props an Client Components durch Serialisierung. Funktionen, Klasseninstanzen, Map und Set können diese Grenze nicht überschreiten.

// ❌ Klasseninstanzen sind nicht serialisierbar
export default async function UserProfile({ userId }) {
  const user = await getUser(userId)
  return <ClientProfile user={user} /> // user ist eine Klasseninstanz
}

// ✅ In ein einfaches Objekt konvertieren
export default async function UserProfile({ userId }) {
  const user = await getUser(userId)
  return (
    <ClientProfile 
      user={{
        id: user.id,
        name: user.name,
        createdAt: user.createdAt.toISOString()
      }} 
    />
  )
}

Missverständnisse bei React Server Actions

Die 'use server'-Direktive markiert Funktionen als Server Actions – vom Client aufrufbar, aber auf dem Server ausgeführt. Sie macht eine Komponente nicht zu einer Server Component. Server Components benötigen keine Direktive, da sie der Standard sind.

// Dies ist eine Server Action, keine Server Component
async function submitForm(formData) {
  'use server'
  await db.insert({ email: formData.get('email') })
}

Server Actions sind effektiv RPC-artige Endpunkte. Behandeln Sie sie wie API-Routes: Validieren Sie Eingaben, behandeln Sie Fehler und vertrauen Sie niemals Client-Daten.

Ignorieren des RSC-Caching-Modells

Das Caching-Verhalten von Next.js hat sich erheblich weiterentwickelt. Gehen Sie nicht davon aus, dass fetch-Aufrufe standardmäßig gecacht werden – dies variiert je nach Next.js-Version, Route-Segment-Konfiguration und Runtime-Einstellungen. Seien Sie explizit bezüglich der Datenaktualität.

// Seien Sie explizit über Caching-Absichten
const data = await fetch(url, { 
  next: { revalidate: 3600 } // Cache für 1 Stunde
})

// Oder komplett deaktivieren
const data = await fetch(url, { cache: 'no-store' })

Verwenden Sie revalidatePath() und revalidateTag() in Server Actions, um gecachte Daten nach Mutationen zu invalidieren. Das RSC-Caching-Modell erfordert bewusste Entscheidungen über die Datenaktualität.

Fazit

React Server Components belohnen sorgfältiges Nachdenken darüber, wo Code ausgeführt wird. Standardmäßig Server Components verwenden. Client-Grenzen nach unten verschieben. Daten an der Grenze serialisieren. Server-Action-Eingaben validieren. Explizit beim Caching sein.

Das mentale Modell braucht Zeit, um verinnerlicht zu werden, aber die Vorteile – kleinere Bundles, schnellere Ladezeiten, einfacheres Data-Fetching – sind die Investition wert.

FAQs

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.