React Server Components: la cola larga de la migración

Migrar a React Server Components no es flip-the-switch. Es repensar dónde vive el estado, quién lo posee y cómo se serializa. Los equipos que lo están haciendo bien están tardando meses, no semanas, y los que lo están haciendo mal están acumulando deuda técnica que tendrán que pagar más tarde.

Después de más de un año desde que RSC llegó a producción estable con Next.js App Router, el ecosistema tiene suficiente experiencia acumulada como para hablar de patrones que funcionan y antipatrones que se repiten. Eso es exactamente lo que hemos recopilado hablando con equipos de distintos tamaños.

El modelo mental que más ayuda

La forma más práctica de pensar en la migración es separar el árbol de componentes en dos preguntas independientes:

1. ¿Necesita este componente estado interactivo del usuario? Si sí, es un Client Component. Si no, probablemente puede ser Server Component.
2. ¿Necesita datos que solo están disponibles en el servidor? Si sí, Server Component. Si esos datos vienen de una API externa que también tienes en el cliente, Client Component.

El error más común es intentar convertir todo a Server Components de golpe. El resultado es inevitablemente una cadena de errores de "you cannot use hooks in a server component" que frustra al equipo y genera regresiones.

El patrón que funciona: composición

// Server Component — accede a la DB directamente
async function ProductPage({ id }: { id: string }) {
  const product = await db.products.findById(id); // Sin fetch, sin API
  return (
    <div>
      <ProductDetails product={product} />
      <AddToCartButton productId={id} /> {/* Client Component */}
    </div>
  );
}

El Server Component hace el trabajo pesado de datos; el Client Component solo gestiona la interactividad. La clave está en pasar datos serializables (objetos planos, strings, números) desde el servidor al cliente — no instancias de clases ni funciones.

Lo que más complica la migración

• Context API: los contextos de React no funcionan en Server Components. Los datos globales que vivían en contexto tienen que subir a la URL, a cookies o a un store de servidor.
• Librerías de terceros: muchas librerías de UI asumen que están en el cliente. Necesitan ser importadas desde Client Components o envueltas en wrappers.
• Suspense y streaming: la ganancia real de RSC viene de streaming con Suspense, pero requiere refactorizar cómo se cargan los datos y cómo se muestran los estados de carga.

La buena noticia es que la migración es incremental. Puedes tener un directorio con App Router y otro con Pages Router simultáneamente mientras migras rutas una a una.