Fundamentos

Rutas

En Next.js, las rutas estĆ”ticas y dinĆ”micas son formas de definir cĆ³mo se accede a diferentes pĆ”ginas en tu aplicaciĆ³n. AquĆ­ tienes una explicaciĆ³n breve y ejemplos de cada tipo:

Rutas EstƔticas

Las rutas estƔticas son aquellas que tienen una URL fija y predefinida. Estas rutas se definen mediante archivos en la carpeta pages de tu proyecto Next.js.

Ejemplo:

  • Archivo: pages/about.js

  • URL: /about

// pages/about.js
export default function About() {
  return <div>About Page</div>;
}

Rutas DinƔmicas

Las rutas dinĆ”micas permiten crear pĆ”ginas cuyas URLs pueden variar segĆŗn parĆ”metros. Estas rutas se definen utilizando corchetes [] en el nombre del archivo.

Ejemplo:

  • Archivo: pages/posts/[id].js

  • URL: /posts/1, /posts/2, etc.

// pages/posts/[id].js
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { id } = router.query;

  return <div>Post ID: {id}</div>;
}

Rutas DinƔmicas Anidadas

TambiĆ©n puedes tener rutas dinĆ”micas anidadas, donde mĆŗltiples segmentos de la URL pueden ser dinĆ”micos.

Ejemplo:

  • Archivo: pages/posts/[category]/[id].js

  • URL: /posts/tech/1, /posts/sports/2, etc.

// pages/posts/[category]/[id].js
import { useRouter } from 'next/router';

export default function Post() {
  const router = useRouter();
  const { category, id } = router.query;

  return <div>Category: {category}, Post ID: {id}</div>;
}

Nota: TambiƩn se puede obtener el nombre del segmento de ruta dinamica via props

En Next.js, los corchetes con tres puntos ([...categories]) en una ruta dinĆ”mica definen un segmento de captura o una ruta dinĆ”mica opcional que puede abarcar mĆŗltiples partes de la URL.

CaracterĆ­sticas:

  1. Captura mĆŗltiple: Acepta una o varias partes de la ruta.

    • Ejemplo: /products/shoes o /products/shoes/nike

  2. ParƔmetro como array: El valor capturado estarƔ disponible como un array.

    • Ejemplo: Si la URL es /products/shoes/nike, entonces categories serĆ” ['shoes', 'nike'].

  3. Ruta opcional: La ruta puede ser sin parƔmetros adicionales.

    • Ejemplo: /productsEn este caso serĆ” resuelta si hay un page.tsx en la pruta products de lo contrario si solo hay el page.tsx en /products/[...categories]/page.tsx , no serĆ” resuelta la ruta /products para lograr eso se necesitan los dobles corchetes.

Ejemplo:

/app/products/[...categories]/page.js

  • /products/shoes ā†’ categories = ['shoes']

  • /products/shoes/nike ā†’ categories = ['shoes', 'nike']

  • /products ā†’ categories = undefined (o un array vacĆ­o dependiendo de la configuraciĆ³n).

Se utiliza para manejar rutas flexibles o jerƔrquicas con facilidad.

TambiĆ©n se pueden usar los dobles corchetes. En Next.js, [[...categories]] define una ruta dinĆ”mica opcional con captura mĆŗltiple, lo que significa que el segmento puede estar presente o no.

Diferencias con [...categories]:

  • Opcionalidad: Si no hay segmentos en la URL, la ruta sigue siendo vĆ”lida.

  • Si la ruta es /products, categories serĆ” undefined (en lugar de requerir al menos un segmento).

Ejemplo:

/app/products/[[...categories]]/page.js

  • /products ā†’ categories = undefined

  • /products/shoes ā†’ categories = ['shoes']

  • /products/shoes/nike ā†’ categories = ['shoes', 'nike']

Esto se usa para manejar rutas donde los segmentos adicionales son opcionales.

Layouts

En Next.js 14, los layouts son una caracterĆ­stica fundamental que permite estructurar la interfaz de manera mĆ”s modular y reutilizable. En este contexto, los layouts definen la estructura o el "esqueleto" comĆŗn de la pĆ”gina, como encabezados, barras laterales o pies de pĆ”gina, y se integran perfectamente con el sistema de enrutamiento de Next.js.

ĀæQuĆ© son los layouts en Next.js 14?

  1. Layouts anidados: Next.js 14 permite que los layouts sean anidados y especĆ­ficos para ciertas partes de la aplicaciĆ³n. Por ejemplo, puedes tener un layout general para toda la aplicaciĆ³n y otro layout especĆ­fico para un Ć”rea administrativa.

  2. Persistencia entre rutas: Los layouts permanecen montados mientras se navega entre rutas que comparten el mismo layout. Esto mejora el rendimiento y evita la pĆ©rdida de estado en componentes como menĆŗs abiertos o pestaƱas seleccionadas.

  3. Server Components: Con el soporte para Server Components, los layouts pueden usarse para renderizar contenido en el servidor y enviar al cliente Ćŗnicamente lo necesario, optimizando el rendimiento.

CĆ³mo afectan los layouts a las rutas en Next.js 14

En Next.js 14, los layouts se definen en el sistema de directorios bajo la carpeta /app. El lugar donde colocas el archivo layout.js afecta directamente a las rutas que lo utilizan.

  1. Layouts globales:

    • Si colocas un archivo layout.js directamente dentro de la carpeta /app, este se aplicarĆ” a todas las rutas de la aplicaciĆ³n.

    • Por ejemplo:

      /app/layout.js

      Se aplica a:

      /home
/about
/dashboard

  2. Layouts especĆ­ficos por secciones:

    • Si colocas un archivo layout.js dentro de una subcarpeta, este solo se aplicarĆ” a las rutas que estĆ©n bajo esa carpeta.

    • Por ejemplo:

      /app/dashboard/layout.js

      Se aplica a:

      /dashboard
/dashboard/settings
/dashboard/profile

      Pero no se aplica a rutas como /about o /home.

  3. Layouts anidados:

    • Puedes combinar layouts globales con layouts especĆ­ficos.

    • Por ejemplo:

      /app/layout.js         -> Layout general
/app/dashboard/layout.js -> Layout para dashboard

      AquĆ­, una ruta como /dashboard/settings usarĆ­a tanto el layout global como el layout especĆ­fico del dashboard.

  4. CombinaciĆ³n con pĆ”ginas:

    • Los layouts funcionan en conjunto con archivos page.js. Cada layout renderiza su contenido en un componente children, que incluye la pĆ”gina correspondiente.

Ejemplo prƔctico

Estructura de carpetas:

/app
  layout.js            // Layout global
  /dashboard
    layout.js          // Layout para el dashboard
    page.js            // PƔgina principal del dashboard
    /settings
      page.js          // PĆ”gina de configuraciĆ³n dentro del dashboard

CĆ³mo funciona:

  • La pĆ”gina /dashboard/settings:

    • UsarĆ” primero layout.js de /app como layout global.

    • Luego, aplicarĆ” layout.js de /dashboard como layout especĆ­fico.

Ventajas de los layouts en Next.js 14

  1. ReutilizaciĆ³n: Reduce la duplicaciĆ³n de cĆ³digo al centralizar la estructura comĆŗn.

  2. Escalabilidad: Facilita la organizaciĆ³n en aplicaciones grandes con muchas secciones.

  3. OptimizaciĆ³n de rendimiento: Los layouts montados no se descargan innecesariamente al cambiar de ruta, mejorando la experiencia del usuario.

Con estas capacidades, los layouts en Next.js 14 son una herramienta poderosa para construir aplicaciones estructuradas y eficientes.

Componentes

En Next.js 14, los Server Components (componentes del servidor) y los Client Components (componentes del cliente) tienen roles y comportamientos diferentes, optimizados para sus respectivos contextos.

Server Components

  1. QuƩ son:

    • Se renderizan en el servidor y envĆ­an HTML estĆ”tico al cliente.

    • No incluyen JavaScript en el cliente, por lo que son mĆ”s livianos y rĆ”pidos.

  2. CaracterĆ­sticas:

    • Acceso directo a datos del servidor (bases de datos, APIs, etc.) sin exponer credenciales al cliente.

    • Ideal para contenido que no necesita interactividad.

    • Mejor rendimiento inicial y SEO.

  3. CuƔndo usarlos:

    • Para renderizar datos estĆ”ticos o dinĆ”micos que no requieren interacciĆ³n del usuario.

    • Ejemplo: encabezados, pies de pĆ”gina, o listas estĆ”ticas de productos.

  4. CĆ³mo declararlos:

    • Son el comportamiento por defecto en la carpeta /app.

    • No necesitan la directiva "use client".

Client Components

  1. QuƩ son:

    • Se renderizan en el cliente y necesitan JavaScript para funcionar.

    • Permiten manejar estados e interactividad.

  2. CaracterĆ­sticas:

    • Pueden usar hooks de React como useState y useEffect.

    • Adecuados para componentes que dependen de eventos del usuario.

  3. CuƔndo usarlos:

    • Para elementos interactivos como formularios, botones o sliders.

    • Ejemplo: un carrito de compras, un botĆ³n "me gusta", o un modal dinĆ”mico.

  4. CĆ³mo declararlos:

    • Necesitan la directiva "use client" al inicio del archivo.

ComparaciĆ³n: CuĆ”ndo usar cada uno

Aspecto

Server Components

Client Components

RenderizaciĆ³n

En el servidor, entrega HTML estƔtico.

En el cliente, requiere JavaScript.

Interactividad

No interactivo.

Interactivo (usa eventos, hooks).

Rendimiento

MƔs rƔpido para carga inicial.

MƔs lento debido a JavaScript.

Estado/Side Effects

No maneja estado ni efectos secundarios.

Maneja estado y efectos secundarios.

SEO

Excelente para SEO.

Menos Ć³ptimo por depender de JS.

Ejemplo mixto

// Server Component (por defecto en /app)
export default function ProductList({ products }) {
  return (
    <ul>
      {products.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

// Client Component
"use client";
import { useState } from "react";

export default function LikeButton() {
  const [liked, setLiked] = useState(false);
  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? "Unlike" : "Like"}
    </button>
  );
}

Aquƭ, ProductList usa datos estƔticos, mientras que LikeButton maneja interactividad en el cliente. Combinar ambos tipos mejora la eficiencia y la experiencia del usuario.

Una buena practica es agregar use client solo a los elementos que lo requieran, recordar que puden combinarse como el ejemplo anterior y si el componente client es cliente todos sus hijos lo serƔn.

Route Grouping

En Next.js, el grouping (agrupaciĆ³n) es una funcionalidad que permite organizar rutas y estructuras de carpetas sin que estas afecten la URL final de la aplicaciĆ³n. Esto se logra mediante el uso de directorios de grupo de rutas, que se indican colocando el nombre de la carpeta entre parĆ©ntesis.

ĀæQuĆ© es un directorio de grupo de rutas?

Es un directorio que se utiliza Ćŗnicamente para organizar el cĆ³digo y que no forma parte de la URL. Los directorios de grupo estĆ”n delimitados por parĆ©ntesis ( ).

CaracterĆ­sticas clave:

  1. No afectan la URL:

    • Los directorios con parĆ©ntesis no se reflejan en la ruta final.

  2. OrganizaciĆ³n del cĆ³digo:

    • Facilitan estructurar archivos y componentes de forma lĆ³gica, especialmente en aplicaciones grandes.

  3. Compatibilidad:

    • Se pueden combinar con otras caracterĆ­sticas como layouts, pĆ”ginas y componentes.

Ejemplo: CĆ³mo funciona

Estructura de carpetas:

/app
  /(admin)
    dashboard
      page.js
  /shop
    product
      page.js

URLs resultantes:

  • /dashboard ā†’ Renderiza /(admin)/dashboard/page.js.

  • /shop/product ā†’ Renderiza /shop/product/page.js.

AquĆ­, el directorio (admin) es solo organizativo y no aparece en la URL.

Ventajas del grouping:

  1. OrganizaciĆ³n modular:

    • Divide funcionalidades como Ć”reas administrativas, secciones pĆŗblicas, o dominios especĆ­ficos.

  2. EstructuraciĆ³n mĆ”s clara:

    • Hace que el cĆ³digo sea mĆ”s mantenible y fĆ”cil de navegar sin afectar la experiencia del usuario.

  3. Facilita la reutilizaciĆ³n:

    • Puedes agrupar componentes o layouts que comparten lĆ³gica o estilo.

Casos comunes de uso

  1. Ɓreas especĆ­ficas de la aplicaciĆ³n:

    • Agrupar rutas de administrador, usuario, o clientes sin exponer esa estructura en las URLs.

  2. ReutilizaciĆ³n de layouts o middleware:

    • Aplicar un layout especĆ­fico a todas las rutas dentro de un grupo sin afectar el diseƱo general de la aplicaciĆ³n.

Esta tĆ©cnica es muy Ćŗtil para mantener un balance entre estructura del proyecto y simplicidad en las URLs.

Pages vs App

En Next.js, la introducciĆ³n de la carpeta app representa un cambio significativo en la forma de estructurar y manejar las aplicaciones. Tradicionalmente, Next.js utilizaba la carpeta pages para definir las rutas y componentes de la aplicaciĆ³n. Sin embargo, con la introducciĆ³n de la carpeta app, Next.js ofrece una nueva forma de estructurar aplicaciones que proporciona mĆ”s flexibilidad y caracterĆ­sticas avanzadas.

Carpeta pages

La carpeta pages es la forma tradicional de definir rutas y componentes en Next.js. Cada archivo en la carpeta pages se convierte automĆ”ticamente en una ruta accesible en la aplicaciĆ³n.

Ejemplo de Estructura con pages:

/pages
  index.js
  about.js
  /blog
    index.js
    [id].js

Rutas Generadas:

  • /

  • /about

  • /blog

  • /blog/[id]

Carpeta app

La carpeta app es una nueva forma de estructurar aplicaciones en Next.js que ofrece mƔs flexibilidad y caracterƭsticas avanzadas, como el uso de React Server Components, layouts anidados, y mƔs.

Ejemplo de Estructura con app:

/app
  layout.js
  page.js
  /about
    page.js
  /blog
    page.js
    /[id]
      page.js

Rutas Generadas:

  • /

  • /about

  • /blog

  • /blog/[id]

Diferencias Clave entre pages y app

  1. React Server Components: La carpeta app permite el uso de React Server Components, lo que puede mejorar el rendimiento y la experiencia del usuario al permitir que partes de la aplicaciĆ³n se rendericen en el servidor.

  2. Layouts Anidados: La carpeta app permite definir layouts anidados de manera mĆ”s intuitiva. Puedes tener un layout principal y layouts especĆ­ficos para diferentes secciones de la aplicaciĆ³n.

  3. Estructura de Archivos: La carpeta app utiliza una estructura de archivos mƔs flexible y modular. Por ejemplo, puedes tener archivos layout.js y page.js en cada carpeta para definir layouts y pƔginas especƭficas.

  4. ConfiguraciĆ³n y PersonalizaciĆ³n: La carpeta app ofrece mĆ”s opciones de configuraciĆ³n y personalizaciĆ³n, lo que permite una mayor flexibilidad en la forma de estructurar y manejar la aplicaciĆ³n.

ConclusiĆ³n

La introducciĆ³n de la carpeta app en Next.js ofrece una nueva forma de estructurar aplicaciones que proporciona mĆ”s flexibilidad y caracterĆ­sticas avanzadas. Mientras que la carpeta pages sigue siendo una opciĆ³n vĆ”lida y compatible, la carpeta app permite aprovechar nuevas tecnologĆ­as y mejoras en el rendimiento y la experiencia del usuario. La elecciĆ³n entre usar pages o app dependerĆ” de las necesidades especĆ­ficas de tu proyecto y de las caracterĆ­sticas que desees utilizar.

React Server Components (RSC) y Static Generation (SG)

React Server Components (RSC) y Static Generation (SG) son dos conceptos diferentes en el ecosistema de Next.js y React, y no se sustituyen mutuamente. En cambio, pueden complementarse para ofrecer una experiencia de desarrollo y rendimiento mejorada. AquĆ­ te explico cada uno y cĆ³mo pueden trabajar juntos:

React Server Components (RSC)

React Server Components es una nueva caracterĆ­stica de React que permite que los componentes se ejecuten en el servidor en lugar de en el cliente. Esto tiene varias ventajas:

  1. Menor TamaƱo del Bundle: Al ejecutar componentes en el servidor, se reduce el tamaƱo del bundle de JavaScript que se envƭa al cliente, lo que puede mejorar el tiempo de carga inicial.

  2. Mejor Seguridad: Los componentes del servidor no exponen lĆ³gica sensible al cliente, lo que puede mejorar la seguridad de la aplicaciĆ³n.

  3. Mejor Rendimiento: Al ejecutar componentes en el servidor, se puede aprovechar la potencia de procesamiento del servidor y reducir la carga en el cliente.

Static Generation (SG)

Static Generation es una caracterĆ­stica de Next.js que permite generar pĆ”ginas HTML estĆ”ticas en el momento de la compilaciĆ³n. Estas pĆ”ginas estĆ”ticas pueden ser servidas directamente desde un CDN, lo que puede mejorar significativamente el rendimiento y la escalabilidad de la aplicaciĆ³n.

  1. Mejor Rendimiento: Las pƔginas estƔticas se generan una vez y se sirven rƔpidamente desde un CDN.

  2. Escalabilidad: Las pĆ”ginas estĆ”ticas no requieren procesamiento en el servidor en cada solicitud, lo que puede manejar un mayor nĆŗmero de usuarios simultĆ”neos.

  3. SEO: Las pĆ”ginas estĆ”ticas son fĆ”ciles de rastrear para los motores de bĆŗsqueda, lo que puede mejorar el SEO.

CĆ³mo Pueden Complementarse

React Server Components y Static Generation pueden complementarse para ofrecer una experiencia de desarrollo y rendimiento mejorada. AquĆ­ hay algunas formas en que pueden trabajar juntos:

  1. GeneraciĆ³n de PĆ”ginas EstĆ”ticas con RSC: Puedes usar React Server Components para generar pĆ”ginas estĆ”ticas en el momento de la compilaciĆ³n. Esto permite aprovechar las ventajas de RSC (menor tamaƱo del bundle, mejor seguridad) mientras aĆŗn se beneficia del rendimiento y la escalabilidad de las pĆ”ginas estĆ”ticas.

  2. HibridaciĆ³n: Puedes usar una combinaciĆ³n de React Server Components y Static Generation en diferentes partes de tu aplicaciĆ³n. Por ejemplo, puedes usar RSC para componentes que requieren lĆ³gica del servidor y SG para pĆ”ginas que pueden ser completamente estĆ”ticas.

  3. Incremental Static Regeneration (ISR): Next.js tambiĆ©n ofrece Incremental Static Regeneration, que permite actualizar pĆ”ginas estĆ”ticas despuĆ©s de la compilaciĆ³n. Esto puede complementar RSC al permitir que las pĆ”ginas estĆ”ticas se actualicen con nuevos datos sin necesidad de una recompilaciĆ³n completa.

Ejemplo de Uso Combinado

// pages/index.js
import { getStaticProps } from 'next';
import ServerComponent from '../components/ServerComponent';

const HomePage = ({ data }) => {
  return (
    <div>
      <h1>Home Page</h1>
      <ServerComponent data={data} />
    </div>
  );
};

export const getStaticProps = async () => {
  const data = await fetchData(); // Fetch data from an API or database
  return {
    props: {
      data,
    },
  };
};

export default HomePage;

En este ejemplo, getStaticProps se utiliza para generar una pĆ”gina estĆ”tica en el momento de la compilaciĆ³n, mientras que ServerComponent puede ser un React Server Component que se ejecuta en el servidor.

Un ejemplo mas completo

Claro, aquĆ­ tienes un ejemplo de cĆ³mo usar getStaticPaths, getStaticProps y React Server Components en una pĆ”gina de blog dinĆ”mica en Next.js. Este ejemplo asume que tienes una API o una base de datos que proporciona los datos del blog.

Estructura de Archivos

/pages
  /blog
    /[id]
      page.tsx
/components
  BlogPost.tsx

pages/blog/[id]/page.tsx

import { GetStaticPaths, GetStaticProps } from 'next';
import BlogPost from '../../../components/BlogPost';

interface BlogPostProps {
  post: {
    id: string;
    title: string;
    content: string;
  };
}

const BlogPostPage: React.FC<BlogPostProps> = ({ post }) => {
  return (
    <div>
      <h1>{post.title}</h1>
      <BlogPost content={post.content} />
    </div>
  );
};

export const getStaticPaths: GetStaticPaths = async () => {
  // Fetch all blog post IDs from an API or database
  const response = await fetch('https://api.example.com/blog-posts');
  const posts = await response.json();

  const paths = posts.map((post: { id: string }) => ({
    params: { id: post.id },
  }));

  return { paths, fallback: false };
};

export const getStaticProps: GetStaticProps = async ({ params }) => {
  const { id } = params!;

  // Fetch the blog post data from an API or database
  const response = await fetch(`https://api.example.com/blog-posts/${id}`);
  const post = await response.json();

  return {
    props: {
      post,
    },
  };
};

export default BlogPostPage;

components/BlogPost.tsx

import React from 'react';

interface BlogPostProps {
  content: string;
}

const BlogPost: React.FC<BlogPostProps> = ({ content }) => {
  return (
    <div>
      <p>{content}</p>
    </div>
  );
};

export default BlogPost;

ExplicaciĆ³n

  1. getStaticPaths: Esta funciĆ³n se utiliza para generar todas las rutas posibles para las pĆ”ginas de blog. Fetcha todos los IDs de los posts del blog desde una API o base de datos y devuelve un array de objetos params que contienen los IDs.

  2. getStaticProps: Esta funciĆ³n se utiliza para obtener los datos especĆ­ficos de un post de blog en funciĆ³n del ID proporcionado por getStaticPaths. Fetcha los datos del post desde una API o base de datos y devuelve los datos como props para la pĆ”gina.

  3. React Server Component: En este ejemplo, BlogPost es un componente que recibe el contenido del post como prop y lo renderiza. Aunque en este ejemplo BlogPost es un componente de cliente, podrĆ­as convertirlo en un React Server Component si necesitas ejecutar lĆ³gica en el servidor.

ConclusiĆ³n

Este ejemplo muestra cĆ³mo combinar getStaticPaths, getStaticProps y React Server Components para crear una pĆ”gina de blog dinĆ”mica en Next.js. Al usar getStaticPaths y getStaticProps, puedes generar pĆ”ginas estĆ”ticas en el momento de la compilaciĆ³n, lo que mejora el rendimiento y la escalabilidad de tu aplicaciĆ³n. Los React Server Components pueden ser utilizados para ejecutar lĆ³gica en el servidor y reducir el tamaƱo del bundle de JavaScript enviado al cliente.

getServerSideProps

En las nuevas versiones de Next.js, especialmente con la introducciĆ³n de la carpeta /app y React Server Components, el uso de getServerSideProps ha cambiado. Aunque getServerSideProps sigue siendo compatible y Ćŗtil en la carpeta /pages, su relevancia y uso pueden variar dependiendo de la estructura de tu proyecto y las necesidades especĆ­ficas de tu aplicaciĆ³n.

getServerSideProps en /pages

getServerSideProps sigue siendo una opciĆ³n vĆ”lida y Ćŗtil en la carpeta /pages. Se utiliza para obtener datos en el servidor en cada solicitud, lo que es Ćŗtil para pĆ”ginas que necesitan datos frescos y no pueden ser generadas estĆ”ticamente.

Ejemplo en /pages:

// pages/blog/[id].tsx
import { GetServerSideProps } from 'next';
import BlogPost from '../../components/BlogPost';

interface BlogPostProps {
  post: {
    id: string;
    title: string;
    content: string;
  };
}

const BlogPostPage: React.FC<BlogPostProps> = ({ post }) => {
  return (
    <div>
      <h1>{post.title}</h1>
      <BlogPost content={post.content} />
    </div>
  );
};

export const getServerSideProps: GetServerSideProps = async ({ params }) => {
  const { id } = params!;

  // Fetch the blog post data from an API or database
  const response = await fetch(`https://api.example.com/blog-posts/${id}`);
  const post = await response.json();

  return {
    props: {
      post,
    },
  };
};

export default BlogPostPage;

/app y React Server Components

En la carpeta /app, Next.js introduce una nueva forma de manejar el renderizado del lado del servidor utilizando React Server Components. Esto permite una mayor flexibilidad y mejores capacidades de renderizado del lado del servidor sin necesidad de getServerSideProps.

Ejemplo en /app:

// app/blog/[id]/page.tsx
import BlogPost from '../../../components/BlogPost';

interface BlogPostProps {
  params: {
    id: string;
  };
}

const BlogPostPage: React.FC<BlogPostProps> = async ({ params }) => {
  const { id } = params;

  // Fetch the blog post data from an API or database
  const response = await fetch(`https://api.example.com/blog-posts/${id}`);
  const post = await response.json();

  return (
    <div>
      <h1>{post.title}</h1>
      <BlogPost content={post.content} />
    </div>
  );
};

export default BlogPostPage;

ComparaciĆ³n y Uso

  1. getServerSideProps en /pages:

    • Ventajas: Familiaridad y compatibilidad con versiones anteriores.

    • Desventajas: Menos flexible y puede ser mĆ”s difĆ­cil de manejar en aplicaciones grandes.

  2. React Server Components en /app:

    • Ventajas: Mayor flexibilidad, mejor rendimiento y capacidades avanzadas de renderizado del lado del servidor.

    • Desventajas: Nuevo paradigma que puede requerir un tiempo de aprendizaje.

ConclusiĆ³n

getServerSideProps sigue siendo Ćŗtil y relevante en la carpeta /pages, especialmente para proyectos que ya estĆ”n utilizando esta estructura o que necesitan una soluciĆ³n rĆ”pida y compatible. Sin embargo, para nuevos proyectos o para aprovechar las nuevas capacidades de Next.js, la carpeta /app y React Server Components ofrecen una soluciĆ³n mĆ”s moderna y flexible.

La elecciĆ³n entre usar getServerSideProps en /pages o React Server Components en /app dependerĆ” de las necesidades especĆ­ficas de tu proyecto y de tu familiaridad con las nuevas caracterĆ­sticas de Next.js.

Server Actions

En Next.js 13+ (incluyendo la versiĆ³n 14), las Server Actions son una caracterĆ­stica que permite manejar lĆ³gica del lado del servidor directamente desde componentes React. Esto simplifica la interacciĆ³n entre el cliente y el servidor al eliminar la necesidad de crear rutas API separadas para realizar acciones del lado del servidor.

ĀæQuĆ© son las Server Actions?

Las Server Actions son funciones que se ejecutan exclusivamente en el servidor y se pueden invocar directamente desde componentes React. EstƔn diseƱadas para manejar tareas como:

  • Enviar formularios.

  • Interactuar con bases de datos.

  • Ejecutar lĆ³gica de negocio en el servidor.

Con Server Actions, puedes escribir cĆ³digo del servidor en un entorno controlado sin preocuparte por exponerlo al cliente.

ĀæCĆ³mo funcionan?

  1. DeclaraciĆ³n de una Server Action:

    • Se utiliza la funciĆ³n especial server proporcionada por Next.js para definir una Server Action.

    • Deben ser declaradas como funciones asĆ­ncronas.

    Ejemplo de una Server Action:

    "use server";

async function saveData(formData) {
  // AquĆ­ puedes interactuar con la base de datos o APIs del servidor.
  await db.save(formData);
  console.log("Datos guardados:", formData);
}

export default saveData;

  2. Uso en Componentes React:

    • Las Server Actions se pueden invocar directamente desde componentes React.

    • Por ejemplo, se usan comĆŗnmente con formularios.

    Ejemplo con un Formulario:

    import saveData from "./actions/saveData";

export default function MyComponent() {
  async function handleSubmit(formData) {
    await saveData(formData);
  }

  return (
    <form action={handleSubmit}>
      <input type="text" name="name" placeholder="Name" required />
      <button type="submit">Save</button>
    </form>
  );
}

  3. Flujo de EjecuciĆ³n:

    • Cuando el usuario envĆ­a el formulario, el navegador realiza una solicitud POST.

    • Next.js procesa la acciĆ³n en el servidor usando la funciĆ³n definida en saveData.

Ventajas de las Server Actions

  1. Eliminan la necesidad de rutas API personalizadas:

    • Antes, para guardar datos, necesitabas una ruta en /api.

    • Ahora, puedes manejar esta lĆ³gica directamente desde componentes React.

  2. Mantienen la seguridad:

    • El cĆ³digo de las Server Actions solo se ejecuta en el servidor. No se incluye en el bundle del cliente.

  3. Simplifican el desarrollo:

    • Menos pasos para interactuar con el servidor.

    • Mejor integraciĆ³n con formularios y lĆ³gica del lado del servidor.

  4. Mejor rendimiento:

    • Reducen la sobrecarga al evitar crear rutas adicionales o manejar respuestas HTTP manualmente.

Limitaciones

  1. Soporte en /app: Las Server Actions funcionan exclusivamente en la carpeta /app.

  2. Compatibilidad con estado del cliente: Las Server Actions no pueden interactuar directamente con librerĆ­as que gestionan estado del cliente (como Redux).

  3. No se puede usar con useEffect: No estƔn diseƱadas para ser invocadas desde efectos React.

Casos de Uso ComĆŗn

  • Guardar datos en un formulario.

  • Realizar operaciones CRUD directamente en el servidor.

  • Validar entradas del usuario antes de almacenarlas.

PreviousNext Js

Last updated