Helix Eye es una aplicación React que consume la API pública de la NASA para mostrar imágenes de galaxias y servirá como base para migrar de client side rendering a server side rendering. Si quieres entender cómo se conecta un stack moderno con TypeScript, styled-components y Webpack antes de transformarlo, aquí tienes el recorrido completo.

¿Qué hace la aplicación Helix Eye y qué stack usa?

Helix Eye es una landing page que consume la NASA Image and Video Library para listar galaxias con sus imágenes, títulos y keywords. Tiene dos rutas: el home y la vista de galaxias, ambas manejadas con React Router DOM.

El stack combina varias piezas pensadas para escalar hacia server side rendering:

• TypeScript como base para componentes de React, lo que añade tipos y previene errores antes de producción.
• styled-components para escribir CSS como JavaScript inline, ideal para SSR.
• Webpack como bundler y servidor de desarrollo.
• SWC como loader para transpilar TypeScript, equivalente a Babel pero escrito en Rust y mucho más rápido al compilar.
• Express para servir la aplicación cuando se publica a producción.

La aplicación está construida hoy como client side rendering: se hace el bundle de todos los archivos y luego se publican. La misión del proyecto es convertirla en server side rendering [01:00].

¿Qué es client side rendering? Es cuando el navegador descarga el bundle de JavaScript y arma la interfaz en el cliente. El servidor solo entrega archivos estáticos, no HTML pre renderizado.

¿Cómo descargar y correr el proyecto en local?

El repositorio se llama Helix Eye Custom Server Side Rendering y tiene una rama específica para empezar desde el estado client side. Los pasos son directos:

1. Clona el repositorio y entra a la carpeta con cd helix-eye-custom-server-side-rendering.
2. Lista las ramas con git branch -a para ver las remotas.
3. Cambia con git checkout client-side-render para tener la app ya desarrollada.
4. Instala dependencias con yarn o, si prefieres, con npm install.
5. Levanta el servidor de desarrollo con yarn dev, que abre Webpack en modo desarrollo [02:30].

Yarn es el manejador de paquetes recomendado por su rendimiento, pero npm funciona igual de bien para este proyecto.

¿Cómo se consume la API de la NASA en Helix Eye?

La API usada es NASA Image and Video Library y se consulta con un endpoint tipo search?q=galaxies. La respuesta trae un objeto data.collection.items con título, NASA ID, fecha, keywords y tipo de asset (imagen, video o audio).

Dentro del proyecto, el consumo se centraliza en un hook personalizado que vive en la vista de galaxias. Maneja tres estados: loading, completed y error. La lógica es simple: hace fetch al endpoint, transforma la respuesta a JSON y devuelve data.collection.items para renderizar las tarjetas.

Mientras la promesa está pendiente, se muestra un spinner. Si falla, se imprime un console.error con el mensaje error in request galaxies y se cambia el estado a error. Si todo sale bien, los datos pasan al estado de galaxias y se renderiza el layout.

¿Qué devuelve el endpoint search de la NASA? Un objeto con collection.items, donde cada item tiene data (título, fecha, keywords, NASA ID) y enlaces a los assets multimedia asociados.

¿Cómo están organizados los componentes y estilos?

Cada componente vive en su carpeta con tres archivos: index.tsx para la lógica, styles.ts para los styled-components, y un archivo opcional con interfaces de TypeScript cuando recibe props.

El componente GalaxiesLayout envuelve todas las tarjetas en un div con display: grid. Cada GalaxyCard recibe título, keywords y la imagen, y aplica estilos anidados con clases como .title y .infoContainer directamente dentro del template literal del styled component.

Las media queries también se escriben dentro del mismo bloque. En el componente Hero, por ejemplo, una media query reordena el subtítulo cuando la pantalla pasa a responsive, moviéndolo debajo del título principal.

¿Por qué styled-components funciona bien para SSR?

Las librerías CSS in JS como styled-components son ideales para server side rendering porque los estilos se generan junto con el JavaScript del componente. Eso significa que cuando el servidor renderiza el HTML, también puede inyectar el CSS crítico en la misma respuesta, sin esperar a que el navegador descargue una hoja de estilos aparte.

¿Qué ventaja real aporta TypeScript aquí?

TypeScript no es más que JavaScript con tipos. Si declaras un objeto user y luego intentas acceder a user.name cuando esa propiedad no existe, el editor te avisa antes de compilar. Esa detección temprana evita errores que normalmente solo aparecerían en producción.

¿Cuál es el siguiente paso para migrar a server side rendering?

Imagina que entras a una empresa como Vercel y te encuentras una app client side funcional, pero necesitan un motor de SSR propio. Ese es el ejercicio: no tocar mucho la lógica de cliente, sino construir el tooling que permita renderizar React en el servidor con Express, hidratar en el cliente y mantener los estilos de styled-components sincronizados.

En la siguiente clase empieza la configuración de herramientas para crear ese motor desde cero. ¿Qué parte del stack te parece más retadora de migrar? Cuéntame en los comentarios.