La inyección de initialProps desde el servidor al cliente es la pieza que conecta el fetch hecho en Node con la hidratación de React en el navegador. Si trabajas con server-side rendering manual y React Router DOM, necesitas entender cómo pasar esas propiedades sin romper la hidratación ni perder las ventajas del HTML pre-renderizado.

¿Cómo paso las initialProps desde window al componente App?

El punto de entrada es el archivo index.tsx dentro de la carpeta app, donde ocurre la hidratación. Allí declaras una constante que recoge el objeto inyectado por el servidor en el HTML inicial.

tsx const initialProps = window.initialProps; console.log(initialProps);

Con ese console.log confirmas si el servidor logró inyectar el objeto con las galaxias provenientes de la API de la NASA. Si al recargar ves window.initialProps vacío, el problema no está en tu código de cliente, sino en cómo React Router está manejando la navegación.

¿Por qué window.initialProps aparece vacío al navegar? Porque React Router DOM intercepta los clics del componente Link y hace navegación del lado del cliente, sin pedir el HTML al servidor. Sin nuevo request, no hay script con propiedades inyectadas.

¿Por qué cambiar Link por la etiqueta a en server-side rendering?

El componente Link de React Router DOM evita la recarga completa del navegador. Para SSR, eso significa que pierdes el prefetching del HTML que el servidor ya tiene listo con los datos.

La solución es reemplazar los Link por etiquetas <a href> cuando quieras forzar el cambio de ruta contra el servidor [01:30]. En el componente menu, sustituyes cada Link activo por un anchor tradicional. El trade-off es claro:

• El routing se vuelve más lento porque cada cambio de ruta es un request completo al servidor.
• Ganas prefetching real del HTML con datos ya resueltos.
• Recibes initialProps poblado en cada navegación.

Nada es mejor o peor en términos absolutos. Son intercambios entre velocidad de navegación interna y aprovechamiento del server-side rendering.

¿Cómo desestructuro las props en App y las paso a la página de galaxies?

Una vez que initialProps llega al cliente, lo pasas como propiedad al componente App. Dentro de App lo desestructuras con spread y lo distribuyes a las páginas hijas.

tsx <App {...initialProps} />

En la página de galaxies, el hook que antes hacía el prefetching en el cliente ya no es necesario. Ahora el componente lee props.galaxies directamente. La lógica del spinner cambia: en lugar de depender de un loadingStatus, evalúas la longitud del arreglo.

tsx Galaxies.defaultProps = { galaxies: [] };

Las defaultProps con un arreglo vacío evitan que la aplicación reviente si el servidor no envía datos. Si props.galaxies.length es cero, muestras el spinner; si trae elementos, renderizas las cartas.

¿Qué es un error de hidratación y por qué aparece?

Al cambiar el entorno de production a development en el package.json, los errores dejan de estar ofuscados y se revela el problema real: un mismatch de hidratación entre lo que envía el servidor y lo que renderiza el cliente [05:30].

¿Qué es un error de hidratación en React? Ocurre cuando el HTML generado por el servidor no coincide exactamente con el árbol que React intenta hidratar en el cliente. React lanza una advertencia y descarta la versión del servidor.

Al desactivar JavaScript en el debugger y recargar, ves que el DOM enviado por el servidor no contiene todas las cartas de galaxias. Esa diferencia rompe la promesa de hidratación: ambas versiones deben ser idénticas.

¿Cómo reacciona React ante un mismatch de hidratación?

React descarta la versión del servidor en el nodo afectado y se queda con la versión que construye el cliente. No es catastrófico, pero pierdes parte del beneficio del SSR en ese fragmento.

La razón del mismatch en este caso es que el truco de inyectar propiedades vía window.initialProps es básico. Las soluciones robustas, como las que usa Next.js, manejan la inyección a nivel de request con mecanismos más sofisticados de serialización y reconciliación.

¿Vale la pena inyectar props si hay error de hidratación?

Sí, porque el HTML llega más rápido al usuario y te ahorras el request inicial desde el cliente hacia la API. Esa es la ventaja concreta que conservas incluso con el warning de hidratación presente.

Este patrón es el principio mínimo viable para mover datos del servidor al cliente en SSR manual. Sirve como base conceptual antes de adoptar frameworks que resuelven la hidratación de forma profesional.

¿Te animas a probar este flujo en tu propio proyecto y compartir qué errores de hidratación encontraste?