Pinia como alternativa a Vuex

Introducción

Vue 3 se ha convertido en la versión por defecto de Vue y parece que su ecosistema ha sufrido una revolución. Si antes las herramientas recomendadas para trabajar eran Vetur, Vue CLI y Vuex; ahora lo son Volar, Vite y, la que nos interesa en este artículo; Pinia.

Pinia no es nuevo, lleva tiempo en desarrollo pero ha sido con la publicación de la versión final de Vue 3 cuando parece que está ganando en popularidad, sobre todo si tenemos en cuenta que el propio Evan You (creador de Vue) es quien recomienda su uso en lugar de Vuex. Es más, para él Pinia vendría a ser Vuex 5. Toda una declaración de intenciones.

Y, ¿qué hace especial a Pinia y por qué podrías plantearlo como una alternativa a Vuex para tus proyectos? Voy a intentar contártelo de forma sencilla en este artículo.

¿Qué es Pinia?

Pinia es una nueva librería de gestión de estados para el ecosistema Vue, desarrollada por Eduardo San Martin, miembro del equipo Core de Vue y, también conocido, por desarrollar el imprescindible Vue Router. Como gestor de estados que es, cumple la misma función que Vuex y otras tantas librerías con el mismo propósito, aunque en este caso, Pinia sería oficial y cuenta con el soporte del equipo encargado de Vue.

Llegados a este punto te puedes preguntar qué ocurre con Vuex. Bueno, en realidad va a seguir contando con soporte y sigue siendo una de las recomendaciones oficiales por lo que no deberías preocuparte. Eso sí, teniendo en cuenta que apunta a ser el sustituto para Vuex, no es mala opción para proyectos que utilicen la versión 3 de Vue para empezar a familiarizarse con Pinia. Sobre todo viendo las ventajas que ofrece, que vamos a ver a continuación.

¿Qué aporta nuevo?

Adiós a las mutations

Si algo se hace pesado al trabajar con Vuex, es el uso de las mutations. Para modificar el state de nuestra store desde un componente primero llamamos a una acción y esta llama a una mutación que será quien modifique el state. Al final esto redunda en que cada cambio de estado requiere bastantes boilerplates, es decir; mucho código repetido.

Vamos a ver como sería una store sencilla en Vuex:

import { createStore } from 'vuex'

const store = createStore({
  state() {
    return {
      items: []
    }
  },
  actions: {
    addItem({ commit }, item) {
      commit('addNewItem', item)
    }
  },
  mutations: {
    addNewItem(state, item) {
      state.items.push(item)
    }
  }
})

Así quedaría con Pinia:

import { defineStore } from 'pinia'

Export const useCartStore = defineStore('cart', {
  state() => ({
    return {
      items: []
    }
  }),
  actions: {
    addItem(item) {
      this.items.push(item)
    }
  }
})

Si en un ejemplo tan sencillo se ve una clara mejoría de nuestro código no es difícil imaginar cómo resultará en un proyecto real.

No hay dispatch ni mapAction

Siguiendo con el ejemplo de store anterior, para llamar desde un componente a la action ‘addItem’ nos podríamos encontrar algo así:

<template>
  // …
  <button @click=”addItem('apple')”>Apple</button>
</template>

<script>
import { mapActions } from 'vuex'

// …
methods: {
  …mapActions([
    'addItem'
  ])
}
</script>

Es algo con lo que nos hemos acostumbrado a trabajar, pero hay que reconocer que a simple vista ya chirría la idea de utilizar un array de strings que hacen referencia a los métodos definidos en la store.

Vamos a ver cómo quedaría en Pinia:

<template>
  // …
  <button @click=”cart.addItem('apple')”>Apple</button>
</template>

<script>
import { useCartStore } from './stores/cart'

// …
const cart = useCartStore()
</script>

En este caso, la acción se llama como si fuese una función normal de JavaScript. Además, te habrás dado cuenta que estamos importando directamente la store que hemos creado, lo que nos da una pista de que podemos trabajar con distintas stores, lo que enlaza con el siguiente punto.

Diferentes stores

En Vuex no podremos tener distintas stores. Sí, es cierto que podemos dividirla en distintos módulos pero esto resulta bastante engorroso, sobretodo cuando importamos algún módulo en nuestro componente:

computed: {
  ...mapState({
    a: state => state.some.nested.module.a,
    b: state => state.some.nested.module.b
  }),
  ...mapGetters([
    'some/nested/module/someGetter',
    'some/nested/module/someOtherGetter',
  ])
},

Por el contrario, en Pinia trabajamos con distintas stores e importamos aquellas que vamos a necesitar en nuestro componente, pudiendo ser una o varias. Además de que acceder a ellas es mucho más sencillo y limpio pues no es lo mismo llamar a una función de JavaScript que utilizando un string para llamar a un método, con los problemas que ello acarrea.

Soporte de DevTools

Una de las ventajas de que Pinia reciba soporte oficial por parte del Core de Vue, es que al igual que ocurre con Vuex, vamos a tener también el soporte de todas las herramientas de desarrollo que ya tenemos en Vuex. Trabajar con las herramientas que acostumbramos en nuestro navegador o IDE a continuar siendo igual de cómodo con Pinia por lo que la migración de una librería a otra debería ser bastante transparente en este aspecto.

Soporte con TypeScript

Otro punto a tener en cuenta es que Pinia cuenta con soporte para TypeScript al contrario de Vuex, que podríamos decir que no es muy TypeScript friendly. Te podrás preguntar qué ventaja tiene esto si tú no utilizas TypeScript. Es sencillo: cuando una librería tiene soporte para él hace que nuestras herramientas de código nos faciliten las cosas con sugerencias automáticas.

Además, la forma de escribir el código fomenta mejores prácticas. Ya hemos visto antes que no accedemos a las mutations mediante un string, como ocurría con Vuex, si no como se fuesen funciones normales de JavaScript:

// Vuex
commit('increment')

// Pinia
this.increment()

Conclusión

¿Debería actualizar mi proyecto que utiliza Vuex a Pinia? Esto es algo bastante personal pero yo, sinceramente, para una aplicación que se encuentra en producción y está desarrollada en Vue 2 con Vuex, no me precipitaría a implementar la nueva librería. Para un proyecto que no va a recibir nuevas features si no que está principalmente en mantenimiento, las ventajas de Pinia no creo que compensen el coste de una migración.

En caso de hablar de un proyecto con una fase de desarrollo por delante amplia o que no se encuentra en sus etapas finales, podría ser bastante interesante plantear la migración de Vuex a Pinia.

Ahora bien, si se trata de un nuevo proyecto, sin lugar a dudas sería mi opción a elegir por todas las ventajas que ofrece. Para alguien que esté familiarizado con Vuex, no va a suponer una curva de aprendizaje elevada. Es más, pienso que va a ahorrar muchos quebraderos de cabeza. Si a esto añadimos que se va a utilizar TypeScript, diría que la elección de Pinia es casi obligada.

Enlaces de interés

Web oficial de Pinia: https://pinia.vuejs.org/