Server vs Client Components en Next.js: El Framework de Decisión que Necesitas

El Malentendido Fundamental

Acabo de revisar el código de tres proyectos diferentes esta semana. En los tres, desarrolladores experimentados habían cometido el mismo error: asumir que un Client Component se ejecuta *solo* en el navegador.

No es así.

Este malentendido es crítico porque cambia completamente cómo deberías arquitectar tu aplicación. Un Client Component en Next.js se renderiza primero en el servidor, se envía como HTML al navegador, y luego se hidrata (se vuelve interactivo).

La directiva `'use client'` no significa "ejecuta esto en el cliente". Significa "este componente necesita características del cliente para funcionar" (state, event listeners, hooks como `useState`).

Por Qué Importa Esta Distinción

Cuando entiendes que los Client Components se renderizam en el servidor primero, cambias tu mentalidad sobre dónde colocar la lógica.

Escenario real: Tenía un formulario que necesitaba validación. Mi primer instinto fue meter toda la lógica en un Client Component. Resultado: estaba validando datos que ya podría haber validado en el servidor, enviando JavaScript innecesario al navegador.

La realidad es más matizada:

**Server Components** (por defecto): Acceso a bases de datos, secretos, operaciones seguras. Se ejecutan una sola vez.
**Client Components**: Interactividad, estado local, listeners de eventos. Se hidratan en el navegador.

Ambos se renderizán en el servidor. La diferencia está en cuándo y dónde se ejecuta el código *después* de la renderización inicial.

El Framework de Decisión

Aquí está el sistema que uso para decidir cuándo usar `'use client'`:

#### 1. ¿Necesitas interactividad en tiempo real?

Si la respuesta es sí (clicks, form inputs, cambios de estado instantáneos), necesitas un Client Component.

```javascript // ❌ INCORRECTO - Intentar hacer un formulario sin 'use client' export default function ContactForm() { // const [email, setEmail] = useState(''); // Esto fallará return <form>...</form>; }

// ✅ CORRECTO 'use client';

import { useState } from 'react';

export default function ContactForm() { const [email, setEmail] = useState(''); const [submitted, setSubmitted] = useState(false);

const handleSubmit = (e) => { e.preventDefault(); setSubmitted(true); };

return ( <form onSubmit={handleSubmit}> <input value={email} onChange={(e) => setEmail(e.target.value)} type="email" /> <button type="submit">Enviar</button> </form> ); } ```

#### 2. ¿Tienes acceso a APIs del navegador?

LocalStorage, geolocation, window events, etc. Necesitas un Client Component.

```javascript 'use client';

import { useEffect, useState } from 'react';

export default function UserPreferences() { const [theme, setTheme] = useState('light');

useEffect(() => { // Esto solo funciona en el cliente const saved = localStorage.getItem('theme'); if (saved) setTheme(saved); }, []);

return <div className={theme}>Contenido</div>; } ```

#### 3. ¿Necesitas datos en tiempo real o suscripciones?

WebSockets, listeners, real-time updates. Client Component.

#### 4. Todo lo demás: Server Component

Fetch de datos, lógica de negocio, acceso a BD, secretos. Mantén como Server Component.

El Patrón que Cambia el Juego

La arquitectura ganadora es esta: Mantén Server Components grandes, mete Client Components pequeños dentro.

```javascript // app/products/page.js - Server Component import { db } from '@/lib/db'; import ProductCard from '@/components/ProductCard'; import AddToCartButton from '@/components/AddToCartButton';

export default async function ProductsPage() { const products = await db.products.findAll();

return ( <div> {products.map((product) => ( <div key={product.id}> <ProductCard product={product} /> {/* Este Client Component es pequeño y enfocado */} <AddToCartButton productId={product.id} /> </div> ))} </div> ); } ```

```javascript // components/AddToCartButton.js - Client Component 'use client';

import { useState } from 'react';

export default function AddToCartButton({ productId }) { const [loading, setLoading] = useState(false);

const handleClick = async () => { setLoading(true); // Llamada al servidor await fetch('/api/cart', { method: 'POST', body: JSON.stringify({ productId }) }); setLoading(false); };

return ( <button onClick={handleClick} disabled={loading}> {loading ? 'Añadiendo...' : 'Añadir al carrito'} </button> ); } ```

Ve la diferencia: el Server Component maneja toda la lógica pesada y el fetch de datos. El Client Component es minúsculo y solo maneja la interactividad local.

Esto tiene beneficios reales:

**Menos JavaScript en el navegador**: El código del servidor no se envía al cliente.
**Mejor seguridad**: Las secretos nunca llegan al navegador.
**Mejor rendimiento**: El servidor hace el trabajo pesado una sola vez.

El Error Que Ves Constantemente

Muchos desarrolladores hacen esto:

```javascript // ❌ ANTI-PATRÓN 'use client';

export default function Page() { const [data, setData] = useState(null);

useEffect(() => { fetch('/api/data').then(r => r.json()).then(setData); }, []);

return <div>{data}</div>; } ```

Por qué está mal:

1. El componente se renderiza sin datos (loading state) 2. Esperas a que el cliente haga el fetch 3. Envías JavaScript innecesario 4. El SEO se ve afectado

La solución:

```javascript // ✅ CORRECTO import { Suspense } from 'react';

async function DataContent() { const data = await fetch('/api/data').then(r => r.json()); return <div>{data}</div>; }

export default function Page() { return ( <Suspense fallback={<div>Cargando...</div>}> <DataContent /> </Suspense> ); } ```

El servidor fetch los datos. El cliente ve el contenido casi inmediatamente. Sin JavaScript innecesario.

Aplicando Esto en la Práctica

Cuando construyo un proyecto nuevo con Next.js, mi checklist es:

1. Asumo Server Component por defecto. Todos mis componentes son Server Components. 2. Pregunto: ¿Necesito interactividad aquí? Si no, listo. 3. Si sí, extraigo la parte interactiva a un componente separado y le añado `'use client'`. 4. Mantengo ese Client Component lo más pequeño posible.

Esto suena simple, pero requiere disciplina. Es tentador meter todo en un Client Component "por si acaso".

No lo hagas. Tu bundle de JavaScript (y tu usuario) te lo agradecerá.

La Conclusión

La directiva `'use client'` no es sobre *dónde* se ejecuta el código. Es sobre *qué tipo de funcionalidad necesita*.

Server Components son el default. Client Components son la excepción.

Una vez que internalizas esto, tu arquitectura cambia. Escribes menos JavaScript. Tus aplicaciones son más rápidas. Tus deployments son más eficientes.

Y lo más importante: cuando alguien te pregunta "¿por qué usaste un Client Component aquí?", tienes una respuesta clara.

---

Próximo paso: Revisa un proyecto actual y cuenta cuántos componentes tienen `'use client'` innecesariamente. Apuesto a que encontrarás algunos. Esa es tu oportunidad de optimizar.