Einführung

Next.js ist seit langem eine beliebte Wahl für die Erstellung servergerenderter React-Anwendungen. Mit der integrierten Unterstützung für Server-Side Rendering (SSR) können Entwickler dynamische, SEO-freundliche Anwendungen erstellen. Allerdings haben die Einführung des App Routers in Next.js 13 und die Verfeinerungen in Next.js 14 SSR erheblich vereinfacht und verbessert.

In diesem Blogbeitrag untersuchen wir die Unterschiede im SSR zwischen dem traditionellen Page-Routing-System und dem neueren App-Routing-System und beleuchten, wie SSR funktioniert und wie es sich durch das neue Routing-Paradigma verändert.

SSR im Seitenrouting (Pre-Next.js 13)

Vor der Einführung des App Routers wurde SSR im Page Routing-System mithilfe spezifischer Funktionen wie getServerSideProps gehandhabt. Diese Funktion wurde bei jeder Anfrage aufgerufen, sodass Entwickler vor dem Rendern der Seite Daten serverseitig abrufen konnten.

Beispiel für SSR im Seitenrouting mit getServerSideProps:

export default function Blogs({ data }) {
  // Render the fetched data
  return (
    

      {data.map((item) => (
        

          
{item.title}
          
{item.content}
        
      ))}
    
  );
}

// This function runs on every request
export async function getServerSideProps() {
  // Fetch data from an external API
  const res = await fetch('https://api.example.com/blogs');
  const data = await res.json();

  // Pass the data as props to the page component
  return { props: { data } };
}

Hier ist getServerSideProps der Schlüssel für SSR im Page Routing-System. Es ermöglicht Ihnen, bei jeder Anfrage Daten von einer API (oder einer anderen Datenquelle) abzurufen und sie als Requisiten an die Seitenkomponente zu übergeben. Dieses Muster ist zwar leistungsstark, kann jedoch zu komplexen Codebasen führen, wenn viel serverseitige Logik und unterschiedliche Routen verarbeitet werden.

App-Routing und SSR in Next.js 14

Mit Next.js 14 wurde SSR schlanker und in das App Routing-System integriert. Dieses neue System führt Serverkomponenten und Clientkomponenten ein, wobei SSR viel intuitiver ist.

In App Routing können Sie jetzt Daten direkt innerhalb von Komponenten abrufen, ohne dass spezielle Funktionen wie getServerSideProps erforderlich sind. Dies können Sie durch den Einsatz von Serveraktionen erreichen, wodurch der Code einfacher und leichter zu warten ist.

Beispiel für SSR im App-Routing mit Serverkomponenten:

"use server";

export async function getBlogs() {
  try {
    const response = await fetch('https://api.example.com/posts');
    return response.json();
  } catch (error) {
    return { error: error.message };
  }
}

// This component runs on the server and fetches data
export default async function Blog() {
  const blogs = await getBlogs();

  return (
    

      {(blogs || []).map((blog) => (
        

          
{blog.name}
          
{blog.content}
        
      ))}
    
  );
}

In diesem App-Routing-Beispiel verwenden wir eine Serverkomponente, um Daten mithilfe von „use server“ direkt in der Komponentendatei abzurufen. Dadurch entfällt die Notwendigkeit separater API-Routen oder Funktionen wie getServerSideProps.

Die Macht der Serveraktionen
Next.js 14 vereinfacht den Prozess durch die Einführung von Serveraktionen. Mit diesen Aktionen können Sie Daten direkt in der Komponentendatei abrufen und verarbeiten, wodurch die Komplexität verringert und Ihre Codebasis wartbarer wird.

Hauptvorteile von Serveraktionen:

Saubererer Code: Anstatt die serverseitige Logik in separate Dateien oder Funktionen zu verstreuen, können Sie alles an einem Ort aufbewahren.
Verbesserte Wartbarkeit: Weniger bewegliche Teile bedeuten weniger zu verwaltenden Code, wodurch Ihre Anwendung einfacher zu warten ist.
Bessere Leistung: Mit intelligenten Caching-Mechanismen können Sie Ihre serverseitige Logik für optimale Leistung optimieren.

Hydratation in Next.js

Im Kontext von Next.js und serverseitigem Rendering (SSR) bezieht sich Hydration auf den Prozess, bei dem eine statisch gerenderte HTML-Seite (vom Server gesendet) in eine vollständig interaktive React-Anwendung im Browser konvertiert wird. Es „hydratisiert“ den statischen HTML-Code mit dem clientseitigen JavaScript von React, um die Seite interaktiv zu machen.

Hydratation im App-Routing vs. Seiten-Routing

Beim Seitenrouting ist für jede Komponente auf der Seite eine Hydratation erforderlich, wodurch sie auf der Clientseite interaktiv wird. Dies bedeutet, dass das gesamte für Interaktionen benötigte JavaScript an den Client gesendet wird, was bei der Skalierung der Anwendung zu Leistungsengpässen führen kann.

Beim App Routing werden mit Serverkomponenten nur die Clientkomponenten (diejenigen, die die Interaktivität verarbeiten) hydratisiert. Diese selektive Hydratation reduziert die Menge an JavaScript, die an den Client gesendet wird, was zu einer verbesserten Leistung führt.

Beispiel für Client-Komponenten im App-Routing:

'use client';  // Mark this as a client component

export default function Button() {
  return (
     alert('Button clicked!')}>Click Me
  );
}

Hier wird die Button-Komponente als Client-Komponente mit „Client verwenden“ markiert. Es ermöglicht Interaktivität und wird auf der Clientseite ausgeführt, während andere nicht interaktive Komponenten als Serverkomponenten verbleiben und so die Leistung verbessern.

Weitere Informationen zur Flüssigkeitszufuhr finden Sie im App Routing

So funktioniert es:

Übergeordnete Komponenten als Serverkomponenten:

Die übergeordneten Komponenten (normalerweise die übergeordneten Komponenten oder ganze Seitenkomponenten) sind normalerweise Serverkomponenten. Sie laufen auf dem Server und kümmern sich um Dinge wie das Abrufen von Daten, das Rendern von statischem HTML und die Weitergabe dieser Daten an untergeordnete Komponenten.
Da diese vom Server gerendert werden, enthalten sie kein JavaScript auf der Clientseite und sind nicht interaktiv.

Client-Komponenten für Interaktivität:

Untergeordnete Komponenten, die die Interaktivität verwalten (wie Schaltflächen, Formulare usw.), sind Client-Komponenten. Diese Komponenten können React-Hooks (useState, useEffect usw.) verwenden und werden auf der Clientseite hydratisiert.
Serverkomponenten übergeben Daten über Requisiten an diese Clientkomponenten.
Sobald der HTML-Code im Browser geladen ist, hydriert Next.js die Client-Komponenten, fügt die erforderlichen Ereignis-Listener hinzu und macht die Seite interaktiv.

// Server Component (Parent Component)
export default async function ParentComponent() {
  // Fetch data on the server
  const data = await fetch('https://api.example.com/data').then(res => res.json());

  return (
    

      
This is Server-Side Rendered
      
  );
}

// Client Component (Child Component)
'use client';

import { useState } from 'react';

function ClientComponent({ data }) {
  const [count, setCount] = useState(0);

  return (
    

      
Data from server: {JSON.stringify(data)}
      
Client-side counter: {count}
       setCount(count   1)}>Increment
    
  );
}

Abschluss

Next.js 14 macht Server-Side Rendering (SSR) durch die Einführung von Serveraktionen im App Router einfacher und leistungsfähiger. Indem es Entwicklern ermöglicht, Daten direkt in Komponentendateien abzurufen, rationalisiert dieses neue System die serverseitige Logik, vereinfacht Codebasen und reduziert den Bedarf an separaten API-Routen. In Verbindung mit der selektiven Hydratation ist SSR in Next.js 14 jetzt schneller und effizienter und hilft Ihnen dabei, ganz einfach hochdynamische und SEO-freundliche Anwendungen zu erstellen.

Durch die Nutzung dieser Serveraktionen können Sie die Leistung Ihrer App verbessern und gleichzeitig Ihren Code sauber und wartbar halten. Der Wechsel vom Page Routing zum App Routing mit Server- und Client-Komponenten stellt einen großen Fortschritt beim Aufbau skalierbarer Webanwendungen dar.