Muchos estamos esperando el estreno del nuevo use hook que React anunció desde octubre del 2022. Nos emocionan un par de cosas de este estreno: este hook agregará soporte de primera clase para leer el resultado de una promesa de JavaScript usando Suspense, y la promesa de que funcionará de forma similar a await.

¿Pero qué significa esto y en qué beneficiará nuestra experiencia como «front-ends» al emplearlo?, si quieres saberlo, pues acompáñame a responder 3 preguntas: ¿Qué hace este hook? ¿Por qué el equipo de React, está construyendo este Hook? Y cómo implementarlo en un pequeño ejemplo.

¿Qué hace este hook?

Espera. 😄 Sí, espera.

Este Hook desenvuelve el valor de una promesa, pero lo mejor es que puedes emplearlo no solo en componentes del servidor, también puedes utilizarlo en componentes y Hooks del cliente.

Que es lo que hará la diferencia. 🔥

Esto nos permite, como programadores React, conseguir datos asíncronos arbitrarios con Suspense a través de una API estable. En otras palabras: Vamos a poder hacer consumo de datos asíncronos solo React, y en cualquier parte de nuestro código, gracias a su nuevo use Hook y Suspense.

¿Por qué el equipo de React, está construyendo este Hook?

Aunque los developers de React advierten que este Hook no será una solución completa de data fetching principalmente porque no se ocupa de la memoria cache. Pero al mismo tiempo, React promete también liberar una API llamada cache (qué ingeniosos, sacerdotes de la semántica), que vendrá a ayudar y acompañar al use Hook con esta tarea.

Todo, lo que el equipo de React nos muestra en el RFC (Request For Comments) original es muy interesante para mí. Me parece que hace un guiño a la idea de que React quiere unificar el desarrollo web full-stack, dentro de sí mismo.

Para salvarse del apocalipsis zombie, que el uso de «JSX sin React» le ha profetizado. Pero oye, estas son solo mis especulaciones, no te las tomes tan en serio. 🤓

Pequeño ejemplo de uso:

Esto sería data fetching con componentes de servidor y las ya conocidas «keywords» async/await.

async function Message({userId, isAvailable}) {
  const message = await db.message.findUnique({where:{id:userId}});
  return (
    <div>
      <h1>{message.title}</h1>
      <section>{message.body}</section>
      {isAvailable ? <SaveAction messageId={message.id} /> : null}
    </div>
  );
}

Esto ya lo tenemos actualmente. Además de ser la forma recomendada de acceder a datos asíncronos de un servidor, es decir, de consumir una API de un servidor o de una conexión a nuestra base de datos.

Me dirás: oye, ¿pero, si esta es la manera recomendada y funciona bien, por qué necesitamos otro Hook? La respuesta a esa pregunta, sería que una de las limitaciones más importante de los componentes de servidor asíncronos, es que no pueden usar Hooks y esto nos obliga usar fetch directamente en el componente y a no poder reutilizar toda nuestra lógica en nuestros amados customHooks. 😲

Aunque esto no le parece un gran problema al equipo de React, pues argumentan que los componentes de servidor son stateless y los Hooks son poco útiles en ese entorno de trabajo. Aun así, se pueden utilizar Hooks soportados (como useId) dentro de componentes de servidor que sean funciones regulares, osea, no asíncronas.

Ejemplo de uso del Hook use:

// `use` dentro de un componente o Hook.
const data = use(promise);

// Más o menos equivale a `await` en una función asíncrona.
const data = await promise;

El documento también nos dice que use puede hacer cosas que otros Hooks no. Por ejemplo, podrás emplear este Hook dentro de bloques de código, condicionales y hasta bucles o loops, lo que nos facilitará esperar por cargas de datos sin tener que separar la lógica de nuestro componente.

Veamos el mismo componente, pero utilizando el use Hook:

async function Message({userId, isAvailable}) {
  const message = use(fetchMessage(userId));

  if(isAvailable){
	const suggestions = use(fetchSuggestionsFor(userId));
	}

  return (
    <div>
      <h1>{message.title}</h1>
      <section>{message.body}</section>
      {isAvailable ? <SaveAction messageId={message.id} /> : null}
      { suggestions.length > 0 ? 
		<MoreSuggestions items={suggestions} />
		: null	
	  }
    </div>
  );
}

use No solo nos permite trabajar con promesas, también otros tipos, incluido Context lo que lo hará muy compatible con tu aplicación actual. 🔌

Pregunta final: ¿React se convertirá en un framework?

Recordemos que React solo se encarga de dibujar la interfaz.

React no se hace cargo del ruteo de tu app, ni del manejo del estado global, como tampoco de la comunicación con el servidor. React es solo una biblioteca para dibujar una interfaz. Hasta ahora.

Y esa es la razón de la popularidad de herramientas que te ofrecen todo lo anterior con facilidad, como Next.js, Astro o Remix.

Pero, ¿será que ahora el equipo de React está interesado en caminar la senda del meta-framework? ¿Será que pronto React volverá entrar en el debate infinito, para declarar un ganador?, ¿Dejará React de ser una librería, para convertirse en un framework, o incluso, un meta framework, en el futuro cercano?

No tengo respuestas, solo tengo preguntas y me encantaría saber tu opinión.

Abrazo. bliss.

Enlaces relacionados:

RFC original

Tipos «usables» de use