Patrones Probados de Pinia

Hola, mi nombre es Adam Jarr. Soy cofundador de Vue Mastery, el recurso de aprendizaje definitivo para los desarrolladores de Vue. A través de nuestra colección de cursos de Vue, puedes mejorar tus habilidades, elevar tu code y convertirte en el mejor desarrollador de Vue que puedas ser.

Así que en la charla de hoy, vamos a hacer un viaje profundo en el ecosystem de Vue para explorar el planeta de Pinnia. Como todos deberíamos saber ya, Pinnia es la evolución de donde estaba VueX, aportando una versión más nueva, más ligera, más modular, menos prescriptiva, y más liberadora de la state management en nuestras aplicaciones de Vue. Y como dice el refrán, con gran libertad viene gran responsabilidad. Y ahora tenemos más responsabilidad porque podemos ser creativos en cómo implementamos la state management en nuestras aplicaciones de Vue. Y cuando hacemos esto bien, podemos usar Pinnia para desarrollar aplicaciones muy elegantemente arquitecturadas, evitando anti-patrones, y creando una aplicación cuyo estado puede scale a medida que nosotros scale.

Y eso nos lleva al enfoque de la charla de hoy, donde desempaquetamos los probados patterns de Pinnia que puedes usar con confianza en tus aplicaciones, porque esta charla y su contenido fueron aprobados por Posva, o Eduardo San Martín Marrote, el creador de Pinnia. Así que al final de esta charla, habremos cubierto la organización de nuestras tiendas Pinnia, opciones frente a tiendas de configuración, cómo difieren, cuál podrías querer elegir para qué caso de uso, acceso y actualización de tu estado Pinnia. Y también exploraremos algunas características únicas de Pinnia como patch y reset. A lo largo de esta charla, vamos a estar mirando una aplicación de demostración para que podamos aplicar y desempaquetar estas características en un caso de uso más real. Y como puedes ver, esto es un Buscador de Restaurantes. Vas a escribir la ciudad y buscar en Sherm para encontrar restaurantes dentro de una cierta área, y el usuario puede registrar una cuenta. Pueden guardar sus favoritos, y pueden leer información extraída de la API de Google Maps, como calificaciones y reseñas. Esta aplicación va a estar rastreando cada una de sus preocupaciones lógicas a nivel global con sus propias tiendas Pinnia, y vamos a cubrir todo esto a lo largo de la charla, así que comencemos.

Antes de profundizar en los conceptos de Pinnia, aclaremos primero por qué querrías usar Pinnia en primer lugar, porque Vue 3 ya tiene la composition API con un sistema de reactivity incorporado con la flexibilidad para compartir y reutilizar el estado. Simplemente usando la composition API, podríamos crear un objeto reactivo para servir como una tienda para gestionar nuestro estado global. Luego simplemente importaríamos esa tienda en cualquier componente que la necesite, y debido a cómo funciona el sistema de reactivity de Vue, cualquier componente que importe esa tienda puede mutar directamente su estado global. Y si ese estado cambiara y tuviera una plantilla que estuviera mostrando ese estado, esa plantilla cambiaría de forma reactiva también.

Entonces, de nuevo, si podemos simplemente usar la composition API para crear una versión mínima y fundamental de state management en una aplicación de Vue 3, ¿cuándo exactamente necesitaríamos una biblioteca de state management como Pinnia? Bueno, va a ser útil cuando quieras tener patrones consistentes para la organización colaborativa. Esto es especialmente importante para los grandes equipos que están colaborando en una aplicación a gran escala. Un patrón que podrías querer seguir de manera colaborativa es una forma predecible de mutar el estado y las acciones dentro de Pinnia nos permiten lograr eso. La seguridad de SSR es otra cosa a considerar y por qué podrías querer usar Pinnia porque cuando estás usando la renderización del lado del servidor, necesitarás tener cuidado con cómo gestionas el estado global ya que las aplicaciones de SSR, inicializan los módulos de la aplicación en el servidor y luego comparten ese estado en cada solicitud. Por lo tanto, esto podría llevar a vulnerabilidades de seguridad, pero Pinnia fue diseñado para hacerlo más seguro y fácil para gestionar el estado en esas aplicaciones renderizadas en el servidor. Además, al usar Pinnia, obtenemos las DevTools y toda la transparencia y la visión útil que esas herramientas pueden proporcionarnos. Esto va a hacer que la depuración y la comprensión real del estado de nuestras aplicaciones sea mucho más clara. Cada vez es más importante para los desarrolladores de JavaScript trabajar con herramientas que tengan soporte para TypeScript, y Pinnia tiene un soporte de primera clase para usar TypeScript. Todas estas razones combinadas crean una experiencia de desarrollo suave e intuitiva cuando estás usando Pinnia para gestionar el estado en tus aplicaciones. Por lo tanto, si tus necesidades incluyen cualquiera de las cosas que he enumerado en esta lista aquí, probablemente vas a querer decidir usar Pinnia en lugar de simplemente confiar en la Composition API para tus necesidades de state management. Así que todo esto para decir, cuando usas Pinnia, vas a estar empoderado con una forma robusta y refinada de gestionar el estado en tu aplicación, arquitectándola de una manera que puedas depurar y colaborar bien entre tu equipo. Entonces, ahora que tenemos claro cuándo exactamente querríamos usar Pinnia, comencemos a explorar esas características.

Cuando estás usando Vue 3, puedes elegir usar la API de opciones o la API de composición. De manera similar, cuando estás usando Pinya, puedes definir tus tiendas como opciones o tiendas de configuración. La configuración se refiere a la función de configuración dentro de la versión de la API de composición de una tienda Pinya. No hay una respuesta correcta o incorrecta sobre cuál deberías usar en tus aplicaciones, pero exploremos las diferencias para que puedas ver cuál podría ser mejor para tu caso de uso específico.

Primero, revisemos cómo definimos cada tipo de tienda Pinya. Cada vez que queremos crear una tienda, ya sea una tienda de opciones o una tienda de configuración, primero importamos define store de Pinya. Luego pasamos una cadena como primer parámetro para el nombre de la tienda. Esta cadena debe ser única, ya que Pinya la utilizará para realizar un seguimiento del estado de tu tienda y también se mostrará en las herramientas de desarrollo. También será útil cuando comiences a usar complementos en Pinya. Así que asegúrate de tener un nombre único y comprensible para cada una de tus tiendas al definirlas.

Ahora, echemos un vistazo a la estructura de una tienda de opciones. No es coincidencia que este tipo de tienda reciba un objeto como segundo parámetro de la función define store. Los estados, acciones y getters aquí son realmente análogos a los métodos de datos y propiedades computadas cuando escribes un componente con la API de opciones. Por otro lado, con una tienda de configuración, el segundo parámetro que pasas a define store es una función. Este tipo de tienda te resultará familiar en cómo compones un componente con la API de composición. Creamos el estado con ref o reactive. Nuestra acción es simplemente una función y nuestro getter es una propiedad computada. Y observa cómo estamos devolviendo todo lo que queremos que sea accesible para otros componentes. Esto también hará que todo lo que se devuelva sea rastreable por las herramientas de desarrollo, así que asegúrate de no olvidar hacerlo.

En última instancia, como mencioné anteriormente, si usas tiendas de opciones, tiendas de configuración o ambas en tu misma aplicación, eso dependerá de ti y de tu equipo, pero quería explorar algunas de las ventajas que tienen las tiendas de configuración. Estas tiendas nos permiten aprovechar el sistema de reactividad de Vue 3, lo que significa que podemos usar fácilmente composables en esas tiendas, como los composables de la biblioteca vue-use. También podemos usar watchers fácilmente en ellas. De hecho, usamos ambos en la aplicación de demostración a la que hice referencia al principio de la charla. Echemos un vistazo a eso. Observa este comportamiento, donde si el usuario no escribe nada en el campo de la ciudad, se encontrará automáticamente su ubicación actual. Si examinamos el código dentro de una tienda en este proyecto llamada geolocalización, podemos ver que es una tienda de configuración y su funcionalidad depende del componible usegeolocation de vue-use para obtener las coordenadas del usuario. Mientras tanto, los watchers están pendientes de esas coordenadas para activar una acción y obtener los datos de ubicación de la API de Google Maps.

Entonces, nuevamente, podemos usar tanto ese componible como el watcher dentro de esta tienda de configuración. Ahora, es importante entender que PINIA es modular y lo es por diseño. Esto significa que su propia API nos anima a dividir nuestro estado en dominios manejables. Esto se compara con Vue X, donde teníamos un archivo de tienda raíz y luego módulos que se desprendían de él. Con PINIA, creamos tiendas dedicadas a cada preocupación lógica principal de nuestra aplicación y luego podemos importar esas tiendas donde sea necesario. Esto nos ayudará con la división de código en los empaquetadores, nos dará mejores inferencias de tipo si estamos usando TypeScript, mejorará la colaboración en equipo y agregará claridad para la depuración.

Sin embargo, cuando se trata de poner en práctica esta modularidad, no siempre está tan claro dónde y cómo se deben dividir esas tiendas según el tema o el dominio que les concierne. Esto nos lleva al tema de la organización de las tiendas o, como me gusta llamarlo, organización de las tiendas.

Echemos un vistazo a nuestra aplicación de ejemplo para ver una forma sencilla y obvia en la que separaríamos nuestras tiendas, y luego veremos una forma un poco más compleja y sutil. En la aplicación de ejemplo, nuestro usuario puede registrar una cuenta y la interfaz de usuario cambiará dependiendo de si el usuario ha iniciado sesión. Si lo han hecho, veremos su nombre y los favoritos en la barra de navegación. Para lograr este comportamiento de autenticación, necesitamos realizar un seguimiento del estado del usuario y también de las acciones relacionadas con ese estado, como el registro, inicio de sesión y cierre de sesión. Es bastante obvio que todo esto se puede agrupar en una sola tienda y podríamos llamarla tienda de autenticación. Pero no todas las tiendas van a ser tan intuitivas en cuanto a cómo se deben organizar los contenidos.

Veamos una forma menos obvia en la que organizaríamos las tiendas en nuestras aplicaciones Pinia. ¿Recuerdas cómo en nuestra aplicación de restaurantes tenemos dos campos de entrada? El primer campo de entrada recibe la ciudad y el segundo recibe el término de búsqueda para encontrar restaurantes locales relevantes cerca de esa ciudad. Ambos campos de entrada tienen escuchadores de eventos que activan una función cuando el usuario escribe texto. Cada función realiza una llamada a la API de Google Maps. Específicamente, el campo de entrada de la ciudad va a solicitar la latitud y longitud de la ubicación escrita por el usuario, mientras que la búsqueda va a realizar una llamada para obtener los restaurantes relevantes dentro de una cierta distancia de esa ciudad. En otras palabras, tanto el campo de entrada de la ciudad como el de búsqueda utilizan la geolocalización, específicamente con la API de Google Maps. ¿Deberíamos combinar esto en una sola tienda? Tal vez podríamos llamarla Google Maps. Bueno, cuando miramos nuestro proyecto en su conjunto, hay varias acciones que van a depender de la API de Google Maps. Eso sería mucho código que estaríamos metiendo en una sola tienda. Y lo que es más importante, las acciones no van a estar todas relacionadas con el mismo tipo de preocupaciones lógicas. Para tener claridad sobre cómo se debe organizar todo esto, podemos desglosarlo y centrarnos más en para qué se está utilizando realmente la API de Google Maps y qué estado necesitamos rastrear. Cuando hacemos esas preguntas, sabemos que el primer campo de entrada se utiliza para hacer solicitudes de geolocalización, mientras que el segundo se ocupa de los restaurantes que coinciden con el término de búsqueda. Sí, esos restaurantes están cerca, por lo que hay un aspecto de ubicación relacionado con los restaurantes, pero no es su enfoque principal, como lo es el otro campo de entrada que realmente realiza esas solicitudes de geolocalización. Basándonos en este razonamiento, parece que podemos crear dos tiendas separadas, cada una con sus preocupaciones lógicas compartidas, geolocalización y restaurantes. Pero es posible que estés pensando que, en la tienda de restaurantes, cuando solicitamos esa lista de restaurantes relevantes, necesitamos utilizar los datos de geolocalización de la tienda de geolocalización. ¿Arruina eso por completo nuestro enfoque? Bueno, no, en realidad no, porque eso nos lleva a otro punto dentro de Pinia, que son las tiendas anidadas. Con las tiendas anidadas, podemos tener una tienda y luego anidar otra tienda dentro de ella según lo que su padre en este contexto hubiera necesitado. Estamos avanzando en la comprensión de algunas de las características de Pinia. Hasta ahora, algunos puntos clave a tener en cuenta son que debemos agrupar los datos relacionados en sus propias tiendas según las preocupaciones lógicas.

También podemos organizar nuestras tiendas por características dentro de nuestra aplicación. No necesariamente queremos asumir que una tienda debe crearse en torno a una API o una biblioteca, y podemos compartir el estado entre tiendas anidando esas tiendas una dentro de la otra.

Ahora que hemos cubierto todo eso, veamos el tema de cómo accedemos a nuestro estado dentro de Pinia. Mientras que otras bibliotecas de gestión de estado pueden ser muy prescriptivas y realmente obligar a los desarrolladores a acceder y modificar su estado de una manera específica, esto puede llevar a una sobrecarga innecesaria y cierta rigidez que puede sentirse limitante. Pero una de las formas en que Pinia proporciona flexibilidad es permitiendo a los desarrolladores tomar sus propias decisiones sobre los patrones que están utilizando. Así que veamos cómo podemos acceder al estado dentro de Pinia y las opciones que tenemos para hacerlo.

Si estamos en una tienda en sí, tenemos acceso a las propiedades del estado dentro de nuestras acciones y getters. Pero hay algunas consideraciones a tener en cuenta ya que las cosas son un poco diferentes entre una tienda de opción y una de configuración. En una tienda de opción, si estamos en una acción y necesitamos acceder al estado, podemos hacerlo utilizando 'this'. Dentro de un getter en una tienda de opción, vamos a necesitar pasar el estado a ese getter para poder acceder a él. Por otro lado, en una tienda de configuración tanto para acciones como para getters, accedemos directamente a la propiedad de estado, tal como lo haríamos dentro de la función de configuración y el componente que utiliza la API de composición. En este ejemplo, la propiedad de estado es una referencia, por lo que se escribe como city.value. Y por supuesto, debemos recordar devolver todo para que sea accesible fuera de la tienda.

Ahora, ¿qué hay de acceder a piniaState desde dentro de un componente? Ahora, va a haber algunas formas de hacer esto, la más común de las cuales es importar la tienda en el componente de vista en sí y luego invocar la función useStore. Esto nos permitirá leer el estado y escribir en ese estado utilizando la notación de punto. Sin embargo, el uso de la notación de punto podría volverse engorroso si estamos utilizando muchas propiedades de estado diferentes en un componente.

Entonces hay una forma más eficiente de hacer esto. Vamos a facilitarnos mucho la vida al desestructurar las propiedades de la tienda para no tener que escribir ese nombre de tienda todo el tiempo que estamos accediendo y escribiendo y leyendo en ella. Pero debemos tener cuidado de cómo hacemos esto. Nuestro primer instinto podría ser hacer algo como esto, pero esto en realidad va a romper la reactividad. En Vue 3, no podemos desestructurar props a menos que usemos un ayudante llamado toRefs. Es posible que ya estés familiarizado con esto. Y en Pinia, de manera similar, no podemos desestructurar propiedades de estado a menos que usemos un ayudante de Pinia llamado storeToRefs, y esto mantendrá la reactividad intacta.

Ahora, podemos hacer uso de este estado desestructurado para agregar nuevos data en él. Ahora veamos cómo funcionaría vModel si lo estamos usando con una tienda de Pinia. Podemos usarlo para vincular algo como nuestra entrada aquí al estado de Pinia para que nuestra plantilla se mantenga sincronizada con la tienda y reaccione en consecuencia. Estas son algunas formas comunes de acceder a nuestro estado de Pinia. Y algunos puntos clave que quiero que recuerdes son que en una tienda de opción, podemos usar this. En el getter de una tienda de opción, pasamos el estado. En una tienda de configuración, accedemos directamente a las propiedades de estado. No usamos this. En un componente, podemos desestructurar las propiedades de estado con el ayudante StoreToRefs. Y luego podemos usar vModel para vincular un valor en nuestro componente con el estado de nuestra tienda.

De acuerdo, hemos visto algunas formas de acceder a nuestro estado de Pinia. Ahora, ¿cómo mutamos ese estado? Como recordatorio, cuando vemos cómo funcionaba Vuex, cuando mutábamos el estado, enviábamos una acción, esa acción luego procedía a realizar una mutación. Y esta era realmente la única forma recomendada de mutar el estado, a menos que tal vez estuviéramos rompiendo ese patrón y esas prácticas recomendadas. Pero por supuesto, Pinia es diferente. Ya no tenemos ese paso de mutación, y ahora tenemos mucha más flexibilidad en cómo actualizamos nuestro estado.

La forma más común de mutar el estado en Pinia es desencadenar una acción en esa tienda, lo que provoca que ese estado cambie. En este ejemplo, hacer clic en el botón Agregar a favoritos desencadena la acción Agregar a favoritos en la tienda de Favoritos. Ahora, a algunas personas les sorprende saber que esta no es la única forma de cambiar y mutar el estado en Pinia. También podemos cambiar el estado directamente asignando un nuevo valor a la propiedad de estado. En este ejemplo, tenemos un observador en el valor de la ciudad, y luego, si el usuario elimina la ciudad, borramos directamente esas propiedades de estado para que el usuario pueda realizar una nueva búsqueda.

Otra forma de actualizar el estado es usar el método patch de Pinia. Esto nos permite aplicar múltiples cambios al mismo tiempo en el estado de una tienda. Aquí, observa cómo pasamos un objeto con las propiedades de estado actualizadas dentro de él. Ahora, el uso de patch tiene algunos beneficios adicionales porque creará una única entrada en las herramientas de desarrollo, y si seguimos esta convención en toda nuestra aplicación, podríamos buscar fácilmente patch para localizar todos los lugares dentro de nuestra aplicación donde estamos actualizando el estado en bloque de esta manera. Otra cosa útil a tener en cuenta sobre patch es que puede tomar un objeto o una función como parámetro. Por ejemplo, si nuestra propiedad de estado fuera un array, podríamos usar métodos de array para actualizar nuestro estado en consecuencia.

Convenientemente, Pinia también ofrece un método reset. Por lo tanto, podemos restablecer todo el estado de una tienda a su valor inicial. En este ejemplo, el método reset se utiliza dentro de la propia tienda para borrar el estado de nuestra tienda de autenticación. Observa cómo estamos en una tienda de opciones, por lo que estamos usando this. También podemos usar reset en un componente de esta manera. Usar el método reset de esta manera es muy útil cuando queremos actualizar una tienda completa de una vez, como cuando un usuario navega a una página determinada. Por ejemplo, veamos este ejemplo en el archivo del enrutador donde usamos el método reset de Pinia en el propio enrutador. Aquí estamos diciendo que cada vez que el usuario regrese a la página de inicio, borre esa búsqueda anterior. Ahora, desafortunadamente, el método reset no está disponible en las tiendas de configuración, por lo que esta es una de las formas en las que la tienda de opciones definitivamente tiene una ventaja sobre la tienda de configuración. Y si te preguntas por qué es así, es porque el método reset depende de la función de estado para crear un estado nuevo, reemplazando el estado actual de la tienda por uno nuevo. Pero no tenemos acceso a la función de estado en una tienda de configuración. Pero si aún quieres esa funcionalidad donde restableces una tienda completa, pero es una tienda de configuración, por lo que no puedes usar un método reset, puedes escribir tu propia función de configuración que logre lo mismo, donde escribas una acción que restablezca toda la tienda, como se muestra aquí. En cuanto a la mutación de nuestro estado, Pinia también ofrece un método útil que podemos usar para obtener información detallada sobre nuestras acciones. Este se llama el método onAction.

Y como puedes ver, este método tiene varios ganchos que podemos usar para realizar alguna lógica cuando ocurre una determinada acción. Observa cómo podemos pasar el estado como segundo argumento en caso de que lo necesitemos. Aquí, en este ejemplo, se utiliza para registrar información sobre qué acción se ha desencadenado en la tienda de autenticación. Para ver esto en funcionamiento, podemos mirar dentro de la consola y efectivamente vemos el nombre de la acción, así como los argumentos que se le pasaron.

Entonces, como puedes ver, Pinia es una forma evolucionada y flexible de diseñar y gestionar el estado en nuestras aplicaciones. Si quieres seguir aprendiendo sobre las características y patrones dentro de Pinia, te invito a realizar el curso Patrones de Pinia Probados en ViewMastery.com. Eso incluirá todo lo que acabas de ver en esta charla y más, donde exploramos complementos y cómo extender la funcionalidad de Pinia con tus propios comportamientos personalizados.

Y en nuestro sitio web, tenemos una lista completa de cursos de Pinia. Así que si tú o tus compañeros de equipo necesitan comenzar con los fundamentos, puedes construir una aplicación de lista de tareas con nosotros. También tenemos una sesión de preguntas y respuestas con el creador de Pinia, Eduardo, para que puedas aprender un poco sobre las preguntas comunes que la gente tiene y sus respuestas. Acabamos de lanzar un curso exclusivo impartido por Eduardo llamado 5 Formas Elegantes de Usar Pinia. Así que realmente puedes adentrarte en la mente de la persona que escribió la biblioteca y usarla como un profesional.

Y, por supuesto, ser la plataforma de aprendizaje definitiva para los desarrolladores de Vue significa que tenemos contenido sobre una amplia variedad de temas. Así que si estás buscando contenido sobre NUX, puedes construir un blog con el módulo de contenido de NUX. Puedes aprender sobre el middleware de NUX, el servidor de NUX y comenzar a adentrarte en conceptos de NUX de pila completa. Si eres fan de los composables de la biblioteca Vue-Use, puedes realizar nuestro curso de Mejores Prácticas de Composables y aprender cómo crear los tuyos desde cero. Puedes aprender a utilizar CSS de utilidad primero con la popular biblioteca Tailwind, y tenemos contenido exclusivo impartido por el creador de Vue y Vite, Evan Yu. Todos estos cursos y más se pueden encontrar en nuestra biblioteca completa de contenido que puedes utilizar para convertirte en el mejor desarrollador de Vue que puedas ser.

Si eres parte de un equipo que utiliza Vue, te invito a unirte bajo una cuenta de equipo y, cuando lo hagas, puedes obtener un descuento del 55% para acceder a todo nuestro contenido. Por supuesto, si eres un individuo, tenemos planes mensuales y anuales para tener acceso a nuestro contenido. Y finalmente, si quieres un recurso gratuito que te ayudará a aprender Pinia rápidamente, ve y obtén la hoja de trucos gratuita de Pinia en la URL que aparece en tu pantalla. Aprecio mucho tu tiempo y atención, y espero verte en vuemastery.com.