"Si un trabajador quiere hacer bien su trabajo, primero debe afilar sus herramientas." - Confucio, "Las Analectas de Confucio. Lu Linggong"
Página delantera > Programación > SSR en Next.js Novedades del enrutamiento de aplicaciones en comparación con el enrutamiento de páginas

SSR en Next.js Novedades del enrutamiento de aplicaciones en comparación con el enrutamiento de páginas

Publicado el 2024-11-09
Navegar:642

SSR in Next.js  What’s New in App Routing Compared to Page Routing

Introducción

Next.js ha sido durante mucho tiempo una opción popular para crear aplicaciones React renderizadas en servidor. Con su soporte integrado para renderizado del lado del servidor (SSR), los desarrolladores pueden crear aplicaciones dinámicas y compatibles con SEO. Sin embargo, la introducción de App Router en Next.js 13 y las mejoras en Next.js 14 han simplificado y mejorado SSR significativamente.

En esta publicación de blog, exploraremos las diferencias en SSR entre el sistema tradicional de enrutamiento de páginas y el sistema de enrutamiento de aplicaciones más nuevo, destacando cómo funciona SSR y cómo ha cambiado con el nuevo paradigma de enrutamiento.

SSR en enrutamiento de página (Pre-Next.js 13)

Antes de que se introdujera App Router, SSR se manejaba en el sistema Page Routing mediante funciones específicas como getServerSideProps. Esta función se invocaba en cada solicitud, lo que permitía a los desarrolladores obtener datos del lado del servidor antes de representar la página.

Ejemplo de SSR en enrutamiento de página usando 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 } }; }

Aquí, getServerSideProps es la clave para SSR en el sistema de enrutamiento de página. Le permite recuperar datos de una API (o cualquier otra fuente de datos) en cada solicitud y pasarlos al componente de la página como accesorios. Este patrón, aunque potente, puede generar bases de código complejas cuando se maneja mucha lógica del lado del servidor y diferentes rutas.

Enrutamiento de aplicaciones y SSR en Next.js 14

Con Next.js 14, SSR se ha vuelto más optimizado e integrado en el sistema App Routing. Este nuevo sistema introduce Componentes de Servidor y Componentes de Cliente, donde SSR es mucho más intuitivo.

En App Routing, ahora puede recuperar datos directamente dentro de los componentes sin necesidad de funciones especiales como getServerSideProps. Puede lograr esto utilizando acciones del servidor, lo que hace que el código sea más simple y fácil de mantener.

Ejemplo de SSR en enrutamiento de aplicaciones con componentes de servidor:

"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}

))}
); }

En este ejemplo de enrutamiento de aplicaciones, utilizamos un componente de servidor para recuperar datos directamente dentro del archivo del componente usando el servidor. Esto elimina la necesidad de rutas API separadas o funciones como getServerSideProps.

El poder de las acciones del servidor
Next.js 14 simplifica el proceso al introducir acciones del servidor. Estas acciones le permiten recuperar y procesar datos directamente dentro del archivo del componente, lo que reduce la complejidad y hace que su código base sea más fácil de mantener.

Beneficios clave de las acciones del servidor:

Código de limpieza: En lugar de dispersar la lógica del lado del servidor en archivos o funciones separados, puedes mantener todo en un solo lugar.
Mantenibilidad mejorada: Menos piezas móviles significan menos código que administrar, lo que hace que su aplicación sea más fácil de mantener.
Mejor rendimiento: Con mecanismos de almacenamiento en caché inteligentes, puede ajustar la lógica del lado del servidor para obtener un rendimiento óptimo.

SSR in Next.js  What’s New in App Routing Compared to Page Routing

Hidratación en Next.js

En el contexto de Next.js y la representación del lado del servidor (SSR), la hidratación se refiere al proceso en el que una página HTML renderizada estáticamente (enviada desde el servidor) se convierte en una aplicación React totalmente interactiva en el navegador. "Hidrata" el HTML estático con JavaScript del lado del cliente de React para hacer que la página sea interactiva.

Hidratación en enrutamiento de aplicaciones frente a enrutamiento de páginas

En Page Routing, se requiere hidratación para cada componente de la página, lo que la hace interactiva en el lado del cliente. Esto significa que todo el JavaScript necesario para las interacciones se envía al cliente, lo que puede generar cuellos de botella en el rendimiento a medida que la aplicación escala.

En App Routing, con Componentes de Servidor, solo se hidratan los Componentes de Cliente (los que manejan la interactividad). Esta hidratación selectiva reduce la cantidad de JavaScript enviado al cliente, lo que resulta en un rendimiento mejorado.

Ejemplo de componentes de cliente en enrutamiento de aplicaciones:

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

export default function Button() {
  return (
    
  );
}

Aquí, el componente Botón está marcado como Componente Cliente con 'usar cliente'. Permite la interactividad y se ejecuta en el lado del cliente, mientras que otros componentes no interactivos permanecen como componentes del servidor, lo que mejora el rendimiento.

Más información sobre la hidratación en App Routing

Así es como funciona:

Componentes principales como componentes del servidor:

Los componentes principales (normalmente los componentes de nivel superior o los componentes de página completa) suelen ser componentes de servidor. Se ejecutan en el servidor y manejan cosas como la obtención de datos, la representación de HTML estático y la transferencia de esos datos a componentes secundarios.
Dado que se procesan en el servidor, no incluyen JavaScript en el lado del cliente y no son interactivos.

Componentes del cliente para interactividad:

Los componentes secundarios, que manejan la interactividad (como botones, formularios, etc.), son componentes del cliente. Estos componentes pueden usar ganchos de React (useState, useEffect, etc.) y están hidratados en el lado del cliente.
Los componentes del servidor pasan datos a estos componentes del cliente a través de accesorios.
Una vez que el HTML se carga en el navegador, Next.js hidrata los componentes del cliente, adjuntando los detectores de eventos necesarios y haciendo que la página sea interactiva.

// 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}

); }

Conclusión

Next.js 14 hace que la representación del lado del servidor (SSR) sea más fácil y potente con la introducción de acciones del servidor en App Router. Al permitir a los desarrolladores recuperar datos directamente dentro de los archivos de componentes, este nuevo sistema agiliza la lógica del lado del servidor, simplifica las bases de código y reduce la necesidad de rutas API separadas. Junto con la hidratación selectiva, SSR en Next.js 14 ahora es más rápido y eficiente, lo que le ayuda a crear aplicaciones altamente dinámicas y compatibles con SEO con facilidad.

Al aprovechar estas acciones del servidor, puedes mejorar el rendimiento de tu aplicación mientras mantienes tu código limpio y fácil de mantener. El cambio del enrutamiento de páginas al enrutamiento de aplicaciones con componentes de servidor y cliente representa un gran avance en la creación de aplicaciones web escalables.

SSR in Next.js  What’s New in App Routing Compared to Page Routing

Declaración de liberación Este artículo se reproduce en: https://dev.to/asim_khan_cbe65e41bcbbc65/understanding-nextjs-page-routing-vs-app-routing-and-ssr-changes-in-nextjs-14-2cge?1 infracción, por favor contacte a estudio_golang @163.com Eliminar
Último tutorial Más>

Descargo de responsabilidad: Todos los recursos proporcionados provienen en parte de Internet. Si existe alguna infracción de sus derechos de autor u otros derechos e intereses, explique los motivos detallados y proporcione pruebas de los derechos de autor o derechos e intereses y luego envíelos al correo electrónico: [email protected]. Lo manejaremos por usted lo antes posible.

Copyright© 2022 湘ICP备2022001581号-3