Server Components en Next.JS

Si venís de trabajar con Vite o Create React App, tenéis un modelo mental muy claro: Todo vuestro código de React se descarga en el navegador del usuario y se ejecuta allí.

El navegador descarga un archivo JS gigante (bundle), lo procesa, y React empieza a montar el DOM y a ejecutar los useEffect.

Ahora, React puede ser “isomórfico” o “híbrido” (que palabars más bonitas) . Es decir, algunos componentes se ejecutan en vuestro servidor y nunca viajan al navegador, mientras que otros se comportan como siempre.

Entender esta distinción es una de las claves para trabajar bien con Next.js (y una de las cosas que más os liarán al principio… y bueno, también al final 😊).

Por defecto todo es Servidor

Esta es la regla número uno: En la carpeta app, todos los componentes son Server Components por defecto.

No tenéis que hacer nada especial. Si creáis un archivo page.tsx, ese código se ejecutará en el servidor durante el build (o en cada petición) y lo que se enviará al navegador será HTML puro.

Veamos un ejemplo,

// src/app/page.tsx
// Esto es un Server Component.
// Este console.log se verá en la TERMINAL de tu ordenador/servidor,
// NO en la consola del navegador.
import db from '@/lib/db'; 

export default async function Page() {
  console.log("Renderizando en servidor...");
  
  // Podemos acceder a BBDD directamente
  const datos = await db.query('SELECT * FROM users');

  return (
    <main>
      <h1>Lista de Usuarios</h1>
      {/* ... */}
    </main>
  );
}

La directiva "use client"

Evidentemente, el HTML estático está muy bien, pero React se hizo famoso por la interactividad. ¿Cómo hacemos un botón que al hacer clic abra un menú? ¿Cómo usamos useState?

Cuando necesitamos interactividad, debemos optar explícitamente por convertir el componente en un Client Component. Para ello, escribimos la directiva "use client" en la primera línea del archivo.

// src/components/Contador.tsx
'use client' // 👈 Marcamos este archivo como Client Component

import { useState } from 'react';

export default function Contador() {
  // Ahora sí podemos usar hooks y eventos
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicks: {count}
    </button>
  );
}

La frontera

El desafío con Next.js es decidir dónde poner la línea divisoria entre Servidor y Cliente.

Imaginad vuestro árbol de componentes. La raíz (layout.tsx) es Servidor. Vais bajando por las ramas. En el momento en que importáis un componente con 'use client', cruzáis la frontera.

Una vez cruzáis al lado del cliente, todos los componentes hijos importados dentro de ese archivo también serán considerados del lado del cliente (automáticamente, sin necesidad de poner la directiva).

La estrategia de las “Hojas del Árbol”

Para mantener el rendimiento al máximo, queremos que la mayor parte de nuestra app sea Server Components (estáticos y ligeros) y retrasar el uso de 'use client' lo máximo posible, llevándolo a las hojas (los extremos) del árbol.

El problema de la Composición

Hay una restricción más que os va a dar algún dolor de cabeza en algún momento (pero tiene sentido)

Es decir, esto,

'use client'
// ❌ ERROR: Esto rompería porque ServerComponent tiene código de servidor (ej: db call)
// y el Client Component intenta meterlo en el bundle del navegador.
import ServerComponent from './ServerComponent';

export default function ClientWrapper() {
  return (
    <div>
      <ServerComponent />
    </div>
  );
}

La solución es pasar el Server Component como children (prop).**

Si usamos el patrón de composición que vimos en el artículo de “Children y Slots”, podemos hacer esto:

// src/app/page.tsx (SERVER)
import ClientWrapper from './ClientWrapper';
import ServerComponent from './ServerComponent';

export default function Page() {
  return (
    // ✅ CORRECTO: El ClientWrapper recibe el ServerComponent ya renderizado como HTML.
    // No necesita importar su código fuente, solo pintar el "agujero" children.
    <ClientWrapper>
      <ServerComponent />
    </ClientWrapper>
  );
}