SSR dans Next.js Quoi de neuf dans le routage d'application par rapport au routage de page

Présentation

Next.js est depuis longtemps un choix populaire pour créer des applications React rendues par le serveur. Grâce à sa prise en charge intégrée du rendu côté serveur (SSR), les développeurs peuvent créer des applications dynamiques et conviviales pour le référencement. Cependant, l'introduction du routeur d'applications dans Next.js 13 et les améliorations apportées à Next.js 14 ont considérablement simplifié et amélioré le SSR.

Dans cet article de blog, nous explorerons les différences de SSR entre le système de routage de pages traditionnel et le nouveau système de routage d'applications, en soulignant le fonctionnement du SSR et son évolution avec le nouveau paradigme de routage.

SSR dans le routage des pages (Pré-Next.js 13)

Avant l'introduction de l'App Router, SSR était géré dans le système de routage de pages à l'aide de fonctions spécifiques telles que getServerSideProps. Cette fonction était appelée à chaque requête, permettant aux développeurs de récupérer les données côté serveur avant de restituer la page.

Exemple de SSR dans le routage de pages utilisant getServerSideProps :

export default function Blogs({ data }) {
  // Render the fetched data
  return (
    <div>
      {data.map((item) => (
        <div key={item.id}>
          <h3>{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 } };
}

Ici, getServerSideProps est la clé du SSR dans le système de routage de pages. Il vous permet de récupérer des données à partir d'une API (ou de toute autre source de données) à chaque requête et de les transmettre au composant de page en tant qu'accessoires. Ce modèle, bien que puissant, peut entraîner des bases de code complexes lors de la gestion de nombreuses logiques côté serveur et de différentes routes.

Routage d'applications et SSR dans Next.js 14

Avec Next.js 14, SSR est devenu plus rationalisé et intégré au système de routage d'applications. Ce nouveau système introduit les composants serveur et les composants clients, où SSR est beaucoup plus intuitif.

Dans App Routing, vous pouvez désormais récupérer directement les données à l'intérieur des composants sans avoir besoin de fonctions spéciales telles que getServerSideProps. Vous pouvez y parvenir en utilisant des actions de serveur, ce qui rend le code plus simple et plus facile à maintenir.

Exemple de SSR dans le routage d'applications avec des composants serveur :

"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>{blog.name}</h3>
          <p>{blog.content}</p>
        </div>
      ))}
    </div>
  );
}

Dans cet exemple de routage d'application, nous utilisons un composant serveur pour récupérer les données directement dans le fichier du composant à l'aide de use server. Cela supprime le besoin de routes ou de fonctions API distinctes telles que getServerSideProps.

La puissance des actions du serveur
Next.js 14 simplifie le processus en introduisant des actions de serveur. Ces actions vous permettent de récupérer et de traiter directement les données dans le fichier de composant, réduisant ainsi la complexité et rendant votre base de code plus maintenable.

Principaux avantages des actions du serveur :

Code de nettoyage : Au lieu de disperser la logique côté serveur dans des fichiers ou des fonctions séparés, vous pouvez tout conserver au même endroit.
Maintenabilité améliorée : moins de pièces mobiles signifie moins de code à gérer, ce qui rend votre application plus facile à maintenir.
Meilleures performances : Grâce aux mécanismes de mise en cache intelligents, vous pouvez affiner votre logique côté serveur pour des performances optimales.

Hydratation dans Next.js

Dans le contexte de Next.js et du rendu côté serveur (SSR), l'hydratation fait référence au processus par lequel une page HTML rendue statiquement (envoyée depuis le serveur) est convertie en une application React entièrement interactive dans le navigateur. Il « hydrate » le HTML statique avec le JavaScript côté client de React pour rendre la page interactive.

Hydratation dans le routage d'applications par rapport au routage de pages

Dans Page Routing, l'hydratation est requise pour chaque composant de la page, ce qui la rend interactive côté client. Cela signifie que tout le JavaScript nécessaire aux interactions est envoyé au client, ce qui peut entraîner des goulots d'étranglement en termes de performances à mesure que l'application évolue.

Dans App Routing, avec les composants serveur, seuls les composants clients (ceux qui gèrent l'interactivité) sont hydratés. Cette hydratation sélective réduit la quantité de JavaScript envoyée au client, ce qui entraîne des performances améliorées.

Exemple de composants clients dans le routage d'application :

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

export default function Button() {
  return (
    <button onClick={() => alert('Button clicked!')}>Click Me</button>
  );
}

Ici, le composant Button est marqué comme composant client avec « utiliser le client ». Il permet l'interactivité et s'exécute côté client, tandis que les autres composants non interactifs restent en tant que composants serveur, améliorant ainsi les performances.

En savoir plus sur l'hydratation dans App Routing

Voici comment cela fonctionne :

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>This is Server-Side Rendered</h1>
      <ClientComponent data={data} />
    </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.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!