Senior React Frontend — Preguntas de entrevista React

¿Qué cambia realmente cuando un componente se vuelve un Server Component?

Corre solo en el servidor, así nunca envía JavaScript al navegador y puede hablar con una base de datos directamente, pero no puede tener state, usar effects, o adjuntar handlers. El trabajo de diseño real es trazar el límite: las hojas interactivas se quedan como client components, y todo arriba de ellas puede ser server. Marcar un componente "use client" hace que todo lo que importa también sea client, que es cómo los bundles silenciosamente dejan de achicarse.

Tu app puntúa mal en INP. ¿Cómo lo abordas?

INP mide el delay entre una interacción y la respuesta visual, así buscas tareas largas en el hilo principal durante la interacción. Las causas usuales son una actualización de estado que re-renderiza un árbol grande, un handler síncrono costoso, y la hidratación todavía corriendo. Las herramientas son el Profiler y las entradas de long-task; los arreglos son achicar qué re-renderiza, useTransition para actualizaciones no urgentes, y enviar menos JavaScript.

¿Cómo decides qué pertenece a un componente de design system versus la feature?

Un componente de design system posee apariencia e interacción que debe ser consistente en todos lados, y nada sobre una feature específica. En el momento en que le crece una prop nombrada según una pantalla, se cruzó el límite. La prueba es si un segundo equipo podría usarlo sin leer el código del primero, y si cambiarlo es un release coordinado en vez de una edición local.

Un mismatch de hidratación aparece solo en producción. ¿Cómo lo debuggeas?

Significa que el HTML del servidor y el primer render del cliente no coinciden, y las causas son una lista corta: Date.now o Math.random durante el render, leer localStorage o window en el camino de render, formato de locale o zona horaria, y extensiones del navegador reescribiendo el DOM. Reproduce con render de producción localmente, luego haz bisección suspendiendo partes del árbol. Suprimir el warning es el arreglo equivocado — deja los dos árboles realmente distintos.

¿Cuándo es un monorepo la respuesta correcta para frontend, y cuándo es overhead?

Es correcto cuando varias apps comparten componentes y quieres un cambio revisado y lanzado a través de ellas, con las herramientas — Turborepo o Nx — para mantener los builds incrementales. Es overhead para una app con un par de librerías, donde pagas por configuración de caché y complejidad de CI que no necesitas. La pregunta decisiva es si los cambios cross-package pasan semanalmente o dos veces al año.

¿Cómo migrarías un codebase grande de class components a hooks?

No como un proyecto con su propio deadline. Convierte al tocar: cualquier componente que se cambia por una feature se reescribe, así la migration viaja junto a trabajo que ya iba a pasar. Empieza con hojas en vez de contenedores, ya que tienen menos lógica alrededor. Mantén ambos estilos funcionando indefinidamente y acepta que algunos componentes nunca se convierten — el objetivo es un codebase más fácil de cambiar, no un checklist completado.