Estructurando una Tienda Masiva de Vuex

Hola, Vue.js London. Estoy muy contento de hablar aquí hoy. Mi nombre es Doma Gawidowic. Siéntanse libres de llamarme Dom porque es mucho más fácil de pronunciar. Trabajo en Orbital Witness, una startup tecnológica genial de Londres, en algún lugar entre prop tech y legal tech, y también vivo en Londres.

Hoy hablaré sobre la estructuración de una gran tienda UX. Cómo crear una architecture escalable, flexible y mantenible. Actualmente, estamos utilizando esta architecture en Orbital Witness. No tenemos ningún problema con ella. Vamos a sumergirnos.

Comenzaré con un ejemplo de una tienda simple. La iré expandiendo en cada paso y les presentaré los desafíos que necesitamos resolver y, obviamente, resolverlos. Comenzaremos con la tienda más simple posible. Estamos utilizando create store de UX y estamos creando una tienda vacía con acciones, mutaciones y getters vacíos. No los explicaré, asumo que ya los conocen. Me enfocaré en cómo crear una tienda y hacerla escalable, adecuada para su uso en aplicaciones enormes.

Ahora agreguemos algunas propiedades aquí. Por lo general, en sus aplicaciones enormes, tendrán miles de propiedades diferentes. En este momento, solo dos son suficientes, nombre de usuario y nombre de organización, y obviamente algunas mutaciones para establecer ambos. ¿Qué pasaría si este archivo tuviera miles de propiedades? Pueden imaginarlo, simplemente agregando, agregando, agregando cosas aquí, y el archivo solo se volverá más y más grande. No queremos hacer eso. Si vamos a hacer eso, ¿por qué no mantenemos todo nuestro código en app.vue y olvidamos los componentes? Bromas aparte.

Veamos cómo podemos solucionar este problema. Para hacerlo, vamos a utilizar una característica nativa de UX llamada modules. Los modules nos permiten separar las preocupaciones, aislar diferentes partes de la tienda y crear mini tiendas dentro de nuestra gran tienda. Echen un vistazo al módulo de usuario, por ejemplo, aquí tomamos todo lo relacionado con el usuario, como el nombre y su mutación para establecer ese nombre. También estamos pasando acciones y getters como un objeto vacío porque no tenemos ninguno en este momento. Y lo que es realmente importante aquí es el atributo namespaced que se establece en true. El atributo namespaced nos permite registrar esas propiedades para esa mini tienda en un espacio de nombres local, en el espacio de nombres local de ese módulo.

De esta manera, podemos acceder a esas propiedades desde cualquier otro módulo, lo cual es bueno porque el espacio de nombres establecido en true nos impide acceder accidentalmente a algunas de las propiedades locales del modules. Podrías pensar que eso es una limitación, ¿verdad? Porque a veces realmente necesitas desencadenar algunos métodos de los diferentes modules, pero no puedes hacerlo ahora mismo. Bueno, puedes, pero necesitas tener la intención de hacerlo. Así que es posible, pero solo necesitas tener la intención. Pero esto es definitivamente bueno porque estamos evitando esos desencadenamientos accidentales. Puedes tener propiedades de estado iguales, con el mismo nombre o mutaciones, acciones, recolectores con el mismo nombre, el espacio de nombres establecido en true nos lo permite. Y su valor predeterminado es false.

De esta manera, todas las propiedades se registrarán en el espacio de nombres global. Tal vez quieras hacer eso, pero ten cuidado. El módulo de organización es literalmente lo mismo. Entonces tomamos todo lo relacionado con la organización, establecemos el espacio de nombres en true, y exportamos por defecto ese objeto. Si echamos un vistazo al archivo index.js, las cosas han cambiado un poco. Ahora tenemos el módulo de usuario y el módulo de organización. Necesitamos importarlos. Y luego necesitamos pasarlos al objeto modules. Estamos mapeando esos modules importantes a un nombre específico. Ahora mismo es usuario y organización. Esto es genial. Así que ya hemos separado nuestra tienda en diferentes modules. Están aislados. No podemos acceder a ellos por accidente, pero aún hay algo que necesitamos resolver.

Veamos, ¿cómo podemos usar estas mutaciones ahora mismo? Como desarrolladores, odiamos las cadenas codificadas. No son mantenibles. No son escalables. Si necesitas cambiar algo en tu proyecto, literalmente tienes que buscar en todo el código y reemplazarlo. Puedes hacer una búsqueda y reemplazo en todo el código y luego hacer un desastre. Es una receta para los errores. No uses cadenas codificadas. Ahora mismo, no tenemos otras opciones porque podemos desencadenar mutaciones de dos formas. La primera, accediendo directamente al objeto de la tienda y desencadenando, por ejemplo, la acción enviar mutaciones.

Desencadenarías los métodos commit y dispatch desde ese objeto de la tienda. Aún necesitas pasar cadenas codificadas allí. Pero definitivamente no recomiendo hacerlo de esa manera. Tenemos ayudantes de UX, map mutations, map getters, map actions y map state para eso.

¿Por qué es bueno? Bueno, imagina aplicaciones masivas con muchos, muchos, muchos componentes y archivos y una tienda masiva, masiva. Si estás accediendo a esa tienda, a esa tienda global que controla tu aplicación directamente, simplemente no es claro. Vas a tener miles y decenas de miles, o incluso más, referencias directamente a este objeto de this.store y todo será un desastre. Con map mutations y todos los demás ayudantes, literalmente ves, oh, este componente, mi componente aleatorio está utilizando estas partes de la tienda y está claro, lo tienes todo en un solo lugar.

Aún tienes que usar cadenas codificadas en este momento, pero lo resolveremos. Echa un vistazo a map mutations. Debido a que nuestros módulos están en espacios de nombres, necesitamos pasar el nombre del módulo como primer argumento. Es por eso que en el primer escenario, pasamos 'user', el segundo argumento es una matriz de mutaciones. Así que solo una cadena aquí, 'setUsername'. Resolvamos esto. Para hacerlo, necesitamos extraer las cadenas. Es bastante, bastante simple. Necesitas hacer tres cosas. Crea una constante, expórtala y luego establece ese valor constante como nombre de la mutación. Y eso es todo. Lo mismo para el modelo de organización, creando una constante, exportándola para que puedas importarla en otros archivos y estableciéndola como nombre de la mutación. Eso es todo para los módulos. Lo otro que necesitamos agregar es un objeto de módulo, que simplemente será una lista de todos los nombres de nuestros módulos. Luego necesitamos importar ese objeto a nuestro archivo index.js y simplemente usar los valores de ese objeto en lugar de las cadenas codificadas para 'user' y 'organization'. Bastante simple, ¿verdad? Veamos cómo mejoramos nuestro uso al hacer esto. Entonces, si echamos un vistazo a nuestro componente aleatorio, ahora obviamente necesitamos importar 'setUsername', 'setOrganizationName' y el objeto de módulo. Pero ahora en mapMutations, ya no estamos pasando cadenas codificadas. Estamos pasando el nombre del módulo y el segundo argumento, ya no estamos pasando una matriz, sino un objeto donde mapeamos un nombre de mutación a un nombre que queremos usar en nuestro componente. Así que ahora es 'setOrganizationName' y 'setUsername', puedes configurarlo de la forma que quieras. Depende completamente de ti. Bien.

Entonces, RSTAR se divide en modules en este momento. Tenemos esas mini tiendas. Su uso es muy claro. No solo tenemos mapMutations y posiblemente todos los demás ayudantes como mega-headers, mapactions, también necesitamos importar esos métodos para usarlos.

Inmediatamente cuando abres tu componente en la parte superior del archivo, veremos, está bien, aquí uso setUserName y aquí setOrganizationName. Y es muy claro. Oh, este componente utiliza estas partes de la tienda. Es realmente importante cuando tu aplicación escala que tengas esa imagen clara en lugar de acceder directamente al objeto de la tienda. Y debido a que el espacio de nombres está configurado como Verdadero, RSTAR también está aislado. No tenemos cadenas codificadas. Sí, lo mejor.

Pero todavía hay un problema que necesitamos resolver. Aunque nuestra aplicación ahora está dividida en modules, esos módulos pueden ser bastante grandes. Y necesitamos resolver eso y dividirlos aún más. Para hacerlo, primero debemos echar un vistazo a nuestra estructura de carpetas actual. En la parte superior tenemos la carpeta de la tienda raíz, luego dentro de ella tenemos index.js, modules.js, el módulo de organización.js y el módulo de usuario.js. Esto es genial para aplicaciones pequeñas y medianas, pero no es bueno para aplicaciones masivas. Por eso necesitamos refactorizar esta estructura.

Esta es nuestra estructura deseada. La tienda es la misma, por lo que la carpeta raíz está en la raíz, index.js y module.js dentro. Pero ahora hemos agregado otra carpeta llamada modules. Y dentro de esa carpeta, vamos a tener múltiples carpetas con los módulos separados. Ahora mismo tenemos organización y usuario. Dentro de la organización tenemos acciones, getters, index, mutations y types. Y dentro del usuario, tenemos las mismas cosas. Simplemente no quería expandirlo porque se vería mal. Veamos ahora los detalles de estos archivos. ¿Cómo podemos hacer eso? El título dice dividir los modules. Básicamente eso es lo que necesitamos hacer ahora. Necesitamos tomar ciertas partes de nuestros modules y simplemente crear archivos separados para ellos, exportarlos por defecto y listo.

Primero tenemos el archivo types.js. Recuerdas esas cadenas codificadas. Entonces, types.js, básicamente es una lista de todos los costos, acciones, mutaciones y getters. Todo lo que tenemos y usamos en este módulo. También sirve como una especie de documentación. Puedes ver aquí, oh, okay, este módulo está utilizando estos métodos. Es bastante razonable, bastante claro. No está sobrecargado con ninguna lógica, solo const aquí. Así que sí, esto es una especie de documentación agradable.

Luego tenemos las mutaciones. Obviamente necesitamos importar las constantes de types y asignar los nombres de las mutaciones a esos valores constantes. Por lo general, aquí tendrás múltiples mutaciones. En este momento solo tenemos una única y luego necesitas exportar por defecto ese objeto. Con las acciones, actualmente no tenemos ninguna acción. Es por eso que estamos exportando por defecto un objeto vacío. Eso es posible que suceda para algunos nuevos módulos. Recomiendo encarecidamente exportar por defecto un objeto vacío en lugar de no tener nada aquí o no tener un archivo en absoluto, solo para mantener la consistencia. Y luego, cuando agregues algo adentro, ya tendrás esa plantilla para ello. Todo con las acciones es lo mismo que con las mutaciones, lo mismo ocurre con los getters. Ahora mismo, solo estamos exportando un objeto vacío pero el proceso es el mismo que con las mutaciones y acciones.

Finalmente, tenemos nuestro index.js. No es el index.js en la carpeta de la tienda raíz. Es el index.js dentro de la carpeta de organización, dentro de nuestro módulo. Aquí, necesitamos importar las acciones, mutaciones y getters. Luego, necesitamos crear un objeto de estado. Puedes pensar, oh, tal vez podamos crear un archivo separado para el estado e importarlo también. Y eso es cierto. Puedes hacerlo. No es necesario hacerlo. No lo hacemos porque el objeto de estado no tiene ninguna lógica conectada a él.

Nos encanta que cada vez que abrimos un archivo index.js podamos ver todo ahí. Es justo lo que hacemos. Puedes crear un archivo separado para eso. No es necesario, depende completamente de ti.

Definitivamente recomiendo crear archivos separados para acciones, getters y mutaciones porque hay mucha lógica detrás de esos métodos. Confiamos en esa lógica, ¿verdad? Y por eso no queremos verla. Solo queremos importarla y tener una visión clara del estado.

Finalmente, necesitamos exportar default.object estableciendo, por supuesto, namespace en true, pasando state, mutations, actions y getters. El proceso es el mismo para todos los modules. Así que no repetiré lo mismo para el módulo de usuario en este momento, porque es literalmente lo mismo.

Lo que necesitamos hacer ahora es actualizar nuestra tienda raíz. Para hacerlo, necesitamos importar el módulo de usuario, importar el módulo de organización, e importar nuestro objeto de módulo con todos los nombres. Luego, vamos a declarar el estado global, las acciones globales, las mutaciones globales y los getters globales. Ten cuidado con ellos porque son accesibles en el espacio de nombres global. Ese es el lugar donde se registrarán. En este momento, están vacíos, pero el proceso es el mismo que con los que tienen espacio de nombres, el proceso para crearlos.

Luego, necesitamos crear la carpeta de modules. Vamos a mapear el módulo de usuario a username y el módulo de organización a organization name que obtenemos de la constante del módulo. Finalmente, necesitamos usar create store de Vuex. Necesitamos exportar el objeto let por defecto con state, actions, mutations, getters, los globales y modules. Y eso es todo. Ahora lo tenemos. Tenemos esa arquitectura limpia, escalable y flexible de la tienda para tu aplicación masiva.

Echemos un vistazo. En la parte superior, tenemos el archivo index.js, nuestra tienda raíz. Esa tienda raíz tiene su propio estado global, acciones, mutaciones y getters. Pero a partir de la segunda capa, esa tienda raíz importa todos los diferentes modules que tienes. En este momento, solo tenemos organización y usuario, pero vas a tener muchos más, créeme. Y luego, todos esos diferentes tipos de modules desde la segunda capa, importan sus propias acciones aisladas, getters, mutaciones, estado desde la tercera capa. En este momento en Orbital Witness, no tenemos ningún problema con esta arquitectura.

Estas tres capas son suficientes, pero si eres un jugador experto, puedes crear una cuarta capa. Así puedes dividir, por ejemplo, tus mutaciones en diferentes grupos. Puedes separarlos por preocupaciones y obviamente es importante tener un archivo de índice y luego importarlo a la tercera capa. Y eso es algo para aplicaciones masivas, masivas. Diría que no lo necesitamos en este momento. Podríamos hacerlo, pero no lo estamos haciendo en este momento.

Si tienes algo como una aplicación masiva, masiva, masiva, entonces puedes crear una quinta capa. Y este proceso, puedes profundizar tanto como quieras. Puedes tener tantas capas como desees. Esta architecture es compatible con aplicaciones masivas, las aplicaciones más masivas que puedas imaginar. Y eso es todo lo que quería decir aquí.

Gracias a todos por su atención. Fue un placer hablar aquí. No duden en hacer preguntas. Si no tienen nada en mente en este momento, pueden encontrar mi información en el sitio web de la conferencia en la sección de oradores. Allí encontrarán mi correo electrónico. Podemos conectarnos en Twitter. También echen un vistazo a mi perfil de GitHub porque el código está disponible públicamente allí. Así pueden usarlo como plantilla para su nueva aplicación. O si desean refactorizar su tienda actual, pueden echar un vistazo a estas prácticas. No es necesario refactorizar toda la tienda de una vez. Así que tómense su tiempo, días, semanas, meses, lo que necesiten. Y sí, pueden hacerlo parcialmente. Eso es todo por mi parte. ¡Muchas gracias! ¡Vue.js London!