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.
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 à l'aide de getServerSideProps :
export default function Blogs({ data }) { // Render the fetched data return ({data.map((item) => (); } // 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 } }; }))}{item.title}
{item.content}
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 d'un grand nombre de logiques côté serveur et de différentes routes.
Avec Next.js 14, SSR est devenu plus rationalisé et intégré au système de routage des 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 ({(blogs || []).map((blog) => (); }))}{blog.name}
{blog.content}
Dans cet exemple de routage d'application, nous utilisons un composant serveur pour récupérer les données directement dans le fichier de 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 à des mécanismes de mise en cache intelligents, vous pouvez affiner votre logique côté serveur pour des performances optimales.
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.
Dans le routage de pages, 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 expédié 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 ( ); }
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.
Voici comment cela fonctionne :
Les composants parents (généralement les composants de niveau supérieur ou les composants de page entière) sont généralement des composants serveur. Ils s'exécutent sur le serveur et gèrent des choses comme la récupération de données, le rendu du HTML statique et la transmission de ces données aux composants enfants.
Étant donné qu'ils sont rendus par le serveur, ils n'incluent aucun JavaScript côté client et ne sont pas interactifs.
Composants clients pour l'interactivité :
Les composants enfants, qui gèrent l'interactivité (comme les boutons, les formulaires, etc.), sont des composants clients. Ces composants peuvent utiliser des hooks React (useState, useEffect, etc.) et sont hydratés côté client.
Les composants serveur transmettent des données à ces composants clients via des accessoires.
Une fois le code HTML chargé dans le navigateur, Next.js hydrate les composants clients, en attachant les écouteurs d'événements nécessaires et en rendant la 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 (); } // Client Component (Child Component) 'use client'; import { useState } from 'react'; function ClientComponent({ data }) { const [count, setCount] = useState(0); return (This is Server-Side Rendered
); }Data from server: {JSON.stringify(data)}
Client-side counter: {count}
Next.js 14 rend le rendu côté serveur (SSR) plus simple et plus puissant grâce à l'introduction d'actions de serveur dans l'App Router. En permettant aux développeurs de récupérer des données directement dans les fichiers de composants, ce nouveau système rationalise la logique côté serveur, simplifie les bases de code et réduit le besoin de routes API distinctes. Associé à une hydratation sélective, le SSR dans Next.js 14 est désormais plus rapide et plus efficace, vous aidant à créer facilement des applications hautement dynamiques et conviviales pour le référencement.
En tirant parti de ces actions du serveur, vous pouvez améliorer les performances de votre application tout en gardant votre code propre et maintenable. Le passage du routage de pages au routage d'applications avec des composants serveur et client représente un pas en avant majeur dans la création d'applications Web évolutives.
Clause de non-responsabilité: Toutes les ressources fournies proviennent en partie d'Internet. En cas de violation de vos droits d'auteur ou d'autres droits et intérêts, veuillez expliquer les raisons détaillées et fournir une preuve du droit d'auteur ou des droits et intérêts, puis l'envoyer à l'adresse e-mail : [email protected]. Nous nous en occuperons pour vous dans les plus brefs délais.
Copyright© 2022 湘ICP备2022001581号-3