React Server Components — Entrevista

Componente que ejecuta SOLO en el servidor: su código nunca se envía al browser. Accede a la BD/apis directamente y renderiza HTML.

En RSC el componente es async y awaited: los datos llegan antes del render, sin estados de carga en cascada. En client, el efecto corre DESPUÉS de pintar (loader → fetch → repaint).

Server por defecto (datos, await, secrets). Client (`"use client"`) solo lo que necesita interactividad: useState, efectos, event handlers, APIs del browser.

Datos serializables: strings, números, booleanos, arrays, objetos planos, Dates, y elementos React/componentes como children. NO funciones, clases ni instancias.

El client component llega como HTML y React "adjunta" los handlers en el browser (hidrata). Se rompe si el HTML del servidor difiere del primer render del cliente.

Por `children`: el server renderiza el contenido y lo pasa como prop — el client component lo recibe como elemento ya renderizado.

Marca la ruta para renderizarse en cada request (SSR), sin caché estático ni build-time.

Invalida la caché de una ruta tras un mutation para que la próxima navegación vea datos frescos.

Funciones con `"use server"` que el cliente puede llamar como funciones: la llamada viaja al servidor, ejecuta, y devuelve el resultado.

HTML completo con datos en el primer response: indexable sin ejecutar JS y first paint sin waterfall de fetches.

Partir la respuesta en chunks: mandás el shell ya y cada sección lenta (suspense boundary) llega cuando su dato está listo.

Apps 100% interactivas tras la carga (editores, juegos, dashboards con drag&drop y realtime): casi todo termina siendo client components y pagás el server de más.

El punto de entrada del bundle client: ese módulo y TODOS sus imports se envían al browser. No convierte en client lo que está encima.

Porque no hay instancia viva en el cliente donde guardar el estado: el componente corre una vez en el servidor y viaja como resultado.

Next la renderiza ante una URL sin match y cuando una page llama `notFound()`: es la UI de las rutas inexistentes.

No se desmonta el layout: conserva estado y scroll mientras la page se reemplaza. Para forzar re-mount existe `template.tsx` (o sacarlo del layout).

Un límite de Suspense automático alrededor del segmento: mientras el servidor fetchea, viaja el shell con el fallback visible.

Sin await intermedio: `const [a, b] = await Promise.all([getA(), getB()])`. El total es la más lenta, no la suma.

Debe ser client component y recibe `{ error, reset }`: es una error boundary de React, y esas solo existen del lado del cliente.

El hijo espera su dato y recién entonces renderiza al nieto que pide el suyo: latencias sumadas en cadena. Aceptable solo si un dato depende del anterior.

Son dynamic APIs: solo tienen valor con un request concreto, así que leerlas saca la ruta del prerender estático.

Es parte del request (la URL): leerla o awaitearla la vuelve dinámica. Declararla como prop sin leerla no rompe el prerender.

Request memoization (deduplica el mismo fetch dentro de UNA pasada de render), Data Cache (persiste respuestas fetch ENTRE requests), Full Route Cache (guarda el HTML+RSC ya renderizado por ruta).

Te da el estado del resultado dentro del componente: `pending`, el retorno y los errores — sin flags manuales ni onSubmit custom.

Aplicando el estado "esperado" con useOptimistic: la UI refleja el click al instante y React revierte si falla o confirma con el dato real.

Con useFormStatus un componente HIJO del form (el botón) lee `pending` del form ancestro — sin props, sin conocer la action, sin re-render del padre.

El chequeo de Origin: el POST con origen ajeno al Host de la app se rechaza antes de ejecutar la action — CSRF cortado por defecto.

Que no puede streamear: Next espera que resuelva antes de mandar el head; un fetch lento ahí frena todo el documento.

La caché en memoria del browser con los payloads RSC por ruta: Link los precarga y navegar o volver atrás no pide al servidor.

Fetchea en la page (server) y baja los datos a la lista client; la action muta y devuelve estado; la lista aplica useActionState + useOptimistic y confirma al revalidar.

Rompe el build si ese módulo (secrets, queries directas) termina importado por un client component — en vez de terminar silencioso en el bundle.

Handler para consumidores externos: webhooks, APIs públicas, descargas con verbos HTTP reales. Action para mutations disparados desde tu propia UI.

Tag para invalidación por DATO: los fetches etiquetados (`next: { tags: [...] }`) quedan frescos en todas las vistas. Path para refrescar una RUTA completa por URL.

Resize por viewport (srcset/densidades), conversión a WebP/AVIF, lazy por defecto y width/height que reservan el espacio — sin layout shift.