Patrones para Aplicaciones Vue.js a Gran Escala

Rate this content
Bookmark

¿Cuál es la mejor manera de estructurar una aplicación Vue.js para que pueda escalar y satisfacer todas las necesidades de tus usuarios? Hay múltiples patrones establecidos en la comunidad Vue y en la comunidad de programación en general que se pueden adoptar para hacer que tus bases de código sean más predecibles, mantenibles y extensibles.

25 min
21 Oct, 2021

Video Summary and Transcription

Los estándares son cruciales para lograr previsibilidad y mantenibilidad en una base de código. La comunidad de Vue.js proporciona varias fuentes de estándares, incluyendo la Guía de Estilo de Vue.js y las bibliotecas oficiales. Los estándares personales y a nivel de equipo pueden complementar los de la comunidad. Estructuras alternativas de componentes, como una estructura casi plana, pueden funcionar bien para aplicaciones grandes. Adoptar una convención de nomenclatura estandarizada para las rutas puede hacer que las rutas sean más predecibles. Algunos consejos adicionales incluyen envolver bibliotecas de terceros, crear SDKs para APIs y registrar componentes globalmente. Es importante realizar pruebas exhaustivas, y Vue School ofrece varios servicios y cursos para convertirse en un experto en Vue.js.

Available in English

1. Introducción

Short description:

Hola a todos. Soy Daniel Kelly, un profesor de Vue School. He trabajado como desarrollador full stack con tecnologías como PHP en Laravel y JavaScript en Vue. Estoy emocionado de compartir algunos consejos y trucos con ustedes hoy.

Hola a todos. Estoy realmente emocionado de estar aquí hoy y compartir algunas cosas, algunos tips y trucos que he aprendido durante mi tiempo como desarrollador. Mi nombre es Daniel Kelly y soy profesor en Vue School. En realidad, solo he estado en Vue School durante unos seis meses, pero desde que me uní al equipo, he disfrutado mucho la oportunidad de contribuir a la comunidad de Vue que me ha dado tanto a lo largo de mi carrera como desarrollador. Antes de unirme a Vue School, fui desarrollador full stack y he trabajado con varias 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é luchar más, si con mis hijos o con mi código. Cuando tienes tres, hay mucho de eso.

2. Achieving Predictability with Standards

Short description:

Cuando se trata de construir un proyecto escalable, la predictibilidad es clave. Quieres poder localizar y abordar fácilmente las solicitudes de funciones o informes de errores en el código. La predictibilidad también significa saber qué herramientas y datos están disponibles en cada ubicación. Tener una base de código predecible es importante porque elimina la confusión y ahorra tiempo. Si bien una base de código no puede ser completamente predecible o comprendida en su totalidad, la predictibilidad se trata de poder centrarse en una pieza a la vez. Los estándares son la clave para lograr la predictibilidad en una base de código.

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

Bueno, si me permites ser audaz, voy a intentar responder esa pregunta que se hace con frecuencia con una sola palabra. Y aquí está, predictibilidad. Cuando se trata de construir un proyecto escalable, quieres que todo en él sea lo más predecible posible. ¿Qué significa eso en un nivel práctico? Bueno, para mí se trata de la capacidad de ir desde una solicitud de función o un informe de error hasta la ubicación exacta o tal vez varias ubicaciones en el código donde se puede abordar dicha función 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 del código.

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

Ahora, rápidamente. Veamos lo que no estoy diciendo. En primer lugar, no estoy diciendo que tu base de código pueda ser cien por ciento predecible. No estoy diciendo que nunca tendrás que buscar un poco para encontrar lo que estás buscando, ¿verdad? Eso simplemente no es posible. Tampoco estoy diciendo que tu base de código pueda ser cien por ciento comprendida en su totalidad. 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 al mismo tiempo. Y por lo tanto, que una base de código sea predecible no se trata necesariamente de poder entender todo al mismo tiempo. Para mí, la predictibilidad se trata más bien de poder predecir dónde encaja una determinada pieza en esa base de código y realmente poder 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 base de código realmente buena. Bien. Entonces, ¿cómo logramos la predictibilidad? Esa es la pregunta. ¿No es así? Bueno, una vez más, si me permites ser audaz, voy a intentar responderlo con una sola palabra. Esa palabra es standards. ¿Por qué standards? Bueno, porque realmente así es como haces que cualquier cosa sea predecible, ¿verdad? Puedo saber con un 100 por ciento de seguridad que cuando vaya a cambiar las sábanas de la cama de mi hijo esta noche, las sábanas que saque del armario encajarán porque hay un sistema de tamaños estándar y simplemente se hace así con un estándar. Ahora, puede que saque las sábanas del tamaño incorrecto del armario para mi cama en lugar de la de él, pero hemos estado ahí.

3. Estándares de la Comunidad Vue.js

Short description:

Los estándares son el mayor predictor de una base de código mantenible. Hay cuatro fuentes de estándares en la comunidad Vue.js: la Guía de Estilo de Vue.js, el andamiaje generado por Vue.cli, las bibliotecas oficiales de Vue.js y los marcos de componentes populares. Estas fuentes proporcionan estándares compartidos, lo que facilita la interacción con otros y la integración de nuevos miembros del equipo. Considera utilizar soluciones existentes antes de crear las tuyas propias, ya que vienen con pruebas integradas, una excelente documentación y estándares establecidos.

Pero eso es culpa mía. Eso no es culpa de los estándares. Muy bien. Ahora, una vez más, no estoy diciendo que los estándares sean una solución mágica. No es algo que vaya a resolver todos tus problemas de desarrollo. Pero creo que es el mayor predictor de una base de código mantenible si sigues los estándares.

Entonces surge la pregunta, ¿qué tipo de estándares existen para la comunidad de Vue en general? ¿Cuáles son esos estándares que todos podemos compartir y conocer, ya sea que estemos trabajando, ya sabes, solos, en un equipo pequeño o en cualquier parte del mundo? Y en mi opinión, hay cuatro fuentes de estándares en la comunidad de Vue.js. La primera es la Guía de Estilo de Vue.js. Y probablemente la más obvia, porque su propósito literal es proporcionar un conjunto de estándares para todos nosotros. La siguiente es el andamiaje generado por Vue.cli. Ahora no voy a entrar en detalles sobre Vue.cli o Vite aquí porque realmente prefiero Vite, pero estoy hablando principalmente de la estructura de archivos que todos estamos acostumbrados a ver. Otra fuente son las bibliotecas oficiales de Vue.js. Y esas son todas las bibliotecas enumeradas en el sitio web oficial de documentación de Vue en la sección de proyectos oficiales. Y por último, y sí, admito que de manera un poco más flexible, tenemos los marcos de componentes más populares. Cosas como Vue. Defy o Quasar o Bootstrap Vue. Muy bien. Entonces, primero, profundicemos un poco más en los dos últimos elementos. Es decir, las bibliotecas oficiales de componentes. Admitidamente, su propósito principal es la funcionalidad. Sin embargo, como efecto secundario de ser tan ampliamente utilizadas, también proporcionan estándares compartidos. ¿Qué quiero decir con eso? Bueno, toma VueRouter, por ejemplo. Si terminas usando VueRouter como solución de enrutamiento para tu proyecto de Vue.js, no solo estás optando por un paquete, realmente te estás uniendo a una comunidad de personas que utilizan el mismo paquete exacto. Y, por lo tanto, puedes interactuar con otros en todo el mundo que conocen y están familiarizados con ese paquete. Entonces, eso es parte de lo que estas bibliotecas oficiales y estas bibliotecas de componentes nos proporcionan es este conjunto de estándares a seguir. VueX lo abraza al decir en su sitio web oficial que es un patrón y una biblioteca de gestión de estado. 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 obvias, pero mi punto es que realmente deberías considerar utilizar la solución existente antes de intentar crear la tuya propia o usar otra solución. Si ya hay una solución disponible para satisfacer tus necesidades, intenta usarla a menos que tengas una muy buena razón para no hacerlo, porque esa solución no solo viene con pruebas integradas, no solo viene con una excelente documentación, sino que también viene con estándares, estándares que las personas fuera de tu equipo conocen, y eso facilitará la integración de nuevos miembros del equipo.

4. Estándares de Componentes en Vue.js

Short description:

Ahora esto también se aplica a todas las bibliotecas de componentes. La estructura proporcionada por el Vue CLI es un estándar familiar con el que no deberíamos meter mano, a menos que haya una buena razón. La Guía de Estilo de Vue.js proporciona estándares para los componentes que hacen que el código sea más predecible. Algunos de estos estándares incluyen el uso de componentes de archivo único dedicados, nombrar los componentes en Pascal case y agregar el prefijo app o base a los componentes base. También sugiere el uso de nombres con varias palabras para evitar conflictos con los elementos HTML, agregar el prefijo the a los componentes de instancia única y agregar el nombre del componente acoplado a los componentes secundarios acoplados. Por último, los componentes deben comenzar con el término más general y terminar con el más específico para facilitar el agrupamiento en los IDE.

Ahora esto también se aplica, creo, a todas las bibliotecas de componentes, pero en un nivel un poco más flexible, pero con la misma idea.

Muy bien, el siguiente estándar es la estructura proporcionada por el Vue CLI, y realmente no tengo mucho que decir al respecto, aparte de que es algo con lo que todos estamos familiarizados, así que no lo modifiquemos a menos que tengamos una muy buena razón.

Muy bien, si ahora profundizamos en el directorio de componentes y si consultamos la Guía de Estilo de Vue.js, veremos que tenemos algunos estándares de componentes que se describen en la Guía de Estilo y que realmente ayudarán a que nuestro código sea más predecible.

Veamos algunos de esos estándares hoy. El primero mencionado en la Guía de Estilo es que realmente deberíamos usar componentes de archivo único dedicados. No hay realmente ninguna buena razón, a menos que no estés utilizando una herramienta de compilación, para no colocar todos tus componentes en un archivo dedicado de Vue.

También, tus componentes de archivo único deben tener nombres en Pascal case. Tus componentes base deben tener el prefijo app o base. Esto los agrupa en la estructura de archivos y proporciona un estándar donde otras personas pueden ver el componente y decir: `Oh, ese es un componente reutilizable en toda la aplicación. Sé exactamente cuándo y dónde puedo usarlo`. De hecho, prefiero usar app todo el tiempo porque comienza con una A y normalmente agrupo todos esos y los coloco en la parte superior de mi directorio de componentes.

Otra cosa en la Guía de Estilo de Vue.js es usar nombres con varias palabras para tus componentes. Esto va más allá de ser solo una cuestión de estilo. Es para evitar conflictos con elementos HTML futuros o existentes, ya que por definición siempre son una sola palabra.

Otro estándar en la Guía de Estilo de Vue.js es agregar el prefijo the a todos tus componentes de instancia única. Es decir, componentes que solo se utilizará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 nuevo en el proyecto sepa instantáneamente de qué se tratan estos componentes.

También sugiere agregar el nombre del componente acoplado a los componentes secundarios acoplados. Por ejemplo, podrías tener una lista de tareas y luego elementos dentro de esa lista de tareas. 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 empleo y luego un campo de mapa de ubicación especial en ese formulario. Por lo tanto, ese componente se llamaría campo de mapa de ubicación del formulario de empleo.

A veces, sí, esto puede volverse un poco largo, pero realmente los agrupa y ayuda a las personas a saber que están acoplados y que no se pueden usar 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 agrupa las cosas una vez más. Y cuando los buscas en tus IDE, búsqueda rápida o lo que sea, puedes ver todo agrupado en una sola búsqueda. Por ejemplo, tienes el widget de búsqueda, tienes el widget de entrada de búsqueda y, por último, la lista de resultados del widget de búsqueda. Muy bien, la Guía de Estilo de Vue.js tiene muchas otras cosas realmente valiosas en ella.

5. Estándares Personales y de Equipo

Short description:

Te animo a que consultes la Guía de Estilo de Vue.js y utilices el complemento oficial de ESLint para recomendaciones en tiempo real. Además, recomiendo establecer estándares personales o de equipo para complementar los estándares de la comunidad. Una recomendación es tener un directorio de componentes plano, que ofrece beneficios como una navegación rápida y una mejor capacidad de búsqueda. Aunque personalmente no he utilizado esta estructura, creo que puede mejorar en gran medida el proceso de desarrollo.

Pero no los repetiré todos aquí hoy. Pero realmente te animo a que lo consultes. En realidad, fue bastante tarde en mi tiempo desarrollando con Vue antes de darme cuenta de que existía la Guía de Estilo de Vue.js. Y si lo hubiera utilizado antes en mi carrera, antes en mi desarrollo con Vue, probablemente me habría ahorrado algunos dolores de cabeza y problemas al comunicarme y codificar con mis compañeros de equipo sobre Vue.

Ahora, si quieres hacer que las recomendaciones de la guía de estilo estén más disponibles y sean en tiempo real, puedes utilizar el complemento oficial de ESLint que, por supuesto, combinado con las capacidades de tu editor, marcará los errores en línea, mientras editas tus archivos. Y no solo incluirá errores de JavaScript en tus componentes de archivo único, sino que también te advertirá sobre algunas infracciones a la guía de estilo de Vue.js. Así que realmente te animo a que lo consultes y lo uses en tus proyectos para que puedas adherirte a estos estándares 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 sería un error no recomendar algunos estándares personales o de equipo que he encontrado útiles. Creo que son absolutamente necesarios porque los estándares de la comunidad simplemente no son lo suficientemente completos para cubrir todas nuestras necesidades. 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 funciona el mundo del desarrollo. Pero realmente creo que es esencial que para nuestro propio desarrollo personal o para nuestros equipos, establezcamos algunos estándares para nosotros mismos. Realmente hará que tu proceso de desarrollo sea mucho más fluido.

Muy bien. Mi primera recomendación para tu estándar personal o de equipo es tener un directorio de componentes plano. Sé que algunos de ustedes pueden ver esto y pensar que puede parecer un poco loco, pero escúchenme y no se desconecten todavía. Creo que hay varios beneficios que proporciona el directorio de componentes plano. El primero es que puedes navegar rápidamente desde las herramientas de desarrollo hasta el archivo del componente. Solo tienes que mirar 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 por diferentes directorios y buscar en diferentes directorios y todo eso. Todos están 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 tus ideas, porque navegar por esa larga lista se vuelve un poco más difícil. Realmente te obliga a intentar hacer la búsqueda. Y si nombras tus componentes correctamente, como sugiere la guía de estilo, todo el agrupamiento que normalmente se haría con carpetas se hará automáticamente para ti. Y hay algunos otros beneficios que simplemente no tengo tiempo de explicar hoy, pero voy a compartir estas diapositivas en Twitter después de la charla. Así que si quieres ver más, puedes hacerlo en ese momento.

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

6. Estructura Alternativa: Casi Plana de Componentes

Short description:

He escuchado de personas inteligentes que una estructura de componentes casi plana puede funcionar bien para aplicaciones grandes. Aunque no la he utilizado personalmente, te mostraré una alternativa que sí he utilizado. Es un compromiso entre la estructura de componentes plana y el diseño impulsado por dominios, donde los componentes específicos de la página se almacenan en un directorio parcial. Este enfoque me ha funcionado muy bien.

Pero quería compartirlo con ustedes porque he escuchado, basado en personas realmente inteligentes, que esto realmente puede funcionar bien, incluso para aplicaciones de gran tamaño. Pero como no es algo que haya utilizado personalmente, no puedo recomendarlo al 100 por ciento y quiero mostrarte 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 llamaré una estructura de componentes casi plana es porque nuestro directorio de componentes sigue siendo plano. La única diferencia es que para los componentes que son específicos de una página, me gusta almacenarlos en un directorio parcial junto con mis componentes de página. Por ejemplo, como puedes ver en la captura de pantalla, hay un directorio llamado 'views' y tengo varias páginas que tienen que ver con los recursos 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 se encuentra en 'partials' son componentes que solo se utilizan en esas páginas de clientes. No son páginas completas en sí mismas, sino que son solo piezas de esas páginas de clientes. Y encuentro que esto funciona muy bien como una especie de compromiso entre la estructura de componentes plana y el diseño impulsado por dominios. Es algo intermedio. Me ha funcionado muy bien.

7. Convención de Nomenclatura de Rutas Estandarizadas

Short description:

El siguiente estándar que recomiendo es una convención de nomenclatura de rutas estandarizada. Funciona muy bien para Laravel y puede ser adoptado por la comunidad de Vue. La mayoría de las aplicaciones CRUD tienen cuatro necesidades típicas para un recurso: listar, crear, mostrar y editar. Al seguir esta convención de nomenclatura, tus rutas se vuelven predecibles.

Muy bien, el siguiente el siguiente estándar que quiero recomendar que utilices en tus proyectos personales o en los proyectos de tu equipo es una convención de nomenclatura de rutas estandarizada. De hecho, lo vimos en acción en la captura de pantalla que mostramos hace un minuto. Aquí vemos crear clientes, editar clientes, índice de clientes y mostrar clientes. 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 community de Vue?

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 uno solo de ellos. Y, por supuesto, también una forma de eliminarlos. Pero eso normalmente no requiere una página completa. Y así es como 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 no tenemos tiempo, pero esto realmente funciona bien y hace que tus rutas sean muy predecibles.

8. Consejos Variados para Aplicaciones a Gran Escala

Short description:

Envuelve tus bibliotecas de terceros en componentes para cambiar fácilmente las dependencias y ampliar la funcionalidad. Extiende tu clase HTTP con almacenamiento en caché o crea componentes envolventes para iconos de terceros. Envuelve las APIs REST en un SDK sencillo para eliminar errores tipográficos y proporcionar autocompletado. Registra automáticamente los componentes base de forma global para simplificar la importación y el registro.

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

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 hacer es envolver Axios en una clase con un nombre más genérico, como HTTP, y luego usar Axios bajo el capó para hacer el trabajo real. Ahora, ¿por qué demonios haría esto, a menos que me paguen por línea de código? ¿Verdad? Parece que solo crea un poco de fricción y trabajo adicional. Pero hay algunos beneficios. El primero es que si por alguna razón tienes que cambiar Axios por alguna otra solución HTTP, solo tienes que hacerlo en un solo lugar. Por ejemplo, en este ejemplo, he cambiado Axios por Fetch. No tuve que recorrer todo mi código y cambiar cosas, sino que solo tuve que apuntar a esa clase HTTP y el resto del código continúa usando la clase HTTP como de costumbre. De hecho, las personas que usan esa clase HTTP en el resto del código, realmente no tienen que saber que la dependencia subyacente ha cambiado. Siguen usando la misma interfaz para esa clase a la que están acostumbrados. 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 alguna acción cuando una solicitud HTTP falla desde Fetch. Ahora, obviamente, alertar puede que no sea la mejor solución, no es lo más amigable para el usuario, pero entiendes la idea. Ahora, por supuesto, con Axios, también hay ciertos hooks a los que puedes engancharte para hacer cosas similares, pero para mí simplemente no son tan obvios. Y para algunas bibliotecas de terceros, esos hooks simplemente pueden no existir. Y así, si los envuelves, la capacidad de extender y mejorar tus bibliotecas de terceros se vuelve mucho más clara y es un camino claro para hacerlo. Muy bien. Y este es solo otro ejemplo de cómo podrías hacer lo mismo al extender tu clase HTTP con almacenamiento en caché. Muy bien. Pero no solo puedes hacer eso con bibliotecas, cosas que son más funcionales en la naturaleza, sino que también puedes hacerlo con componentes de terceros. Por ejemplo, podría crear un componente envolvente llamado icono de la aplicación, y lo hemos llamado icono de la aplicación debido a los estándares. ¿Verdad? Y lo que hace este icono de la aplicación es proporcionar una interfaz única para trabajar con varios tipos de iconos de terceros, en este caso, Phone Awesome y Material Design icons.

Mi siguiente consejo para ustedes es interactuar con las APIs REST, con SDKs, tal vez su servicio ya proporciona un SDK, y si es así, genial, úsenlo. Pero si solo proporciona un punto de conexión de API para acceder, te animo a envolver esa API en un SDK sencillo propio. Y ese 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 tipográficos y te brinda algo un poco más inteligente con lo que trabajar, algo como una clase con un método en la 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 código puede permanecer intacto.

9. Auto Registering Components and Testing

Short description:

Registra automáticamente los componentes base de forma global y no olvides hacer pruebas exhaustivas. La biblioteca recomendada para probar los componentes de Vue.js es Vue.testing library. En conclusión, Vue School ofrece varios servicios empresariales, incluyendo desarrollo, consultoría y capacitación de equipos. También ofrecen la masterclass de Vue.js 3 y otros cursos para ayudarte a convertirte en un experto en Vue.

Además, registra automáticamente los componentes base, ya que de todos modos deben estar disponibles globalmente, así que puedes registrarlos automáticamente con un código simple como este, y ni siquiera tienes que preocuparte por importarlos y registrarlos tú mismo.

Y por último, simplemente haz tus pruebas. Sé que muchas veces no nos apetece hacerlo y no es la tarea más emocionante del mundo, pero para tus aplicaciones a gran escala, te prometo que es mejor hacer el trabajo desde el principio que lidiar con los errores y los problemas de regresión más adelante. A nivel personal, sí, a veces las pruebas pueden ser frustrantes, pero nunca, nunca me he arrepentido de hacer o crear una prueba. Ha habido muchas veces en las que me he arrepentido de no crear una prueba.

Y también, solo para que lo sepan, la biblioteca recomendada ahora para probar tus componentes de Vue.js es la biblioteca Vue.testing, no Vue.testutils. La biblioteca Vue.testing en realidad se basa en Vue.testutils, pero te proporciona una abstracción un poco más alta para facilitar la escritura de tus pruebas.

Muy bien, eso concluye mi charla sobre patrones para aplicaciones de Vue.js a gran escala. Pero tal vez estés en medio de escribir tu propia aplicación de Vue.js y podrías necesitar un poco de ayuda. Bueno, en Vue School, estaremos encantados de echarte una mano. Ofrecemos varios servicios empresariales, incluyendo desarrollo, consultoría y capacitación de equipos en forma de videos educativos, así como masterclasses en vivo. Así que si estás interesado en alguno de estos servicios, contáctanos en team@VueSchool.io y estaremos encantados de ayudarte.

Además, si quieres construir tu propia aplicación de Vue.js del mundo real, deberías echar un vistazo a la masterclass de Vue.js 3. Alex y yo enseñamos los conceptos esenciales, como Vue Router y componentes de archivo único, pero también profundizamos en temas más complejos como la gestión del estado con Vuex, SEO y más. Además, si te suscribes a nuestro servicio, tendrás acceso a la masterclass de Vue.js 3 y a otros cursos geniales que te enseñarán cómo ser un experto en Vue.js. Además, hay varios cursos gratuitos, así que realmente no tienes excusa para no ir y echarles un vistazo hoy mismo. Muy bien, a todos ustedes, realmente disfruté estar aquí con ustedes y gracias por su tiempo.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Top Content
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Top Content
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.

Workshops on related topic

Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Top Content
Workshop
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.
Vue.js London 2023Vue.js London 2023
137 min
TresJS create 3D experiences declaratively with Vue Components
Workshop
- Intro 3D - Intro WebGL- ThreeJS- Why TresJS- Installation or Stackblitz setup - Core Basics- Setting up the Canvas- Scene- Camera- Adding an object- Geometries- Arguments- Props- Slots- The Loop- UseRenderLoop composable- Before and After rendering callbacks- Basic Animations- Materials- Basic Material- Normal Material- Toon Material- Lambert Material- Standard and Physical Material- Metalness, roughness - Lights- AmbientLight- DirectionalLight- PointLights- Shadows- Textures- Loading textures with useTextures- Tips and tricks- Misc- Orbit Controls- Loading models with Cientos- Debugging your scene- Performance
Vue.js London Live 2021Vue.js London Live 2021
176 min
Building Vue forms with VeeValidate
Workshop
In this workshop, you will learn how to use vee-validate to handle form validation, manage form values and handle submissions effectively. We will start from the basics with a simple login form all the way to using the composition API and building repeatable and multistep forms.

Table of contents:
- Introduction to vee-validate
- Building a basic form with vee-validate components
- Handling validation and form submissions
- Building validatable input components with the composition API
- Field Arrays and repeatable inputs
- Building a multistep form
Prerequisites:
VSCode setup and an empty Vite + Vue project.
Vue.js London Live 2021Vue.js London Live 2021
116 min
Building full-stack GraphQL applications with Hasura and Vue 3
Workshop
The frontend ecosystem moves at a breakneck pace. This workshop is intended to equip participants with an understanding of the state of the Vue 3 + GraphQL ecosystem, exploring that ecosystem – hands on, and through the lens of full-stack application development.

Table of contents
- Participants will use Hasura to build out a realtime GraphQL API backed Postgres. Together we'll walk through consuming it from a frontend and making the front-end reactive, subscribed to data changes.
- Additionally, we will look at commonly-used tools in the Vue GraphQL stack (such as Apollo Client and Urql), discuss some lesser-known alternatives, and touch on problems frequently encountered when starting out.
- Multiple patterns for managing stateful data and their tradeoffs will be outlined during the workshop, and a basic implementation for each pattern discussed will be shown.
Workshop level

NOTE: No prior experience with GraphQL is necessary, but may be helpful to aid understanding. The fundamentals will be covered.
Vue.js London Live 2021Vue.js London Live 2021
72 min
A Different Vue into Web Performance
Workshop
Solving your front-end performance problems can be hard, but identifying where you have performance problems in the first place can be even harder. In this workshop, Abhijeet Prasad, software engineer at Sentry.io, dives deep into UX research, browser performance APIs, and developer tools to help show you the reasons why your Vue applications may be slow. He'll help answer questions like, "What does it mean to have a fast website?" and "How do I know if my performance problem is really a problem?". By walking through different example apps, you'll be able to learn how to use and leverage core web vitals, navigation-timing APIs, and distributed tracing to better understand your performance problems.