
<LinkToCanonical canonicalUrl="https://javascript.plainenglish.io/how-to-solve-the-problem-with-immutability-and-reducers-in-a-declarative-way-10274691b06c" />

Todas hemos escrito _reducers_ de Redux que tienen mil millones de usos del operador _spread_ (`...`). Nos alegramos cuando funcionan pero no podemos evitar sentirnos un poco mal, dada la verbosidad y el exceso de _boilerplate_.

Voy a tomar prestado un ejemplo de [este artículo](https://www.smashingmagazine.com/2020/06/better-reducers-with-immer/) por [Chidi Orji](https://www.smashingmagazine.com/author/chidi-orji/) en Smashing Magazine, para mostrar a qué tipo de _reducer_ me estoy refiriendo, en caso de que seas suficientemente afortunado de nunca haberte encontrado con uno de estos monstruos en código de producción:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'ADD_PACKAGE':
      return {
        ...state,
        packages: [...state.packages, action.package],
      };
    case 'UPDATE_INSTALLED':
      return {
        ...state,
        packages: state.packages.map(pack =>
          pack.name === action.name
            ? { ...pack, installed: action.installed }
            : pack
        ),
      };
    default:
      return state;
  }
};
```

Este no es tan terrible para ser honesto ¡Créanme, he visto y escrito peores!

¿Cuál es el problema aquí, exactamente? Bueno, si queremos actualizar una propiedad de algún objeto que está muy anidado en nuestro árbol de estado, vamos a tener que copiar mucho estado manualmente para modificarlo y luego retornar nuevo estado. Recordemos: los _reducers_ deben ser funciones puras libres de efectos secundarios, por lo que no podemos realizar mutaciones directamente sobre el estado, sino que retornar una referencia distinta para gatillar una transición.

El problema con usar mucho el operador _spread_ (`...`) en términos de legibilidad y mantenibilidad, es que no nos ayuda a expresar ninguna intención sobre cómo vamos a actualizar nuestro estado. Sólo nos ayuda a copiar cosas, y para cuando llegamos a la propiedad que queremos actualizar, terminamos con un montón de código a nuestro alrededor que no sirve ningún propósito más que replicar la estructura del árbol de estado.

### Haciendo las cosas declarativas

Una de las cosas que los conceptos de programación funcional embebidos en React nos han enseñado, es que expresar intención de forma declarativa hace nuestro código más fácil de entender. Lo hace más fácil para nosotras en el futuro y para nuestras colegas, porque cuando escribimos código lo hacemos para otras personas. Si eso no fuera imporante, escribiríamos _assembly code_ o _byte code_ y los lenguajes de programación de alto nivel no existirían.

Así que en vez de copiar cosas manualmente y luego intentar descifrar qué es lo que el código que escribimos hace supuestamente, es mejor si realmente describimos lo que el código debería hacer. Y la mejor manera de hacerlo de forma declarativa, es utilizando funciones puras.

Démosle un vistazo a cómo la acción `'ADD_PACKAGE'` está actualizando el estado en nuestro ejemplo anterior:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'ADD_PACKAGE':
      return {
        ...state,
        packages: [...state.packages, action.package],
      };
    // ...etc
  }
};
```

Bastante simple, ¿cierto? Un valor nuevo es asociado a la propiedad `packages`, y obtenemos este valor tras adjuntar un nuevo paquete al listado de paquetes.

Definamos algunas funciones para realizar estas operaciones. Primero, definiremos una función llamada `assoc`, que nos ayude a asociar data a una propiedad:

```js
const assoc = (key, value, record) => ({
  ...record,
  [key]: value
});
```

Y luego una función `append`, para adjuntar un valor al final de una lista (sería una versión inmutable de `Array.prototype.push`):

```js
const append = (element, list) => [ ...list, element ];
```

Podemos usar ambas funciones para actualizar nuestro estado:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'ADD_PACKAGE':
      return assoc(
        'packages’,
        append(action.package, state.packages),
        state
      );
    // ...etc
  }
};
```

Ahora, para un caso tan simple como el anterior los beneficios no son realmente visibles. Veamos que sucede con la acción `'UPDATE_INSTALLED'`:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'UPDATE_INSTALLED':
      return {
        ...state,
        packages: state.packages.map(pack =>
          pack.name === action.name
            ? { ...pack, installed: action.installed }
            : pack
        ),
      };
    // ...etc
  }
};
```

En este caso queremos ajustar (o asociar un nuevo valor) la propiedad `installed` de un paquete solo si el nombre del paquete (`pack.name`) es igual a `action.name`. Ahora, si bien podemos utilizar `map` para actualizar el listado de paquetes, esto es conceptuamente erróneo.

Cuando usamos `map`, todos los valores de la colección deberían ser transformados. Decidir si queremos transformar un elemento o no dentro de la colección, es un comportamiento especializado y no particularmente un _mapeo_: estamos realizando una actualización selectiva.

> Hay muchas formas de manejar condicionalidad en el código: la más común es utilizando un `if`. Pero hay mejores formas de manejar condicionalidad, y si la que intentamos modelar implica un cambio de comportamiento, lo que en realidad necesitamos es un comportamiento especializado.

Dicho esto, entonces creemos una función especializada que describa este comportamiento de forma más precisa:

```js
const adjustByWhere = (adjustFn, selectFn, list) => {
  return list.map((acc, item) => {
    return selectFn(item) ? adjustFn(item) : item;
  });
};
```

Probablemente estás pensando: "Trampa! Eso es lo mismo que tienes en el código del _reducer_, solo que genérico". Y sí, es la misma cosa. La diferencia es que ahora tenemos una abstracción que realmente describe la operación que estamos realizando, y ese es todo el punto de hacer programación declarativa: que tu código describa lo que hace, en vez de tener que descifrarlo nosotras cada vez que lo leemos.

Nuestra acción luciría así:

```js
const updateReducer = (state = initState, action) => {
  switch (action.type) {
    case 'UPDATE_INSTALLED':
      return assoc(
        'packages’,
        adjustByWhere(
          package => assoc('installed', action.installed, package),
          package => package.name === 'foo',
          state.packages
        ),
        state
      );
    // ...etc
  }
};
```

Esta solución está lejos de ser perfecta y definitivamente hay mejoras que podríamos aplicar a la API, pero la idea está allí: comenzar a escribir código que te diga lo que está haciendo, en vez de tener que descifrarlo cada vez que lo lees.

### El elefante en la habitación

> Me sentiría sumamente irresponsable si no mencionara `Immer`, porque resuelve este problema de forma brillante. Hablaré de ello brevemente pero si quieres darle un vistazo a fondo, asegúrate de leer la [documentación](https://immerjs.github.io/immer/).

Como diría Miley, `Immer` llegó como una bola de demolición para ofrecer una solución alternativa a este problema: en vez de hacernos copiar manualmente el estado actual de la aplicación para retornar nuevo estado, `Immer` nos proporciona un borrador que podemos actualizar directamente, mutando cualquier propiedad que queramos. Tras finalizar con las mutaciones, `Immer` crea un nuevo estado de forma inmutable usando el borrador que hemos modificado como base. Ese es un truco bastante inteligente, si me preguntas (o si le preguntas a cualquier, es brillante).

El código previo se vería así:

```js
import { produce } from 'immer';

const updateReducer = (state = initState, action) =>
  produce(state, draft => {
    switch (action.type) {
      case 'ADD_PACKAGE': {
        draft.packages.push(action.package);
        break;
      }
      case 'UPDATE_INSTALLED': {
        const package = draft.packages.find(p => p.name === action.name);
        if (package) package.installed = action.installed;
        break;
      }
      default: {
        break;
      }
    }
  });
```

Ahora, esto luce mucho más simple. Sin embargo hay una trampa: cuando usamos `Immer` debemos seguir un par de reglas porque así es como funcionan las cosas mágicas.

En resumen:

- Puedes modificar el estado o retornar un nuevo objet. Si haces ambas cosas, el infierno se desata.
- No podemos asignar directamente un valor al borrador. Podemos cambiar cualquier cosa dentro del borrador (cualquier propiedad de este), pero no el borrador en sí.

Si quieres averiguar más al respecto, checa este inciso en la [documentación](https://immerjs.github.io/immer/return/).

<PostDetailFooter />





Este artículo trata sobre las ventajas de utilizar composición de funciones para describir transiciones de estado en un reducer

Lidiando con reducers e inmutabilidad de forma declarativa

Donde hablo mayoritariamente sobre JavaScript y frontend.

Twitter

Donde subo videos de JavaScript y frontend.

YouTube

Donde subo código, mayoritariamente (sí, lo adivinaste) JavaScript para el frontend.

Lidiando con reducers e inmutabilidad de forma declarativa

¡Hola! 👋

Mi nombre es Osman Cea y soy un ingeniero de software y desarrollador frontend establecido en Santiago de Chile.