
![Testing Library vs Enzyme](/static/images/enzyme/lab-enzyme.jpg)
<span>Photo by <a href="https://unsplash.com/@nci?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">National Cancer Institute</a> on <a href="https://unsplash.com/?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></span>

# Por qué 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.

```jsx
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:

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

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

```jsx
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.

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

- Desmontar el componente.

```jsx
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](https://github.com/testing-library/react-testing-library/blob/master/src/pure.js#L63)

## ¿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

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

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

```jsx
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.

```jsx
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:

```jsx
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](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](https://testing-playground.com/) donde podemos visualizar nuestro componente (aunque no tenga los estilos demasiado bien) y ver el árbol completo. Para ello, dentro de nuestro test ponemos:

```jsx
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"](https://www.giffgaff.io/tech/react-test-driven-development/).  Esta forma de testear, aunque parece ser "opinionated", es en realidad la forma más efectiva de testear User Interfaces, [evitando testear implementaciones](https://kentcdodds.com/blog/testing-implementation-details/). 

> "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,](https://www.infoq.com/news/2020/03/airbnb-drops-ownership-enzyme/) 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](https://www.npmjs.com/package/@wojtekmaj/enzyme-adapter-react-17) 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, compartiéndolo en twitter y siguiéndome para estar al tanto del contenido que voy creando. Si ves que hay alguna errata y quieres colaborar, puedes directamente [hacer una Pull Request](https://github.com/lucbpz/lucasbernalte.com).

🙋‍♂️ Happy Testing!

Análisis entre Enzyme y React Testing Library sobre cómo renderizan los componentes y qué se puede hacer con ambas. Buenas prácticas de testing.

Por qué usar Testing Library en lugar de Enzyme


![User Interface](/static/images/api-component/user-interface.jpg)

# 4 pasos para crear una buena API de componente reusable

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.](https://www.youtube.com/watch?v=IcgmSRJHu_8) 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](https://kentcdodds.com/blog/make-impossible-states-impossible), 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:

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

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

```jsx
<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í?

```jsx
<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:

```jsx
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`:

```jsx
<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:

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

acepte en su variable data tanto:

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

como:

```jsx
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](https://sandimetz.com/blog/2016/1/20/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:

1. Desarrollamos componente que permite renderizar una lista de items.
2. Creamos la abstracción para que se pueda pasar contenido JSX.
3. Hay un nuevo requerimiento, cada item irá con un icono, y la mayoría de las veces será el mismo.
4. Creamos una abstracción para poder pasar un icono que se repetirá con cada item. Ahora nuestro componente se usaría:

    ```jsx
    <RenderList data={messages} icon="fa-file">
    	<Message />
    	<HiddenMessages />
    </RenderList>
    ```

5. Esta abstracción nos hace pensar en el tiempo que ahorramos con esa nueva prop.
6. Ahora pensamos qué pasa si queremos diferentes iconos y refactorizamos para poder pasar `icons`:

    ```jsx
    <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!

```jsx
expect(newComponent).toBeBetterThan(oldComponent)
```


Cómo crear componentes reutilizables con React para un catálogo de componentes

4 pasos para crear una buena API de componente reusable


![testing](/static/images/testing/QA-engineers-bro.png)
<a style={{margin: '0 auto'}} href="https://stories.freepik.com/work">Illustration by Freepik Stories</a>

## 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](https://twitter.com/lucasbernalte/status/1328609820761583617)).
- 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:

```jsx
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](https://applitools.com/blog/visual-testing-a-guide-for-front-end-developers/)), 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](https://kentcdodds.com/blog/write-tests) de [Kent C. Dodds](https://twitter.com/kentcdodds) 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](https://twitter.com/erinfranmc/status/1148986961207730176?s=20)

> 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](https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests)

Buenos ejemplos de cosas que testear:

1. Comprobar que se ve bien el componente (decide qué significa “bien”).
2. Hacer click en un botón y comprobar que se abre una modal.
3. 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](https://pbs.twimg.com/media/DVUoM94VQAAzuws.jpg)" es tuyo.

[https://twitter.com/kentcdodds/status/960723172591992832](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](https://twitter.com/lucasbernalte). 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.

```javascript
expect(newSuscribers).toBe(oldSuscribers + 1)
```

---

Cómo hacer tests de forma agnóstica en el front, saber qué tests hacer primero y qué testear

Decidir qué testear en Frontend


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.

![logo](/static/images/react-query/logo.svg)

Gracias a [una charla de su autor, Tanner Linsley, en el React Summit](https://www.youtube.com/watch?v=seU46c6Jz7E), 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.

## TL;DR

- 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](https://react-query.tanstack.com/docs/guides/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](https://react-query.tanstack.com/docs/guides/mutations), 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:

```jsx
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:

```jsx
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:

```jsx
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](https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-closure-b2f0d2152b36)), 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 pr[o](https://es.reactjs.org/docs/hooks-reference.html#useref)blema resuelto con la `closure`?
- [Slides de introducción a React Query](https://slides.com/lucasbernalte/react-query-intro):

<iframe src="https://slides.com/lucasbernalte/react-query-intro/embed" width="700" height="420" scrolling="no" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>

---

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](mailto:hola@lucasbernalte.com?subject=Curso%20React%20Query&body=Hola!%20Me%20gustar%C3%ADa%20tener%20acceso%20al%20contenido%20del%20curso%20de%20React%20Query%20en%20Espa%C3%B1ol.%20Gracias!), o directamente por [Twitter](http://www.twitter.com/lucasbernalte). Si quieres además contenido que voy encontrándome por mi camino, no olvides suscribirte a mi newsletter!

Un saludo!


La librería para manejar estado asíncrono en React. Otra más? Qué pasa con Redux?

Introduciendo React Query


Estrenamos la web!

<video autoPlay loop muted playsInline>
  <source src="/static/videos/yay.mov" type="video/mp4"/>
</video>

Hola! Mi nombre es Lucas Bernalte, soy desarrollador web, y voy a hablarte de por qué quiero empezar este blog.

Llevo varios años dedicándome al desarrollo de software y los más recientes enfocados directamente en el desarrollo Frontend. He ido aprendiendo a lo largo de estos años cosas que me gustaría compartir. Por H o por B (por Holgazanería o por “Bagueza”) no había dedicado tiempo a tener mi espacio para publicar estas cosas. Ya sabemos los desarrolladores cómo es este proceso de dejar proyectos a medio terminar (!false story).

Mi idea es compartir conocimiento ya sea técnico, algo más relevante a soft skills, mi propia experiencia o incluso algún conocimiento extra que pueda venir bien a desarrolladores de Frontend para seguir creciendo. 

Ya sé que hay muchas fuentes de conocimiento, y que es difícil estar al día con todas, así que prometo no ser intenso y publicar cuando tenga un contenido de calidad. También quiero poner en marcha una newsletter, donde compartiré artículos que leo, y algunos varios extras pero para eso primero me hace falta saber si tengo gente que quiera suscribirse, así que si te gustaría una newsletter enfocada en artículos o katas de programación en JS, házmelo saber suscribiéndote! Te dejo el link abajo.

Y si te apetece saber algo en concreto puedes hacérmelo llegar por el formulario de la web!

Nos vemos!


Por cierto, los yay! del principio, son cortesía de [Enna](http://www.twitter.com/ennapg) y su bonita tipografía analógica.

Además, el template utilizado para esta web, es de [leerob](http://leerob.io). Mientras desarrollaba mi propio website con Gatsby, tenía algunas dudas
sobre cómo quería hacer ciertas cosas. Me topé con el site de leerob escrito para NextJS y me pareció un buen punto de partida para entender ciertas cosas sobre Next.
Ya tenía integrado buttondown para la Newsletter así que perfecto. He deshabilitado muchas de las funcionalidades que trae (espectacular su trabajo)
y ya iré cambiando ciertas cosas a medida que siga trabajando en él.

👋 Hey, I’m Lucas Bernalte

Últimos Posts

Por qué usar Testing Library en lugar de Enzyme

4 pasos para crear una buena API de componente reusable

Decidir qué testear en Frontend

Suscríbete a mi Newsletter