SSR in Next.js Was ist neu beim App-Routing im Vergleich zum Seiten-Routing?

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 können.

Beispiel für SSR im Seitenrouting mit getServerSideProps:

export default function Blogs({ data }) {
  // Render the fetched data
  return (
    <div>
      {data.map((item) => (
        <div key="{item.id}">
          <h3 id="item-title">{item.title}</h3>
          <p>{item.content}</p>
        </div>
      ))}
    </div>
  );
}

// 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 zu 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 (
    <div>
      {(blogs || []).map((blog) => (
        <div key="{blog._id}">
          <h3 id="blog-name">{blog.name}</h3>
          <p>{blog.content}</p>
        </div>
      ))}
    </div>
  );
}

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:

Cleaner 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 (die für die Interaktivität verantwortlich sind) 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 (
    <button onclick="{()"> alert('Button clicked!')}>Click Me</button>
  );
}

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:

Parent Components as Server Components:

The parent components (usually the higher-level components or entire page components) are typically Server Components. They run on the server and handle things like data fetching, rendering static HTML, and passing that data down to child components.
Since these are server-rendered, they do not include any JavaScript on the client-side, and they are not interactive.

Client Components for Interactivity:

Child components, which handle interactivity (like buttons, forms, etc.), are Client Components. These components can use React hooks (useState, useEffect, etc.) and are hydrated on the client-side.
Server Components pass data to these Client Components via props.
Once the HTML is loaded in the browser, Next.js hydrates the Client Components, attaching the necessary event listeners and making the page interactive.

// 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 (
    <div>
      <h1 id="This-is-Server-Side-Rendered">This is Server-Side Rendered</h1>
      <clientcomponent data="{data}"></clientcomponent>
    </div>
  );
}

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

import { useState } from 'react';

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

  return (
    <div>
      <p>Data from server: {JSON.stringify(data)}</p>
      <p>Client-side counter: {count}</p>
      <button onclick="{()"> setCount(count + 1)}>Increment</button>
    </div>
  );
}

Conclusion

Next.js 14 makes Server-Side Rendering (SSR) easier and more powerful with the introduction of server actions in the App Router. By allowing developers to fetch data directly inside component files, this new system streamlines server-side logic, simplifies codebases, and reduces the need for separate API routes. Coupled with selective hydration, SSR in Next.js 14 is now faster and more efficient, helping you build highly dynamic and SEO-friendly applications with ease.

By leveraging these server actions, you can improve your app’s performance while keeping your code clean and maintainable. The shift from Page Routing to App Routing with Server and Client Components represents a major leap forward in building scalable web applications.

Das obige ist der detaillierte Inhalt vonSSR in Next.js Was ist neu beim App-Routing im Vergleich zum Seiten-Routing?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!