Los Server Components se ejecutan solo en el servidor, en tiempo de request o de build, y nunca envían su código al navegador; pueden hacer await de una consulta a base de datos directamente, pero no pueden usar estado, efectos ni manejadores de eventos. Los Client Components se marcan con la directiva use client, hidratan en el navegador y se encargan de la interactividad. Por defecto usa server y empuja la frontera del cliente lo más abajo posible en el árbol.
Por qué lo preguntan los entrevistadores
El trabajo con App Router ya es habitual y mucha gente solo ha leído sobre él. El entrevistador quiere saber si entiendes la frontera: qué código llega de verdad al navegador, qué puede cruzar la línea de serialización y por qué el valor por defecto importa para el tamaño del bundle. También está atento a si conoces el truco de composición de pasar hijos renderizados en el servidor a un componente de cliente.
Cómo estructurar tu respuesta
- Empieza por dónde se ejecuta cada uno y qué llega al navegador.
- Nombra los límites concretos: sin hooks, sin manejadores de eventos, solo props serializables.
- Di cuál es tu opción por defecto y qué te hace cruzar la frontera.
- Menciona pasar hijos renderizados en el servidor a una cáscara de cliente.
Ejemplo de respuesta
Yo lo pienso así: los Server Components son para traer datos y renderizar marcado, y los Client Components para todo lo que el usuario toca. Un Server Component corre en el servidor, así que puedo hacer await de una consulta dentro de él, y ni ese código ni esas dependencias acaban en el bundle del navegador. El precio es que no hay useState, ni useEffect, ni onClick. En el momento en que necesito uno de esos, pongo use client arriba del archivo, y todo lo que ese archivo importa se suma también al bundle del cliente. Por eso mi opción por defecto es server y empujo la frontera lo más abajo que puedo. En mi último proyecto tenía un dashboard donde solo el desplegable de filtros y el tooltip del gráfico eran interactivos, así que esos fueron dos componentes de cliente pequeños y el resto de la página, incluido un renderizador de markdown bastante pesado, se quedó en el servidor. Lo que suele pillar a la gente es que las props que cruzan la frontera tienen que ser serializables, así que no puedes pasar una función hacia abajo. El patrón que uso en su lugar es pasar hijos renderizados en el servidor dentro de una cáscara de cliente.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Qué puedes pasar como props a través de la frontera entre servidor y cliente?
- ¿Cómo comparten estado dos componentes de cliente situados en partes distintas de una página renderizada en el servidor?
- ¿Qué pasa si importas un módulo exclusivo del servidor dentro de un componente de cliente?
Más preguntas para Desarrollador React
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas