Ketting v6: Uso de API de hipermedia con React

Bienvenido, soy Luis y para hoy les traigo un nuevo tutorial.

Acabamos de lanzar Ketting 6. Esta es la acumulación de aproximadamente un año de aprendizaje sobre cómo integrar mejor las API REST con marcos frontend, en particular React.

Está repleto de nuevas funciones, como la administración del estado local, nuevas estrategias de almacenamiento en caché, soporte de middleware (del lado del cliente) y eventos de cambio.

También es la primera versión que tiene algunas pausas de BC más grandes para que todo funcione.

Lanzar Ketting 6 es un gran hito personal para mí, y estoy muy emocionado de lanzarlo al mundo y ver qué hace la gente. ¡Muchas gracias a todas las personas que probaron esta versión beta en los últimos meses!

¿Qué es Ketting?

En resumen: Ketting es un cliente REST genérico para Javascript. Puede usarlo para enviar objetos JSON a través de HTTP, pero cuanto más rica sea su API en términos de mejores prácticas y formatos estándar, más puede hacer automáticamente por usted.

Tiene soporte para formatos Hypermedia como HAL, Siren, Collection + JSON, JSON: API e incluso puede comprender y seguir enlaces desde HTML.

A menudo se dice que REST (y las API de Hypermedia) carecen de un buen cliente genérico. GraphQL tiene muchas ventajas, pero una de las principales son las herramientas. Ketting tiene como objetivo cerrar esa brecha.

Reaccionar soporte en Ketting 6

Ketting ahora tiene un reaccionar paquete que proporciona enlaces de React a Ketting. Estos enlaces deberían resultarle muy familiares si ha utilizado Cliente Apollo en el pasado.

Vamos a sumergirnos en un ejemplo:

Supongamos que tiene una API REST que tiene un punto final de 'artículo'. Esto devuelve algo como:

{
   "title": "Hello world",
   "body": "..."
}

Este artículo se recupera con GET y actualizado con PUT, así es como lo mostraría:

import { useResource } from 'react-ketting';

export function Article() {

const { loading, error, data } = 
useResource('https://api.example/article/5');

if (loading) {
return <div>Loading...</div>;
}
if (error) {
return <div class="error">{error.message}</div>;
}
return <article>
<h1>{data.title}</h1>
<p>{data.body}</p>
</article>;
}

Pero ¿qué pasa con las mutaciones? A diferencia de GraphQL, las mutaciones en las API REST suelen tener el mismo formato para GET y PUT, por lo que enviar un recurso actualizado a un servidor a menudo solo significa mutar sus 'datos' y devolverlos.

El siguiente ejemplo permitiría a un usuario editar un artículo y devolverlo:

import { useResource } from 'react-ketting';

export function Article() {

const { loading, error, data, setData, submit } = 
useResource('https://api.example/article/5');

if (loading) {
return <div>Loading...</div>;
}
if (error) {
return <div class="error">{error.message}</div>;
}
const changeTitle = (title) => {
data.title = title;
setData(data);
};
const changeBody = (body) => {
data.body = body;
setData(data);
};
return <form onsubmit={() => submit}>
<input 
type="text"
value={data.title}
onChange={ev => changeTitle(ev.target.value) />
<textarea 
onChange={ev => changeBody(ev.target.value)}>
{data.body}
</textarea>
<button type="submit">Save!</button>
</form>;
}

Cuando setData se llama, la caché interna de Ketting se actualiza con el nuevo estado del recurso. Esto se almacena globalmente, según el uri del recurso.

Esto significa que si se utilizan varios componentes useResource en ese mismo uri, todos los componentes verán esa actualización y activarán una nueva renderización.

Esto es similar al estado local de Apollo, excepto que todavía está vinculado a un único recurso uri y eventualmente se puede guardar.

Cuando submit() se llama, el data se vuelve a serializar y se envía en una solicitud PUT.

Lista no exhaustiva de otros cambios

Planes futuros

Las siguientes dos cosas en las que estamos trabajando son:

Gracias por leer este tutorial.