Notas del curso Desarrollo de aplicaciones web con React 18

A lo largo de todo el curso hemos desarrollado aplicaciones con interfaz web basada en React y con todo tipo de funcionalidades. Ha llegado el momento de preparar una aplicación para desplegarla y hacerla pública.

En este módulo, exploraremos vías para optimizar la aplicación de cara a su uso en producción, herramientas para realizar un despliegue automático y frameworks para construir tanto aplicaciones más complejas como aplicaciones móviles utilizando React.

Hablaremos de:

• Renderizado en el lado servidor (SSR)
• Generación estática de sitios web
• Next.js
• Frameworks más conocidos para React
• Cómo desplegar aplicaciones React en Vercel
• Cómo crear aplicaciones móviles con React Native y Expo

Un posible inconveniente de las aplicaciones que tienen el frontend desarrollado en React, especialmente cuando se vuelven relativamente complejas, es que todo el renderizado se realiza en el navegador.

En muchos casos, esto conlleva trabajo redundante, ya que se renderizan las mismas páginas en todos los clientes. Piensa, por ejemplo, en el portal de inicio de una aplicación, o en la página de registro de una nueva cuenta: ¿realmente es necesario que el navegador compute el árbol de elementos que hacen falta para mostrarlas cada vez que se visiten?

Lo más probable es que podamos utilizar el propio servidor para resolver parte del trabajo, con el objetivo de que la interfaz de las páginas se cargue mucho más rápidamente.

Vamos a ver las diversas opciones que tenemos en React para conseguirlo.

La tecnología que permite compartir la tarea de renderizado entre el cliente y el servidor se denomina Server-Side Rendering (SSR), y consiste precisamente en preparar la interfaz inicial de una página React en el lado del servidor, de manera que el cliente pueda mostrarla directamente incluso antes de ejecutar cualquier código JavaScript.

La diferencia entre renderizar todas las páginas en el servidor a demanda y utilizar SSR con React es que, con SSR, el servidor solamente tiene que calcular el marcado HTML de la página web en su estado inicial. Una vez que la página llega al navegador se activa la reactividad de forma que se pueda cargar la información dinámica y todas las interacciones tengan efectos sin necesidad de recargar la página de nuevo.

El renderizado en el lado del servidor ofrece la ventaja primordial de que el navegador, para poder mostrar la página, ya no debe esperar a descargar todo el código JavaScript asociado a la aplicación web, con lo que se muestra mucho más rápido y el rendimiento percibido por los usuarios es mucho mayor. Esto es especialmente útil en entornos móviles. Y también que hasta entornos que no soporten JavaScript podrán mostrar al menos esta interfaz inicial.

También existen algunos inconvenientes causados por SSR, principalmente, que la respuesta del servidor puede ser más lenta, ya que debe computar la estructura de la página web a partir de los componentes en lugar de enviar una respuesta HTML casi vacía. Esto implica que el servidor debe tener más recursos disponibles para poder atender a un mismo número de clientes.

Para implementar SSR en nuestra aplicación, React ofrece una serie de funciones en el módulo react-dom/server como renderToString o renderToReadableStream. Estas se pueden ejecutar en un servidor para analizar el árbol de componentes y convertirlo a una cadena (o stream) de marcado HTML.

Por su parte, en el código del cliente ya no se realizará el renderizado inicial del componente raíz, sino que se utilizará la función hydrateRoot de react-dom/client para asociar los elementos HTML ya renderizados con la estructura de componentes.

React es una biblioteca especialmente útil a la hora de crear aplicaciones web de una sola página, pero eso no significa que no podamos aprovecharla para construir cualquier otro tipo de sitio web por medio de componentes. Por ejemplo, es muy sencillo implementar un blog que tome las publicaciones de una base de datos y produzca páginas para cada una, por medio de una herramienta de routing como React Router.

En estos casos, es muy probable que las páginas que se muestren a cualquier cliente sean siempre las mismas y solo cambien cuando se modifiquen los datos. Esto haría posible realizar todo el proceso de compilación de páginas de forma estática, antes de que cualquier cliente la consulte.

El trabajo de renderizado en el servidor, en este caso, consiste en adelantar el cómputo que tendrían que hacer todos los navegadores si construyeran el árbol DOM del sitio web desde cero, generando un conjunto de archivos HTML ya preparados para ser enviados al navegador.

De esta forma, la generación estática facilita respuestas rápidas del servidor ya que las respuestas a todas las posibles peticiones ya se han generado previamente, así como un tiempo de carga prácticamente nulo por parte del cliente, que se limita a mostrar una página web sin comportamiento dinámico.

Sin embargo, esta técnica solo se puede aplicar a sitios cuyos datos no varíen continuamente, puesto que se deben volver a construir tras cada cambio en los datos, y cuyas respuestas no dependan de las solicitudes de los clientes.

Por lo general no será habitual que implementemos manualmente el renderizado en el lado del servidor ni la generación estática de los sitios, sino que contaremos con frameworks construidos alrededor de React que aporten estas funcionalidades. En las próximas lecciones aprenderás más acerca de estos frameworks.