De Vuex a Pinia. Cómo migrar una aplicación existente

Hola, ¿estás listo para migrar tus proyectos de UX a Pinia? Bueno, empecemos juntos.

Hola, soy Danny, soy de Italia. Soy un desarrollador full stack que trabaja con Python y JavaScript, y por supuesto, Vue.js. Y trabajo para Fingerprint como desarrollador front-end.

Entonces, comencemos hablando de Pinia. ¿Qué es Pinia? Bueno, Pinia es la biblioteca oficialmente reconocida para la gestión de estado en Vue.js. Pinia comenzó como un experimento para rediseñar cómo podría ser una tienda para Vue.js con API de composición. Y por supuesto, intentaron implementar ideas y muchas cosas del equipo central de discusión para VueX5. Y luego vieron que ya estaba allí. Entonces, ¿por qué aplicar de nuevo, los mismos cambios a Vuex para crear VueX5, cuando PNIA ya estaba allí. Así que vamos a darle a PNIA y hacerlo la recomendación predeterminada ahora.

Entonces, antes de comenzar a migrar todo, hagamos una rápida comparación entre VueX y PNIA. Por supuesto, PNIA funciona con Vue.js 2 y 3 con la misma versión instalada. Así que no necesitas instalar, por ejemplo, VueX 3 para Vue.js 2 y VueX 4 para Vue.js 3. Solo necesitas instalar la última PNIA disponible. Y por supuesto que funciona. Y aparte de esto, tiene una API más sencilla que VueX porque las mutaciones ya no existen. A menudo se percibían como extremadamente verbosas. Y de nuevo, con cadenas mágicas para inyectar y así sucesivamente, eran un poco difíciles de usar. Así que no necesitas mutaciones ahora, solo acciones, pero lo veremos en un momento. Y luego no necesitas crear envoltorios complejos personalizados para soportar TypeScript porque, por supuesto, está, de nuevo, siempre implementado como una función o como un objeto. Así que es perfecto con la auto-completación y así sucesivamente. Así que no más cadenas mágicas para inyectar, importar funciones, importar métodos y propiedades, llamarlos y disfrutar de la completación. Y no necesitas añadir tiendas de forma dinámica porque todas son dinámicas por defecto. Es genial. Por la misma razón, no necesitas anidar módulos y no necesitas crear una estructura anidada para tu tienda porque son como con espacios de nombres, puedes decir. Y puedes usar una tienda dentro de otra y funciona. Simplemente genial.

Entonces, comencemos instalando Pina. Pina puede coexistir con Vuex, así que puedes instalarlos juntos.

Si estás utilizando Vue.js 3 o 2.7, puedes simplemente instalar Pina. Eso es todo, pero si estás utilizando Vue.js 2.6, necesitas instalar también Vue composition API porque Pina funciona con composition API. Entonces puedes encontrar una tienda raíz de una manera básica. Así que simplemente importando create Pina y usándolo en tu aplicación. O si estás utilizando Vue.js 2.x, necesitas importar también el plugin Pina Vue y usar el plugin antes de crear Pina. Pero si quieres crear la tienda raíz de una manera avanzada, necesitas crear un archivo index.js en el directorio de tiendas, importando create Pina y creando la tienda. Algo similar para Vue.js 2.x. Y luego en tu archivo main.js, puedes importar tu Pina desde tiendas y usarlo en tu aplicación. Así que, todo lo relacionado con Pina permanecerá en la carpeta de tiendas.

Luego, después de definir la tienda raíz, llamémosla la instancia Pina, necesitas definir al menos una tienda si quieres usar una tienda. Así que, esta es la sintaxis para Vue.js 3.x y 2.x también. Así que, necesitas definir la tienda pasando el nombre de la tienda como primer parámetro, y necesita ser único entre las tiendas. Y como segundo parámetro, necesitas pasar el estado, que es una función que devuelve un objeto. Y luego getters y acciones, por supuesto sin mutaciones, acciones por supuesto, sin mutaciones, pero acciones que cambian el estado de la tienda usando solo esto. Puedes usar una sintaxis de composition API también. Es algo similar al script de configuración, pero lo importante que debes recordar es que necesitas devolver propiedades, getters y acciones en la parte inferior de la función, de lo contrario no funcionará. Pero si recuerdas esto, puedes simplemente definir tus propiedades reactivas, computadas y funciones, y funciona. Es realmente genial.

Ahora, para usar la tienda en tus componentes, necesitas importar store2refs. Store2refs si quieres usar la sintaxis aquí, o simplemente importando la tienda, tu tienda de uso exportada, luego declarando la tienda. Y a partir de ahora puedes usar directamente la tienda, accediendo a las acciones de estado y getters desde aquí. O si quieres usar getters y propiedades reactivas de una manera fácil con variables, puedes definirlas usando una sintaxis computada como esta o como mencioné hace unos segundos, puedes usar store2refs para expandirlas en variables en una sola línea. No necesitas store2refs para acciones porque son funciones simples. Así que puedes llamarlas sin la reactividad. Para Vue.js 2, necesitas importar mapState y mapActions algo similar a Vuex y por supuesto, tu tienda y luego puedes mapear el estado y las acciones para envolver los getters de estado en mapState y acciones, mapActions, por supuesto. Y puedes usar cadenas como lo estábamos haciendo en Vuex en Vuex o puedes mapearlos de esta manera.

Así que ahora es el momento de migrar todo de Vuex a Binia. Pero antes de eso, necesitamos preparar la migración para tener todo ordenado y todo listo para ir. Así que echemos un vistazo a la estructura de la tienda Vuex. Tenemos la tienda con index.js conteniendo la inicialización de Vuex, Importa modules, y la tienda principal y otros modules.

Así que ten en cuenta esta estructura por un momento. Y para la definición de la tienda, te sugiero que cambies ligeramente tu definición de la tienda a esta. Así que extrae todo en una console. Desde los estados predeterminados hasta los getters, mutaciones, acciones y modules. Y luego compónelos en la definición de la tienda para migrarlos uno por uno sin problemas o mezcla de lógica. Lo mismo para el módulo, así que puedes exportar el estado predeterminado, getters, mutaciones y acciones y componerlos en la definición del módulo.

Así que, para migrarlos, solo necesitas cambiar de create store a define store y definir el nombre de la tienda y usar una función para el estado predeterminado. Y todo lo demás es más o menos lo mismo. Solo necesitas eliminar las mutaciones y los modules porque ya no hay más modules para pinyin. Y luego puedes cambiar tu estado. Bueno, no realmente porque el estado es solo un objeto así que puedes dejarlo como estaba y funciona. Solo necesitas cambiar los getters porque, bueno, si estabas usando getters así, hay que cambiar. La sintaxis es la misma. Pero si estabas usando funciones, bueno, estas funciones no necesitan recibir parámetros porque pueden acceder a este contexto, accediendo a otros getters o al estado de la tienda. Así que funciona con esto, no con state o getters. Lo mismo para las mutaciones y las acciones.

Así que, bueno, las mutaciones se convierten en acciones. Y luego si estaban usando un state para acceder a la tienda o getters o otras mutaciones, solo necesitas usar esto y funciona. Lo mismo para la acción, no necesitas pasar el contexto como primer parámetro, solo necesitas usar esto. Y de nuevo es algo genial. Ahora, ¿qué pasa con las pruebas? Bueno, si no encuentras pruebas, por supuesto, las pruebas no fallarán, pero si estás escribiendo pruebas, necesitas migrarlas también. Así que, bueno, si extrajiste la lógica, como mencioné antes, la prueba sobre el estado no cambia porque solo prueban un objeto y esperan que sea como estás esperando. Pero si estás testing getters o mutaciones o acciones, ahora necesitas usar .call para llamar a los getters o acciones, y pasar como primer parámetro del método call, tu estado actual, para probarlo y actuar sobre él. Lo mismo para las mutaciones y las acciones, solo pasa el estado en la llamada, simulando quizás funciones o el estado de la tienda, y puedes usarlo como tu contexto de tienda. Así que vamos a ver un par de ejemplos aquí. Esta es la migración de la prueba de estado. Así que solo necesitas esperar que el estado predeterminado sea igual a lo que necesitas. Para los getters, esto no cambia porque, bueno, lo estábamos usando de la vieja manera. Así que pasando el estado como primer parámetro. Pero en este caso, estamos pasando el code con el contexto.

Lo mismo para las mutaciones. Así que definiendo el estado y pasándolo a la función. Y por supuesto, lo mismo para las acciones. Así que escucha la llamada a otra acción, y llámala, y espera que haya sido llamada. Y bueno, al final, si quieres probar una tienda real para un comportamiento real, puedes hacerlo de esta manera. Necesitas crear binya, y establecer la binya activa en tu archivo de prueba, en el antes de cada caso de prueba. Y en el caso de prueba, puedes definir la tienda, y usarla como la estás usando en los componentes o en tu aplicación, y funciona. No te sugiero esto, porque estás creando una instancia completa de binya antes de cada caso de prueba, por lo que consume bastante memoria. Pero si quieres probar la tienda real, puedes hacerlo de esta manera.

Por último, pero no menos importante, queremos migrar nuestros componentes. Como mencioné, necesitamos importar useStore de la tienda correcta, y usarlo de esta manera. Así que con propiedades calculadas, o con store2Fs en una sola línea. Y simplemente importa la función así desde la tienda y úsalas.

Para Vue.js también, necesitamos eliminar mapState, mapGetters, mapMutation, y así sucesivamente de Vuex y usar mapState y mapAction de vigname. Necesitamos importar useStore y usar mapState pasando como primer argumento el useStore que necesitamos. Y el segundo argumento, una lista de cadenas para propiedades y getters en mapState y funciones en mapActions. Lo mismo para los modules de espacio de nombres. Así que ya no necesitamos crear pañales de espacio de nombres. Solo necesitamos importar el estado actual y usarlo de la misma manera.

Ahora es el momento de probar nuestros componentes usando Pina. Así que si quieres hacer una prueba de componentes adecuada testing para componentes usando Pina, necesitas instalar Pina testing. Esta es una gran dependencia que expone esta función createTestingPina que necesitas llamar. Si usas vtest, necesitas pasar createSpy como argumento definiendo lo que createPina necesita usar para simular tus acciones, por ejemplo. Lo veremos en un momento. Y también puedes pasar el estado inicial. Este es el nombre de la tienda que quieres simular o definir. Y estos son sus valores. Así que vamos a inspeccionar createTestingPina. createTestingPina simula automáticamente todas las acciones. Así que puedes unit test la tienda y los componentes por separado para comprobar el comportamiento de los componentes y el comportamiento de la tienda, pero de manera separada. Y por supuesto, te permite sobrescribir el valor de los getters en las pruebas. Ten en cuenta que esto no funciona con Vue.js 2 y Jet porque no puedes sobrescribir los getters en Vue.js 2, pero en Vue.js 3 es genial. Así que no tienes que trabajar en torno a la configuración del estado de la tienda predefinido para hacer el getter en el valor que necesitas, solo necesitas simular el getter y sobrescribir sus valores. Es impresionante. Así que veamos un par de ejemplos en las pruebas de componentes. Un ejemplo con Vue 3 y VTest es así. Así que antes de cada caso de prueba, necesitamos crear nuestra Pina de testing pasando la función de simulación para el create spy. Y por supuesto, si quieres un estado inicial, entonces puedes encontrar tu tienda así, luego puedes montar superficialmente tu componente pasando Pina como plugins globales. Lo mismo para Vue.js 2 y Jest.

Así que solo necesitas crear una vista local, usar tu plugin Pina y antes de cada caso de prueba, crear la Pina de testing, pasando el estado inicial y encontrando la tienda. Y luego al montar el componente, necesitas pasar la vista local y Pina también. Entonces, un rápido repaso, los getters en Vue.js 2 y Jest no son modificables. Así que necesitas establecer el estado correcto para que funcionen como se espera. Así que así, si quieres establecer el recuento de la tienda, puedes escribirlo o simplemente parchear la tienda si necesitas actualizar más propiedades a la vez. Puedes migrar tus pruebas de esta manera.

Así que moviendo create store e importando create testing Pina y new store. Eliminando el create store de Vuex y usando create testing Pina. Y de nuevo, importando el plugin Pina más largo en el shallow mount y probando todo de esta manera. Lo mismo para VJSU, solo importa lo que necesitas, define tu tienda en lugar de la tienda Vuex y pásala a la función shallow o a la función mount y todo debería funcionar. Bueno, sí, no exactamente. Así que hay un par de problemas de migración. Llamémoslos nudos de migración.

Así que si estabas usando la tienda con un enfoque directo como este, ahora necesitas importar tu tienda y acceder a las propiedades y getters usando la tienda y no más uso mágico de la tienda. Lo mismo para commit y dispatch. Si estabas usando commit y dispatch desde cualquier lugar de tu aplicación, ahora necesitas importar la tienda y llamar a la función actual, la función de acción. Luego otra cosa que necesitas recordar es que si estás usando la tienda de esta manera fuera de la pestaña de scripts, bueno, por favor recuerda no escribir esto en la raíz de tu módulo, de lo contrario puedes obtener este error porque no tienes ActivePynea definido. Así que recuerda prepararlo en una función y usarlo así o usarlo en la pestaña de scripts.

Puedes preguntar si Vuex y Pynea pueden coexistir. Bueno, sí, por supuesto, pero al migrar, por favor recuerda migrar módulos enteros y no componentes enteros. Así que necesitas asegurarte de que un solo módulo ha sido migrado antes de pasar a otro módulo solo por orden y simplicidad de migración. Así que pueden coexistir, pero solo tienes un solo módulo de Vuex y ese módulo puede ser migrado a Pynea, pero otros módulos pueden estar en Vuex mientras se migran. Si necesitas persistencia de la tienda, puedes usarla de esta manera en dos formas, realmente, porque puedes suscribirte a los cambios de tu tienda y establecer tu, por ejemplo, almacenamiento local de la manera que prefieras, y puedes restaurarlo cuando la aplicación se haya actualizado usando mystore.state y settings.state, o puedes observar. Puedes usar un observador en tu aplicación y observar los cambios de estado de Pinion y almacenarlos en una variable de almacenamiento local, por ejemplo. Y si necesitas restaurarlo, puedes usar pinion.state.value y establecer su valor.

Ahora hemos llegado al final de nuestra migración. Como tareas finales, necesitamos eliminar Vuex de main.js. Así que solo elimina tu importación y tu uso de la tienda. Y luego podemos eliminar la tienda Vuex y las pruebas. Y por último, pero no menos importante, necesitamos desinstalar las dependencias de Vuex. Así que Vuex y por ejemplo, el plugin CLI de Vue Vuex. Y eso es todo, hemos emigrado de Vuex a Pinia. Ahora te dejo un par de enlaces por supuesto a la documentación oficial de Pinia y dos repositorios con la rama de migración a Pinia, para que puedas revisar y ver lo que necesitas o lo que puedes querer cambiar para migrar de Vuex a Pinia. Y eso es todo, adiós a todos.