Patrones para Aplicaciones Vue.js a Gran Escala

Hola a todos. Estoy realmente emocionado de estar con ustedes hoy y tener la oportunidad de compartir algunas cosas, algunos tips, y trucos que he aprendido durante mi tiempo como desarrollador. Mi nombre es Daniel Kelly, y soy un profesor en Vue School. En realidad, solo he estado en Vue School durante unos seis meses, pero desde que me uní al equipo, realmente he disfrutado de la oportunidad de poder contribuir a la comunidad de Vue que realmente me ha dado tanto a lo largo de mi carrera de desarrollo. Antes de unirme a Vue School, era un desarrollador full stack, y he trabajado con una serie de tecnologías a lo largo de los años, como PHP en Laravel y, por supuesto, JavaScript en Vue. Cuando no estoy programando, paso mi tiempo como esposo y padre, y para ser honesto, no sé con qué lucho más, con mis hijos o con mi código. Cuando tienes tres, hay mucho de eso que sucede.

De todos modos, eso es suficiente sobre mí. Vamos a lo que realmente vinieron a escuchar hoy. ¿Y eso es cuál es la mejor manera de estructurar una aplicación de Vue.js para que sea mantenible y escalable a medida que crece?

Bueno, si puedo ser tan audaz, voy a tratar de responder a esa pregunta frecuentemente formulada con una sola palabra. Y aquí está, previsibilidad. Cuando se trata de construir un proyecto escalable, quieres que todo sea lo más predecible posible. ¿Pero qué significa eso a nivel práctico? Bueno, para mí se trata de la capacidad de pasar de una solicitud de característica o un informe de error a la ubicación exacta o quizás a varias ubicaciones en el code donde se puede abordar dicha característica o informe de error. No solo eso, creo que es la capacidad de saber qué herramientas y qué data tienes acceso en esa ubicación en el code.

Ahora, ¿por qué es esto importante? ¿Por qué es importante que tengamos bases de code predecibles? Bueno, si eres algo como yo, definitivamente te has sentido así antes. Has abierto la base de code en tu editor, y te han asignado una tarea y piensas que no sé por dónde empezar. Estoy perdido. No tengo idea de lo que estoy haciendo y sí, creo que todos hemos estado allí. Tal vez es porque somos nuevos en el equipo. Tal vez es porque somos nuevos en un proyecto y tal vez eso es un poco más comprensible. Pero tal vez es incluso un proyecto en el que hemos estado trabajando durante bastante tiempo, y simplemente no sabemos por dónde empezar. Bueno, ese es el objetivo de una base de code predecible es aliviar esta experiencia tanto como sea humanamente posible y con ello se va a deshacer de muchos dolores de cabeza y va a eliminar mucha frustración y te devolverá mucho de tu tiempo.

Ahora rápido. Vamos a ver lo que no estoy diciendo. En primer lugar, no estoy diciendo que tu base de code pueda ser 100% predecible. No estoy diciendo que nunca tendrás que hacer ninguna excavación para encontrar lo que estás buscando, ¿verdad? Eso simplemente no es posible. También no estoy diciendo que tu base de code pueda ser entendida al 100% como un todo. De hecho, la mayoría de las aplicaciones o al menos muchas aplicaciones muy grandes son simplemente demasiado complejas para poder tener todo en tu cabeza a la vez. Y por lo tanto, una base de code predecible no es necesariamente sobre poder entender todo a la vez. Para mí, la previsibilidad es realmente más sobre poder predecir dónde encaja una cierta pieza en esa base de code y realmente ser capaz de enfocarse solo en esa pieza a la vez sin tener que pensar en el resto. De hecho, creo que eso es una medida de una muy buena base de code. Bueno. Entonces, ¿cómo logramos la previsibilidad? Esa es la pregunta. ¿No es así? Bueno, una vez más, si puedo ser tan audaz, voy a tratar de responderla con una sola palabra. Esa palabra es standards. ¿Por qué standards? Bueno, porque realmente, así es como haces cualquier cosa predecible, ¿verdad? Puedo saber con casi un 100% de certeza que cuando vaya a cambiar las sábanas de la cama de mi hijo esta noche, las sábanas que saco del armario encajarán porque hay un sistema de tamaño estándar y simplemente se hizo de esa manera con un estándar. Ahora puede que saque las sábanas del tamaño equivocado del armario para mi cama en lugar de la suya, pero hemos estado allí.

Pero eso depende de mí. Eso no es culpa de los standards. Bien. Una vez más, no estoy diciendo que los standards sean una bala de plata. No es algo que vaya a resolver todos tus problemas de desarrollo. Pero creo que es el mayor predictor de una base de code mantenible si sigues los standards.

Entonces, eso plantea la pregunta, ¿qué tipo de standards existen para la community de Vue en general? ¿Cuáles son esos standards que todos podemos compartir y conocer, ya sea que estemos trabajando solos, en un equipo pequeño o en cualquier lugar del mundo? Y en mi opinión, hay cuatro fuentes de standards en la community de Vue.js. La primera es la Guía de Estilo de Vue.js. Probablemente la más obvia, porque su propósito literal es proporcionar un conjunto de standards para todos nosotros. La siguiente es el andamiaje generado por Vue.cli. No voy a entrar en Vue.cli o Vite aquí porque realmente prefiero Vite, pero realmente estoy hablando de esa estructura de archivos a la que todos estamos acostumbrados a ver. Otra fuente son las bibliotecas oficiales de Vue.js. Y esas son todas las bibliotecas listadas en el sitio web oficial de la documentation de Vue bajo la sección de proyectos oficiales. Y por último, y sí, admito que quizás un poco más libremente, tenemos los marcos de componentes más populares. Cosas como Vue. Defy o Quasar o Bootstrap Vue. Bien. Entonces, primero que nada, profundicemos un poco más en esos dos últimos elementos. Es decir, las bibliotecas oficiales y de componentes. Admito que su propósito principal es la funcionalidad. Sin embargo, como efecto secundario de ser tan ampliamente utilizados, también proporcionan standards compartidos. ¿Qué quiero decir con eso? Bueno, toma VueRouter, por ejemplo. Si terminas usando VueRouter como tu solución de enrutamiento para tu proyecto de Vue.js, no estás optando solo por un paquete, realmente estás optando por una community de personas que usan exactamente el mismo paquete. Y por lo tanto, puedes interactuar con otros en todo el mundo que conocen y están familiarizados con ese paquete. Eso es parte de lo que estas bibliotecas oficiales y estas bibliotecas de componentes nos proporcionan es este conjunto de standards a seguir. VueX lo entiende al decir en su sitio web oficial que es un patrón de state management más una biblioteca. Entiende la importancia de tener un patrón, un estándar a seguir. Ahora, ¿cuál es mi punto al decir esto? Algunas de estas cosas pueden parecer un poco obvias, pero mi punto es que realmente deberías considerar usar la solución existente antes de intentar crear la tuya propia o ir con alguna otra solución. Si ya existe una solución que satisface tus necesidades, intenta usarla a menos que tengas una muy buena razón para no hacerlo, porque no solo esa solución viene con pruebas incorporadas, no solo viene con una excelente documentation, sino que también viene con standards, standards que personas más allá de tu equipo conocen, y eso hará que la incorporación de nuevas personas sea mucho más fácil.

Creo que esto se aplica a todas las bibliotecas de componentes también, solo que a un nivel un poco más suelto, pero la misma idea.

Bien, el siguiente estándar es la estructura proporcionada por el CLI de Vue, y realmente no tengo mucho que decir sobre esto, aparte de que es algo con lo que todos estamos familiarizados, así que no juguemos con ello, a menos que tengamos una muy buena razón para hacerlo.

Bien, si profundizamos ahora en el directorio de componentes y si miramos en la Guía de Estilo de Vue.js, verás que tenemos algunos estándares de componentes descritos para nosotros en la Guía de Estilo que realmente ayudarán mucho a hacer nuestro código más predecible.

Así que vamos a echar un vistazo a algunos de esos estándares hoy. El primero mencionado en la Guía de Estilo es que realmente deberíamos estar usando componentes de archivo único dedicados. Realmente no hay una buena razón, a menos que no estés usando una herramienta de construcción, para no poner todos tus componentes en un archivo de Vue dedicado.

Además, tus componentes de archivo único deben ser nombrados en Pascal case. Tus componentes base deben estar prefijados con app o base. Y esto simplemente los agrupa todos juntos en la estructura de archivos y proporciona ese estándar donde otras personas pueden mirar la app... o perdón, mirar el componente y decir, oh, eso es como un componente reutilizable en toda la app. Sé exactamente cuándo y dónde puedo usar eso. Y en realidad prefiero usar app todo el tiempo porque comienza con una A y normalmente va a agrupar todos esos y poner todos esos en la parte superior de mi directorio de componentes.

Bien, otra cosa en la guía de estilo de Vue.js es usar nombres de varias palabras para tus componentes. Y esto es realmente más que solo una cosa estilística. Esto es para evitar conflictos con futuros o existentes elementos HTML ya que por definición siempre son una sola palabra.

Otro estándar en la guía de estilo de Vue.js es prefijar todos tus componentes de instancia única con la palabra the. Es decir, componentes que solo se usarán una vez por página. Cosas como el encabezado o la barra lateral. Una vez más, esa previsibilidad hace que un nuevo desarrollador o alguien completamente nuevo en el proyecto sepa instantáneamente de qué tratan estos componentes.

También sugiere prefijar los componentes hijo estrechamente acoplados con el nombre del componente al que están acoplados. Por ejemplo, podrías tener una lista de tareas y luego elementos dentro de esa lista de tareas. Y entonces tendrías un componente de lista de tareas y un componente de elemento de lista de tareas. Del mismo modo, podrías tener un formulario de trabajo y luego un campo de mapa de ubicación especial en ese formulario. Y por lo tanto ese componente se llamaría campo de mapa de ubicación de formulario de trabajo.

Bien, a veces, sí, esto puede ser un poco largo, pero realmente los agrupa juntos y ayuda a las personas a saber que están acoplados y no pueden ser usados uno sin el otro. Y por último, comienza con el término más general dentro de tu componente y termina con el más específico. Esto simplemente agrupa las cosas una vez más. Y cuando los buscas en tus IDEs, en la búsqueda rápida o lo que sea, puedes ver todo agrupado en una sola búsqueda. Entonces, por ejemplo, tienes el widget de búsqueda, tienes el input del widget de búsqueda, y por último la lista de resultados del widget de búsqueda. Bien, la Guía de Estilo de Vue.js en realidad tiene muchas otras cosas realmente valiosas en ella.

Pero no voy a regurgitar todo eso aquí hoy. Pero realmente te animo a que lo revises. En realidad, pasó bastante tiempo desde que comencé a desarrollar con Vue antes de que me diera cuenta de que existía la Guía de Estilo de Vue.js. Y si la hubiera estado utilizando antes en mi carrera, antes en mi desarrollo con Vue, probablemente me habría ahorrado algunos dolores de cabeza y problemas al comunicarme y programar con mis compañeros de equipo sobre Vue.

Ahora, si quieres hacer que las recomendaciones de la guía de estilo sean un poco más accesibles para ti y un poco más en tiempo real, puedes usar el plugin oficial de ESLint que, por supuesto, combinado con los poderes de tu editor, marcará los errores para ti justo ahí en línea, mientras estás editando tus archivos. Y esto no solo incluirá errores de JavaScript en tus componentes de archivo único, sino que también te advertirá de algunas infracciones contra la Guía de Estilo de Vue.js. Así que realmente te animo a que lo revises y lo uses en tus proyectos para que puedas adherirte a estos estándares lo mejor que puedas, los mencionados en la guía de estilo.

Muy bien. Eso es todo para los estándares de la comunidad que tenemos disponibles. Pero creo que realmente estaría remiso si no recomendara algunos estándares personales o de equipo que he encontrado útiles. Creo que estos son absolutamente necesarios porque los estándares de la comunidad simplemente no son lo suficientemente completos para cubrir todas nuestras necesidades. Ahora, no estoy diciendo que sea culpa de la comunidad. Hay muchos estándares por ahí. Simplemente tenemos muchas aplicaciones diferentes, muchas formas diferentes de hacer las cosas. Y así es como va el mundo del desarrollo. Pero realmente creo que es esencial que para nuestro propio desarrollo personal o para nuestros equipos, elaboremos algunos estándares para nosotros mismos. Realmente va a hacer que tu proceso de desarrollo sea mucho más fluido.

Muy bien. Así que mi primera recomendación para tu estándar personal o de equipo es un directorio de componentes plano. Ahora, sé que algunos de ustedes pueden mirar esto y pensar que parece un poco loco, pero escúchame y no te desconectes todavía. Creo que hay una serie de beneficios diferentes que el directorio de componentes plano proporciona. El primero es que puedes navegar rápidamente desde las herramientas de desarrollo a la revisión del archivo del componente. Solo miras el nombre del componente en las herramientas de desarrollo y luego puedes ir directamente a él en tu estructura de archivos sin tener que navegar a través de diferentes directorios y buscar en diferentes directorios y todo eso. Simplemente están todos en ese directorio de componentes plano listados alfabéticamente para ti. También fomenta la navegación con la función de búsqueda rápida de tu IDE, porque navegar a través de esa larga lista se vuelve un poco más difícil. Realmente te hace y te obliga a intentar hacer la búsqueda. Y si estás nombrando tus componentes correctamente, como sugiere la guía de estilo, todo tu agrupamiento que normalmente se haría con carpetas de todos modos saldrá de la caja para ti. Y hay algunos otros beneficios que simplemente no tengo tiempo para repasar hoy, pero voy a compartir estas diapositivas en Twitter después de la charla. Así que si quieres mirar eso más, puedes hacerlo en ese momento.

Ahora, en realidad tengo una pequeña confesión que hacer, y es que nunca he usado la estructura de componentes plana en mis propios proyectos y en los proyectos que he realizado en el trabajo.

Pero quería compartirlo con ustedes porque he escuchado de algunas personas realmente inteligentes que esto realmente puede funcionar bien, incluso para aplicaciones de un tamaño muy grande. Pero como no es algo que haya utilizado personalmente yo mismo, no puedo recomendarlo al 100 por ciento y quiero mostrar la alternativa que sí he utilizado. Pero es muy similar y hoy lo llamaré una estructura de componentes casi plana. Y la razón por la que lo llamo una estructura de componentes casi plana es porque nuestro directorio de componentes en realidad sigue siendo plano. Mi única diferencia es que para los componentes que son específicos de la página, me gusta almacenarlos en un directorio parcial con mis componentes de página. Entonces, por ejemplo, como puedes ver en la captura de pantalla, hay un directorio de vistas y tengo una serie de diferentes páginas que tienen que ver con el recurso del cliente de mi aplicación. Y dentro de esa carpeta de clientes están mis páginas y un directorio llamado Partials. Ahora, lo que vive en partials aquí son componentes que van solo en esas páginas de clientes. No son páginas completas dentro de ellas mismas, pero son solo piezas de esas páginas de clientes. Y encuentro que esto funciona realmente bien como una especie de compromiso entre la estructura de componentes plana y el diseño impulsado por el dominio. Es una especie de término medio. Me ha resultado bastante bien.

Muy bien, el próximo el próximo estándar que quiero recomendar que utilices en tus proyectos personales o de tu equipo es una convención de nomenclatura de rutas estandarizada. De hecho, vimos eso en acción en la captura de pantalla que mostramos hace un minuto. Aquí vemos clientes crear, clientes editar, clientes indexar y clientes mostrar. Si estás familiarizado con Laravel, esto probablemente te resulte muy familiar porque es un estándar al que se adhieren. Y funciona muy bien para Laravel, así que ¿por qué no adoptarlo para la Vue community?

La mayoría de las aplicaciones, la mayoría de las aplicaciones CRUD tienen cuatro necesidades típicas para un recurso en particular. Por ejemplo, tendrías que tener una forma de listar todos ellos, una forma de crear uno de ellos, una forma de mostrar uno solo de ellos, y una forma de editar un solo uno de ellos. Y por supuesto, una forma de eliminarlos también. Pero eso normalmente no necesita una página completa. Y así verías cómo se vería un recurso llamado usuarios con esta convención de nomenclatura de rutas estandarizada para una aplicación CRUD. Y no voy a pasar por todos ellos porque simplemente no tenemos el tiempo para hacerlo, pero esto funciona muy bien y hace que tus rutas sean muy predecibles.

Muy bien, quiero ir un poco más allá de la previsibilidad y hablar sobre algunos otros consejos tips para aplicaciones a gran scale.

Mi primer consejo aquí es envolver tus bibliotecas de terceros en componentes. ¿Qué quiero decir con eso? Bueno, echemos un vistazo a este ejemplo. Digamos que estás usando Axios como tu cliente HTTP, y lo que te recomendaría es que realmente envuelvas Axios en una clase quizás con un nombre más genérico como HTTP, y luego simplemente uses Axios bajo el capó para hacer el trabajo pesado. Ahora, ¿por qué diablos haría esto, a menos que me paguen por línea? ¿Verdad? Parece que solo crea un poco de fricción adicional, un poco de trabajo extra. Pero hay algunos beneficios. El primero es que si por alguna razón alguna vez tienes que cambiar Axios por alguna otra solución HTTP, solo tienes que hacerlo en un solo lugar. Por ejemplo, en este caso, he cambiado Axios por Fetch. No tuve que recorrer toda mi base de código y cambiar las cosas, sino que solo tuve que apuntar a esa clase HTTP y el resto de la base de código continúa usando la clase HTTP como de costumbre. De hecho, las personas que están usando esa clase HTTP en el resto de la base de código, realmente no tienen que saber que la dependencia subyacente cambió. Simplemente siguen usando la misma interfaz para esa clase que han estado acostumbrados a usar. Otro beneficio para mí es que realmente expone formas de expandir la funcionalidad de tus clases de utilidad. Por ejemplo, aquí he incorporado una forma de alertar a un usuario o realizar algún tipo de acción cuando una solicitud HTTP falla en Fetch. Ahora, obviamente, alertar quizás no sea la mejor solución, no sea lo más amigable para el usuario, pero entiendes la idea. Ahora, por supuesto, con Axios, también hay ciertos ganchos en los que puedes engancharte para hacer cosas similares, pero para mí simplemente no son tan obvios. Y para algunas bibliotecas de terceros, esos ganchos simplemente pueden no existir. Y así, si los envuelves, la capacidad de extender y aumentar tus bibliotecas de terceros realmente se vuelve mucho más clara y un camino limpio de cómo hacerlo. Muy bien. Y este es solo un ejemplo más de cómo podrías hacer lo mismo extendiendo tu clase HTTP con algo de caché. Muy bien. Así que no solo puedes hacer eso con bibliotecas, aunque, cosas que son más funcionales por naturaleza, sino que puedes hacerlo incluso con componentes de terceros. Entonces, por ejemplo, podría crear un componente envolvente llamado icono de aplicación, y lo hemos llamado icono de aplicación porque de standards. Correcto. Y así, lo que hace este icono de aplicación es proporcionar una interfaz singular para trabajar con varios tipos de iconos de terceros, en este caso, Phone Awesome y Material Design icons.

Mi próximo paso para ustedes es interactuar con rest APIs, con SDKs, tal vez tu servicio ya proporciona un SDK, y si es así, entonces genial, úsalo. Pero si todo lo que proporciona es un punto final de API para golpear, te animo a que envuelvas esa API en un simple SDK propio. Y eso podría ser un SDK que termines usando solo para ese proyecto, o algo que incluso podrías compartir entre varios proyectos. Pero realmente te ayuda a eliminar la oportunidad de errores de tipeo y te da algo un poco más inteligente con lo que trabajar, algo como una clase con un método en ella que tu IDE puede autocompletar para ti. Además, si la API rest cambia en algún momento en el futuro, solo tienes que actualizar tu SDK y el resto de tu base de code puede permanecer intacta.

También, registra automáticamente los componentes base, necesitan estar disponibles a nivel global de todos modos, por lo que podrías seguir adelante y registrarlos automáticamente con un simple pedazo de code como este, y ni siquiera tienes que pensar en importarlos y registrarlos tú mismo.

Y finalmente, solo haz tus testing. Sé que hay muchas veces que simplemente no nos apetece hacerlo y no es lo más emocionante del mundo, pero para tus aplicaciones a gran scale, te prometo que es mejor hacer el trabajo por adelantado que tener que lidiar con los bugs y los problemas de regresión en el futuro. A nivel personal, sí, a veces las testing pueden ser frustrantes, pero nunca, nunca he lamentado hacer o crear una prueba. Ha habido muchas veces en las que he lamentado no crear una prueba.

Y también, solo para que lo sepan, la biblioteca recomendada ahora para testing tus componentes de Vue.js es la biblioteca Vue.testing, no Vue.testutils. Vue.testing library está construida sobre Vue.testutils, pero te da un poco más de abstracción para hacer la escritura de tu prueba mucho más fácil.

Muy bien, eso concluye mi charla sobre patterns para aplicaciones a gran scale de Vue.js. Pero tal vez estás en medio de escribir tu propia aplicación de Vue.js y podrías usar un poco de ayuda. Bueno, en Vue School, estaremos encantados de echarte una mano. Verás, ofrecemos una serie de servicios empresariales, incluyendo desarrollo, consultoría y formación de equipos en forma de videos educativos, así como masterclasses en vivo. Así que si estás interesado en alguno de estos servicios, ponte en contacto con nosotros en team at VueSchool.io y estaremos encantados de ayudarte.

Además, si quieres construir tu propia aplicación real de Vue.js, deberías echar un vistazo a la masterclass de Vue.js 3. Alex y yo enseñamos lo esencial, cosas como el Vue Router y los componentes de un solo archivo, pero también hacemos inmersiones más profundas en temas más complejos como la gestión de estado con Vuex, SEO, y más. Además, si te suscribes a nuestro servicio de suscripción, obtienes acceso a la masterclass de Vue.js 3 más acceso a una serie de otros grandes cursos que te enseñarán cómo ser un experto con Vue. Además, hay una serie de estos cursos que son gratuitos, así que realmente no tienes excusa para no ir y simplemente echarles un vistazo hoy. Muy bien, a todos, realmente disfruto estar aquí con ustedes y gracias por su tiempo.