Forem: Lucas Bernalte

Cómo generar thumbnails automáticamente para tu blog con NextJS y Microlink Cards

Lucas Bernalte — Wed, 06 Oct 2021 06:44:57 +0000

Voy a contarte cómo puedes generar thumbnails automáticamente sin tener que diseñar tú mismo una imagen para cada artículo.
Utilizaremos el servicio que nos da Microlink Cards, y esto te servirá si ya tienes un blog con NextJS o con cualquier otro framework.
En este artículo además veremos concretamente su uso con NextJS para generar un thumbnail el que está generado para este artículo:

TL;DR

Entra en https://cards.microlink.io/editor, elige un preset y cambia los parámetros que necesites.
Asegúrate de tener un <head> configurable en la página de tu artículo.
Copia la URL desde el editor de Microlink y úsala en tu componente con la meta etiqueta og:image.

Usando el `<head>` para poner tags correctas para nuestros artículos con NextJS

Si tienes un blog (y sobre todo, presta atención si el blog lo estás desarrollando tú mismo), por cada artículo que escribes deberías tener etiquetas <meta> dentro del <head> de tu HTML.
Esto es necesario para el SEO de tus artículos. Si quieres que te lean, tendrán que poder buscarte en google, y cuanto mejor sea tu SEO mejor posicionado estarás. Esto no es nada nuevo.
Si utilizas NextJS, ellos mismos tienen un componente que puedes utilizar para agregar cabeceras en cada página, de esta forma:

import Head from "next/head";

function IndexPage() {
  return (
    <div>
      <Head>
        <meta property="og:title" content="My new title" key="title" />
      </Head>
      <p>Hello world!</p>
    </div>
  );
}

export default IndexPage;

y puedes ver más sobre esto en su documentación.

En mi caso, estoy utilizando otro componente, NextSEO, que hace un poco la vida más fácil si estás haciendo tu blog con NextJS.
Puedes ver en el repositorio de este mismo blog el uso que hago del mismo. En el GitHub de NextSEO verás que tienen bastante documentación con muchos ejemplos dependiendo del tipo de contenido. Genial!

Para que veáis un ejemplo sacado de este blog, el componente ya trae las diferentes props que debemos poner, en lugar de preocuparnos por cómo se llaman las meta etiquetas que debemos poner.

return (
  <>
    <NextSeo
      title={`${title} – Lucas Bernalte's blog`}
      description={summary}
      canonical={url}
      openGraph={{
        type: "article",
        article: {
          publishedTime,
        },
        url,
        title,
        description: summary,
        images: [featuredImage],
      }}
    />
  </>
);

Fijaros en este componente. Tenemos dentro de openGraph una propiedad images que será donde pongamos las imágenes relacionadas (o solo una, que será el thumbnail).
Si usáramos el componente <Head> que nos da NextJS (el primer ejemplo) tendríamos que poner nuestra propia etiqueta para la imagen relacionada, que sería algo así:

<Head>
  <meta property="og:image" content="https://link-to-image.png" />
</Head>

Tan solo declarando la propiedad og:image tendremos un thumbnail para cuando queramos compartir nuestro artículo en redes sociales.

Testeando que esto funciona en local

Una vez que tenemos una página publicada, tenemos herramientas para validar el Open Graph de nuestra página, tanto para Facebook como para Twitter:

¿Cómo validamos nuestro open graph desde nuestro entorno local?

Para ello usaremos una extensión de Google Chrome llamada Localhost Open Graph Checker.

Es una herramienta muy simple que al instalarla, nos saldrá el icono en las extensiones de nuestro Chrome. Cuando queramos hacer una validación del open graph, solo tenemos que hacer 2 cosas:

Abrir nuestra página en local.
Pulsar sobre el icono de la extensión.

La extensión cogerá nuestro HTML, y copiará el <head> en una página que subirá temporalmente a una URL. Nos abrirá una página nueva en nuestro navegador donde nos saldrá el enlace para poder copiarlo, así como enlaces a los validadores mencionados anteriormente.

Microlink Cards como generador de thumbnails

Elegimos usar Microlink Cards para generar las thumbnails tras leer este thread de Zeno Rocha.
Microlink Cards tiene su propio editor, donde puedes elegir un preset y personalizarlo con tus propios parámetros.

Puedes jugar directamente con los componentes en el editor, pero lo más fácil es directamente cambiar las query variables que aparecen debajo del editor.
El preset ya viene con unos parámetros configurables que se añaden como query params a la URL para poder generar el thumbnail con el preset elegido y con nuestra propia personalización.

Veremos que cuando abrimos el editor la URL tiene un formato parecido al siguiente:

https://cards.microlink.io/editor?preset=dracula

Y al cambiar la variable title a "Nuestro título" dentro de las query variables, la URL de nuestro navegador cambia a:

https://cards.microlink.io/editor?preset=dracula&title=Nuestro+t%C3%ADtulo

Si hacemos click en el botón Embed nos saldrá un popup, donde podremos elegir lo que mejor nos convenga para nuestro blog.

Si usamos el componente propio de NextJS, podemos elegir la opción SEO tags que nos dará algo como esto:

<meta name="twitter:card" content="summary_large_image" />
<meta name="image" content="https://i.microlink.io/https%3A%2F%2Fcards.microlink.io%2F%3Fpreset%3Ddracula%26title%3DNuestro%2Bt%25C3%25ADtulo" />
<meta itemprop="image" content="https://i.microlink.io/https%3A%2F%2Fcards.microlink.io%2F%3Fpreset%3Ddracula%26title%3DNuestro%2Bt%25C3%25ADtulo" />
<meta name="twitter:image" content="https://i.microlink.io/https%3A%2F%2Fcards.microlink.io%2F%3Fpreset%3Ddracula%26title%3DNuestro%2Bt%25C3%25ADtulo" />
<meta property="og:image" content="https://i.microlink.io/https%3A%2F%2Fcards.microlink.io%2F%3Fpreset%3Ddracula%26title%3DNuestro%2Bt%25C3%25ADtulo" />

Si accedemos a cualquiera de los enlaces que vemos en el content vemos que se abre una URL donde se acaba mostrando nuestro thumbnail! 🎉🎉🎉

Si usamos el componente NextSEO, tendremos que poner ese enlace dentro del apartado de la imagen:

const featuredImage = {
  url: `https://i.microlink.io/https%3A%2F%2Fcards.microlink.io%2F%3Fpreset%3Ddracula%26title%3DNuestro%2Bt%25C3%25ADtulo`,
  alt: title,
};

return (
  <>
    <NextSeo
      title={`${title} – Lucas Bernalte's blog`}
      description={summary}
      canonical={url}
      openGraph={{
        type: "article",
        article: {
          publishedTime,
        },
        url,
        title,
        description: summary,
        images: [featuredImage],
      }}
    />
    // el resto de la página
  </>
);

Aunque en realidad queremos que sea dinámico, así que podemos extraer las query variables a un objeto y convertir la URL de la siguiente forma:

const microLinkCardParams = {
  title, // nuestro título, que lo obtenemos en nuestra página del blog
};
const searchParams = new URLSearchParams(microLinkCardParams);

const featuredImage = {
  url: `https://i.microlink.io/https%3A%2F%2Fcards.microlink.io%2F%3Fpreset%3Ddracula%26${encodeURIComponent(
    searchParams.toString()
  )}`,
  alt: title,
};

// mismo return del ejemplo anterior

Puedes echar un ojo a cómo está solucionado en este mismo blog y el código es prácticamente el mismo.

NOTA: qué hacer si Twitter no muestra el thumbnail.

Una vez terminado todo el proceso y haber testeado en local, me ha pasado que el validador de Twitter no estaba pillando el thumbnail correctamente. Sin embargo, todos los parámetros estaban correctos, la URL era correcta y el validador de Facebook lo pillaba correctamente.
Debe de ser algún bug raro. Para comprobar cómo lo habían implementado en el hilo que mencionaba anteriormente, me fui directamente a la web de https://draculatheme.com/visual-studio-code y miré la diferencia en las imágenes.

El componente NextSEO sólo agrega un item og:image mientras en esta web están todas las etiquetas que genera automáticamente Microlink Cards. Según la documentación de Twitter, con tener una sola og:image basta para que detecte el thumbnail, pero en mi caso no estaba funcionando.

La única diferencia notable en el content es que la URL a la que estaba apuntando no era la misma. En lugar de apuntar a i.microlink.io, está apuntando a microlink.vercel.app.

Haciendo este cambio se soluciona el problema! 🎉🎉🎉

Ya tendríamos thumbnails dinámicos para cada uno de nuestros artículos.

Si te ha gustado este artículo, puedes ayudarme compartiéndolo en Twitter y mencionándome, o escríbeme un DM sin dudarlo!

Por qué usar Testing Library en lugar de Enzyme

Lucas Bernalte — Tue, 16 Feb 2021 10:12:19 +0000

Original: https://lucasbernalte.com/blog/por-que-usar-testing-library-en-lugar-de-enzyme

La librería de testing creada por Kent C. Dodds y mantenida por su comunidad, Testing Library (no podían haber elegido un mejor nombre) ha tenido un tremendo éxito en la comunidad de desarrollo y aun empezando solo con React, ya existen Testing Libraries para Svelte, Vue, Angular, Cypress, etc. Antes de que existiera, los desarrolladores de React utilizaban Enzyme, creada por AirBnB, como su librería de testing.

En este artículo voy a explicarte qué hacen ambas librerías y por qué elegir Testing Library sobre Enzyme como tu librería de testing en tu stack de desarrollo.

Enzyme

Enzyme es una librería de utilidades de Testing para React, que hace fácil la lectura del output de nuestros componentes, teniendo una API intuitiva y flexible.

¿Cómo renderiza Enzyme un componente?

Shallow rendering: para limitar el test de un componente a su propia unidad, es decir, un nivel de profundidad, sin incluir nada de lo que está por debajo.

const MyComponent = () => {
    return (
        <div>
            <h1>Title</h1>
            <Subcomponent type="info" />
        </div>
    )
};

// output de shallow(<MyComponent />) no renderiza Subcomponent
/*
<div>
    <h1>Title</h1>
    <Subcomponent type="info" />
</div>
*/

Full DOM Rendering: Es la única opción de Enzyme que monta el componente, así que tiene que hacerlo en al menos, algo parecido a un browser, como el JSDOM.
Static Rendering API: Genera HTML a partir del árbol de React de tu componente, para poder analizar la estructura HTML resultante.

¿Qué podemos comprobar y testear con Enzyme?

Podemos interactuar con los elementos de dentro de nuestro componente como sus props y métodos, incluso hacer que se actualice, de forma imperativa:

const wrapper = mount(<SomeComponent />);
act(() => wrapper.prop('handler')());
wrapper.update();

Podemos también setear sus props con setProps o sus estado, con setState.

const wrapper = mount(<Foo name="foo" />);
expect(wrapper.find('.foo')).to.have.lengthOf(1);
expect(wrapper.find('.bar')).to.have.lengthOf(0);
wrapper.setProps({ name: 'bar' });
expect(wrapper.find('.foo')).to.have.lengthOf(0);
expect(wrapper.find('.bar')).to.have.lengthOf(1);

Simular algunos eventos.

wrapper.find('a').simulate('click');

Desmontar el componente.

wrapper.unmount();

Testing Library

Testing Library es un set de utilidades de testing simple y completo que promueve las buenas prácticas del testing. Es una ayuda para testear User Interfaces de forma centrada en el usuario.

¿Cómo renderiza React Testing Library un componente?

Hablamos concretamente de React Testing Library, y no de Testing Library a secas, para hacer la comparación con Enzyme, ya que en otro framework, el renderizado sería diferente. React Testing Library usa el mismo método que usamos para renderizar un componente en nuestra aplicación, ReactDOM.render.

Esto hace que cuando se renderiza un componente en el test, pasa por los mismos ciclos de vida que pasa cuando se renderiza "en la vida real" ya que se hacen de la misma forma.

React Testing Library te provee de una función render que hará este renderizado por ti y te devolvera un tipo de dato que contiene queries para hacerle a este componente.

Aquí puedes ver dónde se realiza el render dentro del código de RTL

¿Qué podemos comprobar y testear con Testing Library?

Testing Library tiene como premisa evitar testear implementaciones, así que lo que podemos hacer es interactuar con el DOM o en React, con el JSDOM. Esto implica que podemos:

Comprobar que existe un elemento con queries directamente

document.querySelector('.component-class');

Lanzar eventos, al igual que se lanzan eventos desde el DOM cuando el usuario interactúa con el componente.

fireEvent.click(screen.getByRole('button'))

Comprobar que existe un elemento con las queries recomendadas, para seguir las buenas prácticas, y que las encontramos como respuesta del método render o dentro de un objeto screen, que contiene todo lo que renderizamos en el test. Esto podemos hacerlo de forma síncrona, o asíncrona. El método asíncrono, en realidad internamente, lo intentaría ejecutar varias veces, teniendo un timeout configurable a nivel global o por ejecución.

render(<MyComponent />);
screen.getByText('title'); // síncrono. Lanza error si no existe.
screen.queryByText('title'); // síncrono. Devuelve null si no existe.
await screen.findByText('title'); // asíncrono.

Comprobar que un elemento ha dejado de existir en el DOM:

await waitForElementToBeRemoved(() => screen.queryByText('the mummy'))

Para saber qué query utilizar en cada momento, su documentación nos dice cuáles son las más recomendadas: https://testing-library.com/docs/queries/about#priority

Si necesitamos debuggear un test porque no sabemos qué se está renderizando y tenemos un árbol demasiado grande, no podremos ver bien el resultado en la terminal y se acabará cortando el árbol. Para ello, han desarrollado una herramienta visual, Testing Playground donde podemos visualizar nuestro componente (aunque no tenga los estilos demasiado bien) y ver el árbol completo. Para ello, dentro de nuestro test ponemos:

screen.logTestingPlaygroundURL();

y ya nos saldrá por consola un link que nos llevará a dicha herramienta con nuestro HTML.

Por qué la comunidad está migrando a Testing Library

Si comparamos la opción de Testing Library con el "mount" de Enzyme, serían las más similares. ¿Por qué entonces la comunidad está eligiendo una frente a la otra?

Pues bien, antes de contestar a esta pregunta, es necesario hacerse otra pregunta.

¿Cuántos usuarios tiene nuestro componente?

En la mayoría de los casos, un componente tendrá dos usuarios:

Por un lado, el usuario final, que ve nuestra aplicación e interactúa con él.
El desarrollador que mantiene el código y puede modificarlo, o reutilizarlo en otro sitio.

Cuando agregamos opciones como shallow rendering, o mocks para testear nuestro componente de forma aislada, estamos creando un tercer usuario de nuestro componente: el test. Esto implica que este test necesitará mantenimiento, estará de alguna medida enlazado con la implementación, y cuando ésta cambie, tendremos que cambiar nuestro test. Nuestro código se vuelve mucho más mantenible cuando sólo tenemos dos usuarios.

Testing Library directamente no da una opción shallow precisamente porque su premisa es hacer tests de una forma "Behavior Driven". Esta forma de testear, aunque parece ser "opinionated", es en realidad la forma más efectiva de testear User Interfaces, evitando testear implementaciones.

"We try to only expose methods and utilities that encourage you to write tests that closely resemble how your React components are used."

Tanto es así, que pasó a ser la primera librería de testing recomendada en la documentación oficial de React.

AirBnB, el propio creador de Enzyme, vio el potencial y comenzó su adopción, manteniendo de momento ambas librerías (tenían más de 17000 tests en Enzyme, imposible migrarlo en un commit...). Y en marzo de 2020 AirBnB anunció que iban a hacer el transfer del ownership de la librería, aunque pensaban seguir contribuyendo.

Algunas de los repositorios Open Source más grandes en Github como Storybook o Gatsby ya usan React Testing Library, y algunas como Material UI están desde abril en proceso de migración.

React va a día de hoy por la v17, y Enzyme, al basarse en la propia implementación de React para poder renderizar, necesita de un "adapter" para funcionar, y todavía no han sacado ninguno oficial para la v17, teniendo que instalarse un adapter no-oficial para que pueda funcionar con la última versión.

Mi recomendación

Cada librería tiene su contexto, y hay que entender el contexto y la premisa con la que fueron creadas. La adopción de testear comportamientos por parte de la comunidad es muy grande y es la forma de aportar más valor con tus tests. Yo recomiendo elegir Testing Library para evitar caer en la tentación y testear cosas que no deberías, como props que se pasan de un sitio a otro (estarías testeando la propia implementación de React). Además proporciona una API muy buena e intuitiva para comprobar nuestra UI incluso de forma asíncrona, y la comunidad está haciendo un gran trabajo, extrayendo el core de la librería y sacando a utilidades toda su API para que pueda ser utilizada con cualquier framework. Y también están desarrollando user-event una librería que simula los eventos reales que realizaría un usuario como "click", "doble-click", "escribir", etc.

Si te ha gustado este artículo, puedes ayudarme dándole visibilidad. Sígueme en Twitter para estar al tanto del contenido que voy creando.

🙋‍♂️ Happy Testing!

4 pasos para crear una buena API de componente reusable

Lucas Bernalte — Tue, 22 Dec 2020 16:43:00 +0000

Original: https://lucasbernalte.com/blog/4-cosas-a-tener-en-cuenta-al-crear-componentes-reutilizables

Creando componentes reusables siempre empiezo dudando de qué API debería tener - en un componente hablamos de entradas y salidas, props que entran y eventos que salen - o en el caso de React, métodos que ejecutan.

TL;DR

Evita estados imposibles
Deja espacio para la personalización.
Piensa en la Developer Experience (DX).
Evita abstracciones innecesarias

En este caso, el "Too long, didn't read" nos sirve de índice, ya que vamos a desarrollar cada punto por separado.

1. Evita estados imposibles

Este apartado está fuertemente inspirado en la charla "Making Impossible States Impossible" de Richard Feldman. Básicamente consiste en declarar un modelo de datos que no permite que estados no compatibles colisionen. Si utilizas un lenguaje tipado, te beneficiarás mucho más de esto, pero también podemos hacer esto con JavaScript.

En este otro artículo, Kent C. Dodds lo pone de manifiesto en un ejemplo tal y como lo buscamos, un estado que hemos creado en un componente de React, y que da lugar a posibles estados que no deberían coexistir.

Si tenemos una notificación que puede ser de tipo "info", "warning" y "error", el componente puede ser:

const Notification = ({info, warning, error, message}) => {
    if (info) {
        ...
    }
    return (
    ...
};

así, podríamos usar el componente de diferentes formas:

<Notification error message="error!" />
<Notification info message="info!" />

Sin embargo, estamos dejando al usuario de nuestro componente la posibilidad de utilizarlo mal, colisionando ciertas props sin saber qué va a pasar. ¿Qué pasará cuando el usuario lo utilice así?

<Notification error info message="mensaje" />

Esto que acabamos de ver es algo a evitar cuando estamos creando un componente reutilizable, y más si lo van a utilizar personas de fuera de nuestro equipo, donde debemos dejar un componente completamente testeado y documentado. Tenemos la opción de crear un test para indicar cuál es el comportamiento correcto en este caso:

describe('when error and info are set', () => {
    it('should...')
};

O mejor, evitar ese estado, haciendo que "error", "info" y "warning" sean valores de un type:

<Notification type="warning" message="warning message!" />

Como dice Richard Fieldman en la charla que mencionábamos

Testear está bien, pero lo imposible está mejor

2. Deja espacio para la personalización

Personalizar los componentes que usamos de alguna librería es algo muy común, ya sea simplemente personalizar los estilos de un componente, o personalizar alguna parte de la interfaz, sustituyendo por ejemplo un texto por un componente propio.

Este punto es muy abierto y puede sonar poco definido, ya que dependerá del framework que estemos utilizando, bien podemos usar <slot> si estamos usando WebComponents, o en el caso de React, hacer uso del children o directamente dejar una prop abierta para el componente a renderizar...

Lo que debemos saber de este punto es que puede que el usuario de nuestro componente lo utilice tal cual, o por su caso de uso necesite un punto extra de flexibilidad.

Un ejemplo muy básico sería un componente que renderiza un listado de items. El componente puede renderizar el item como si fuera cualquier cosa, así que podríamos pasar un listado de items que en realidad sería un listado de JSX que renderizará, incluso cada uno puede tener sus onClick correspondientes, haciendo que un componente del estilo:

<RenderList data={messages}>
    <Message />
    <HiddenMessages />
</RenderList>

acepte en su variable data tanto:

const messages = new Array(20).fill().map((_, i) => ({
  content: `Hello, this is message ${i} here. Cool, huh?`
}));

como:

const messages = new Array(20).fill().map((_, i) => ({
  content: <button key={i} onClick={console.log}>button {i}</button>
}));

Evita abstracciones innecesarias

Somos desarrolladores. Buscamos siempre cómo aportar lo máximo con abstracciones para permitir todos los casos de uso posibles. A veces esto nos puede llevar a pensar cosas del estilo: bueno, si hago X, esta feature es gratis, así que por qué no).

Sin embargo esta abstracción que en teoría hacemos para ahorrar tiempo al usuario y darle lo máximo, a veces puede ser innecesaria e incluso perjudicial, haciendo que sea demasiado compleja para un usuario que está iniciándose con nuestro componente, y en lugar de ayudarle, si no consigue lo que ha venido a hacer, incluso desista y no lo use.

Duplication is far cheaper than the wrong abstraction.

Siguiendo el patrón que se comenta en esa charla, y tomando como el ejemplo del componente anterior que renderiza una lista, podemos seguir el siguiente proceso mental que nos lleva el desarrollo del mismo:

Desarrollamos componente que permite renderizar una lista de items.
Creamos la abstracción para que se pueda pasar contenido JSX.
Hay un nuevo requerimiento, cada item irá con un icono, y la mayoría de las veces será el mismo.
Creamos una abstracción para poder pasar un icono que se repetirá con cada item. Ahora nuestro componente se usaría:
```
<RenderList data={messages} icon="fa-file">
    <Message />
    <HiddenMessages />
</RenderList>
```
Esta abstracción nos hace pensar en el tiempo que ahorramos con esa nueva prop.

Ahora pensamos qué pasa si queremos diferentes iconos y refactorizamos para poder pasar icons:

<RenderList data={messages} icons={["fa-file", "fa-file", "fa-danger"]}>
    <Message />
    <HiddenMessages />
</RenderList>

Esto nos ha llevado a una abstracción que parece no ser la mejor a la hora de resolver el problema inicial, ya que el requisito de
renderizar también un icono se podía hacer desde el principio, pasándole al componente una lista de JSX personalizada.

Lo que fue una abstracción universal, ahora se comporta diferente para diferentes casos de uso. - Sandi Metz

Piensa en la Developer eXperience

Crea los componentes para el usuario más importante del mundo - tu "yo del futuro".

Porque todo lo visto anteriormente no tiene por qué ser para un usuario desconocido - puede ser para tu equipo y/o para ti. Y además de pensar en la API, ten en cuenta que una parte del mantenimiento del software es la documentación y el testing, y con el tiempo nos olvidaremos de cosas si no las dejamos por escrito. Redacta una documentación que no dé lugar a dudas y tests que puedan ser usados como documentación, ya que por la sintaxis podemos hacer que se escriban de forma que describan su comportamiento (además es como se debería testear).

La idea es tardar lo mínimo en entender cómo funciona el componente.

Porque la documentación y los tests pueden hacer que "triunfe" nuestro componente, o pueden "romperlo". Cuando un desarrollador está usando tu componente por primera vez, lo primero que hará será leer la documentación. Si tu guía inicial no está clara, puede que pierdas a este usuario.

Tendemos a enfocarnos mucho en los detalles de implementación y perdemos la visión de los desarrolladores que entran por primera vez y necesitan tener una visión clara de lo que van a usar.

En definitiva, también es nuestro trabajo asegurar que se han tenido en cuenta las necesidades del desarrollador.

Piensa en las veces que como desarrollador, cuando buscas un componente has seguido este proceso:

Necesitas X
Buscas y encuentras una librería que en teoría parece que hace X.
No consigues el resultado que buscas, y desistes, desinstalando la librería y buscando otra o fabricándola tú mismo.

Conclusiones

Espero que este artículo te ayude a la hora de crear tu siguiente componente dentro de un catálogo o a la hora de crear un componente de forma aislada o incluso para crear un catálogo de componentes completo. Estos criterios son los que tengo como fundamento, aunque hay casos especiales y tampoco hay que tener un plan para seguirlo 100% a la perfección, pero con estos 4 puntos seguro que ves tu componente de otra manera 😊. Buena suerte!

expect(newComponent).toBeBetterThan(oldComponent)

Decidir qué testear en Frontend

Lucas Bernalte — Mon, 23 Nov 2020 09:02:07 +0000

Original: https://lucasbernalte.com/blog/decidir-que-testear-en-front

Mi visión del testing en Frontend

Desde hace un tiempo me he interesado un poco por encima de la media (tras unos cálculos exhaustivos) en el testing, y especialmente en la parte donde he estado trabajando más, en el Front. En mis últimos proyectos he trabajado con React y con Polymer. Si buscas cómo hacer tests con unos y con otros seguramente te salgan cosas muy variadas.

La realidad es que cualquier framework en Front puede testearse igual.

La realidad es que cualquier framework en Front debería poder testearse igual (o casi).

TL;DR

El conocimiento que se suele encontrar de testing se basa mucho en que aprendas las herramientas, pero no qué testear.
Muchas veces se tiene un concepto erróneo del testing en front, lo que hace que se pongan esfuerzos en cosas no tan eficaces (no olvidar cuál el propósito de hacer tests).
Todos los frameworks en Front deberían testearse igual.
Mira a tu componente a los ojos e identifica visualmente qué deberías testear.
Pon los esfuerzos donde haya más ratio de cosas testeadas por tiempo invertido, es lo que más valor aportará.

Identifica qué testear

Las primeras búsquedas en google sobre testear componentes de React con Jest te redirigen a algunos enlaces donde te explican el setup de Jest con React y hacer un test. Si especificamos un poco más y buscamos algo del tipo "what to test" o "qué testear en front" o "cómo saber qué testear en front" tampoco encontramos mucho al respecto.

Cuando un desarrollador front cambia de framework o de proyecto, el testing no es algo que tendría que reaprender. Si la herramienta usada para testear es diferente, la sintaxis es diferente o hay algo extra que hay que hacer, no pasaría nada, sin embargo ese concepto de saber qué testear en componentes de front no cambia.

Porque lo ideal es testear el frontend tal y como ves los componentes, con tus propios ojos. En definitiva, tal y como lo vería un usuario de tu aplicación.

Elige un componente. Crea el típico test:

describe('MyComponent', () => {
    it('should render correctly')
}

Si te lo estás preguntando, los repos más top en Github y de los desarrolladores más top es muy probable que contengan tests con este típico should render correctly :).

Pregúntate qué sería necesario definir para que MyComponent se renderizara correctamente. Para ello, la manera más sencilla sería irnos al browser, encontrarlo dentro de nuestra vista, o dentro de nuestro catálogo e identificar qué nos ha llevado a decir que estaba viéndose correctamente (puede ser que contenga un texto, un icono, un botón, etc). No tendríamos forma de identificar que tiene una propiedad myProperty con valor 1 , así que no deberíamos poner nuestro foco en testear eso (a lo mejor esto cambiaría si tuviéramos tiempo infinito para testear, pero normalmente no es la realidad).

Testea qué debería verse (no te centres demasiado en el cómo debería verse si no es muy importante, no estamos hablando de visual testing), testea qué debería de pasar cuando el usuario realiza una acción (un click, escribir en un input..) y qué debería de pasar después de esa acción.

Pon los esfuerzos en el test que aporte más valor

Es complicado decir un punto donde poner los esfuerzos a la hora de hacer tests de componentes en front - pero no es complicado decir donde NO debemos poner los esfuerzos.

Hace unos meses di con un artículo que expresa al 100% mi visión sobre el testing de Kent C. Dodds que hace un análisis de una frase del CEO de Vercel, nada más y nada menos. Lo más interesante del artículo es como pone a prueba la clásica pirámide de testing para comentar que esa pirámide no es la ideal si no dejamos de lado el propósito de hacer tests en el front: si hay algo mal en el código, debería estar fallando algún test.

Si ponemos los esfuerzos en hacer tests unitarios de todo, aislando cada pequeña parte que tengamos fuera del contexto, tendríamos que hacer muchos tests para comprobar una pequeña funcionalidad. Sin embargo, con un solo test de integración cubrimos mucho más que con varios tests unitarios, lo que nos proporciona un buen mecanismo para empezar a meterle tests a un componente, e incluso para entender cómo funciona un componente que no tiene tests. Se introduce un concepto nuevo, el de "Test de Integración" pero no hay que confundirlos con los tests de integración de Backend. Estos tests en el front se parecen mucho más a los tests unitarios que a otra cosa - simplemente la unidad pasa a ser un componente contenedor de otros componentes.

Un ejemplo de qué puede pasar si sólo tenemos tiempo para hacer un test y hemos hecho un test unitario:

https://twitter.com/erinfranmc/status/1148986961207730176

Un Test de integración en Front se parece mucho a un Test unitario. Solamente cambia la unidad, que pasa a ser un componente contenedor de otros componentes.

https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests

Buenos ejemplos de cosas que testear:

Comprobar que se ve bien el componente (decide qué significa “bien”).
Hacer click en un botón y comprobar que se abre una modal.
Cerrar la modal y esperar a que se vea el componente con otro estado.

pueden hacerse dentro del mismo test, y podríamos decir que este test "pasa a ser de integración", pero lo ejecutaremos dentro de una suite de tests con nuestro runner de tests unitarios, al ladito de los tests unitarios.

No te preocupes por las opiniones que puedan surgir sobre el testing. Suele haber más opiniones que análisis sobre este tema. Una vez que pones a prueba estos conceptos, empiezas a ver el verdadero valor de los tests. Si recuerdas siempre el propósito que comentamos anteriormente, y empiezas a probar como un usuario interactuaría con tu componente, estarás optimizando el tiempo a la vez que agregando mucha más robustez a tu aplicación. Después de hacer esto, cuando empieces a desarrollar una feature nueva sobre el mismo componente, y veas que algo no funciona, y era por el test, verás que además el test que hiciste en su momento te está ayudando a ti. En ese momento sabrás que el "Testing Trophy" es tuyo.

https://twitter.com/kentcdodds/status/960723172591992832

Si te ha gustado este artículo, compártelo. Quieres hablar más sobre este tema? Empecemos una conversación en twitter. Sería interesante compartir buenos y malos ejemplos, y me gustaría saber qué opináis sobre esto, y si soléis hacer tests, cómo los hacéis y si tenéis alguna duda.

Para estar al tanto de otras cosas en las que voy trabajando y artículos que voy seleccionando, como algunos que comparto en este post, puedes suscribirte a mi newsletter desde mi website.

expect(newSuscribers).toBe(oldSuscribers + 1)

Introduciendo React Query

Lucas Bernalte — Mon, 26 Oct 2020 11:53:11 +0000

Original: https://lucasbernalte.com/blog/introduciendo-react-query

Buenas a todos!

Os quiero hablar de un descubrimiento de hace unos meses pero que hasta ahora no había podido poner en práctica, y que para mí ha sido un antes y un después a la hora de manejar estado en una aplicación en React: React-Query.

Gracias a una charla de su autor, Tanner Linsley, en el React Summit, me decidí tras un tiempo a echarle un ojo, porque me pareció super interesante, y quería compartir con vosotros un poco mis impresiones y los problemas que me ha solucionado.

TLDR;

React Query reduce la complejidad de manejar estados asíncronos.
Podrías pensar que es capaz de “conectar” dichos estados y las queries entre sí.
Distingue entre queries y mutaciones (acciones que cambian datos en BBDD y hacen las queries obsoletas).
Se acabó el gestionar los casos de loadings y error.

Una intro sobre React Query

Siempre me ha parecido que lo que veía sobre gestionar estado en el front no terminaban de resolver los problemas de la asincronía, y requerían de muchos trozos de código iguales, que aunque se podían refactorizar, siempre acababas centrándote en controlar estos estados, y no en lo que de verdad tiene importancia.

Pero qué es React Query?

Pues no es más que una libraría para manejar estado de Backend. React Query puede manejar las peticiones a una API por ti, y puede gestionar cuándo debes actualizar los datos, incluso de forma automática.

Queries y mutaciones

La forma en la que React Query es capaz de identificar cada petición es mediante una key que le indicaremos. Además, distingue entre queries y mutaciones. Las queries las podrá hacer de forma automática, y podrá manejar su estado “fresh” (sus datos están actualizados) o “stale” (sus datos están obsoletos). React Query te proporciona unos hooks para manejarlas, useQuery y algunos más, dependiendo del tipo de query que queramos hacer (podemos hacer paginadas, infinitas...).

Sin embargo, las mutaciones, son aquellas queries que modifican datos en BBDD (por ejemplo un POST, PUT o DELETE en un típico CRUD). Si tenemos una lista de libros que obtenemos con un GET, la edición, adición o borrado de un libro serían mutaciones sobre la lista de libros. Estas mutaciones, no tienen ninguna key al no tener que mantener en caché ningún dato, puesto que son acciones que se realizarían puntualmente. Entonces, el hook useMutation en lugar de recibir la key, recibe directamente la función que realiza la mutación, y una configuración adicional.

Un caso de uso que contiene queries y mutaciones sería el siguiente:

Tenemos una tabla con proyectos en la DB y un CRUD básico en el Backend. Si tenemos en Front un listado y por ejemplo una creación, podríamos tener estas dos queries:

Por un lado la query que se trae los proyectos:

const {data, isLoading, error} = useQuery('GetProjects', getProjects);

El funcionamiento dentro de un componente de React es muy sencillo. React Query por defecto, va a realizar una petición en un componente al montarse cuando esté utilizando un hook como useQuery. Utilizando la query anterior, vemos que nos da un estado de isLoading y al resolverse, nos dará o bien un data o un error. El componente volverá a renderizar cuando cambie uno de estos parámetros y tendremos ese manejo ya controlado de forma automática!

Y por otro lado el método para crear proyectos:

const [createProject] = useMutation(
    service.createProject,
    {
        onSuccess: () => queryCache.invalidateQueries('GetProjects')
    }
);

Podemos vincular el primer parámetro del array que nos devuelve con la acción a realizar (probablemente con algún onClick) y fijaos lo que está pasando. Estamos utilizando una mutation, pasándole la función que va a “mutar” los datos que no controlamos, y luego le pasamos qué hacer en el caso en el que la petición haya ido correctamente en el onSuccess. Y lo que le estamos diciendo en ese onSuccess es que ejecute una función que va a invalidar la query con el nombre ’GetProjects’. Automáticamente si detecta que hay una query invalidada, vuelve a pedir los datos, con lo que se vuelve a repetir el flujo de antes y no haría falta gestionar ese estado de “refresh” tampoco.

Un caso un poco más específico

Pues bien, después de conocer por encima qué serían las queries y qué serían las mutaciones, en mi primera implementación de React Query, vi el caso de uso que tenía delante:

Una tabla que muestra datos (una query paginada).
Acciones de la tabla a nivel de fila y de toda la tabla (mutaciones sobre los datos).

Qué requisitos debe cumplir nuestra implementación?

Debe manejar un estado complejo de la tabla
Debe manejar cancelaciones.
Debe manejar un dato que se obtiene en la primera request, para enviar en peticiones sucesivas.

El componente de tabla que usamos es un componente propio, que nos hace tener que manejar un estado en el componente que lo usa, para guardar ciertos datos (filtrado, paginación, pageSize).

Además para estas peticiones de tabla, necesitamos un parámetro extra que Backend nos devuelve en la primera petición, y que enviaremos en las peticiones sucesivas. Si este parámetro cambiara, tendremos que enviarlo en la siguiente petición y así (temas de caché).

El primer approach fue utilizar una query paginada, añadiendo a la key la paginación, el pageSize y los filtros. Como puedes crear tus propios hooks con React Query, en principio cada query tendrá su propio hook.

Ahora tenemos que añadir el tema de la cancelación y el manejar un dato, así que decidí crear mi hook para manejar todo eso de forma especial para cada petición que tenga que ver con una tabla:

let myParam;
export function useGetMyTableDataQuery(tableState) {
  // Create a new AbortController instance for this request
  const controller = new AbortController();
  // Get the abortController's signal
  const signal = controller.signal;
  return usePaginatedQuery(
    [Queries.QueryName, tableState.page, tableState.pageSize, tableState.filters],
    () => {
      const promise = service.fetchMyTableData({...tableState, param: myParam}, signal);
      // Cancel the request if React Query calls the `promise.cancel` method
      promise.cancel = () => controller.abort();
      return promise.then((resolvedData) => {
        myParam = resolvedData.myParam;
        return resolvedData;
      });
    },
  );
}

De momento para controlar el tema del parámetro que tenemos que guardar para siguientes peticiones, lo haremos a través de una closure (pregunta de examen), guardando el resultado en myParam.

Las acciones que modifican filas o la tabla completa, no tienen más complejidad que la mostrada en el ejemplo con useMutation anterior. Simplemente invalidan la query, o en algunos casos, varias queries (no importa si invalida algunas que no están en pantalla, puesto que no las va a pedir).

Contenido extra

¿Se te ocurre alguna otra forma de resolver el problema resuelto con la closure?
Slides de introducción a React Query

Si te ha gustado este post, ¡tengo para ti otra buena noticia! Estoy preparando un curso de React Query que subiré a una plataforma de e-learning y me gustaría saber tu opinión. El curso será en inglés, pero si te interesa tenerlo en español, házmelo saber vía email, o directamente por Twitter. Si quieres además contenido que voy encontrándome por mi camino, no olvides suscribirte a mi newsletter!

Un saludo!

Forem: Lucas Bernalte

Cómo generar thumbnails automáticamente para tu blog con NextJS y Microlink Cards

TL;DR

Usando el <head> para poner tags correctas para nuestros artículos con NextJS

Testeando que esto funciona en local

Microlink Cards como generador de thumbnails

NOTA: qué hacer si Twitter no muestra el thumbnail.

Por qué usar Testing Library en lugar de Enzyme

Enzyme

¿Cómo renderiza Enzyme un componente?

¿Qué podemos comprobar y testear con Enzyme?

Testing Library

¿Cómo renderiza React Testing Library un componente?

¿Qué podemos comprobar y testear con Testing Library?

Por qué la comunidad está migrando a Testing Library

Mi recomendación

4 pasos para crear una buena API de componente reusable

TL;DR

1. Evita estados imposibles

2. Deja espacio para la personalización

Evita abstracciones innecesarias

Piensa en la Developer eXperience

Conclusiones

Decidir qué testear en Frontend

Mi visión del testing en Frontend

TL;DR

Identifica qué testear

Pon los esfuerzos en el test que aporte más valor

Introduciendo React Query

TLDR;

Una intro sobre React Query

Queries y mutaciones

Un caso un poco más específico

Contenido extra

Usando el `<head>` para poner tags correctas para nuestros artículos con NextJS