Patrones para Aplicaciones Vue.js a Gran Escala

¡Hola! Mi nombre es Daniel Kelly, y soy el instructor principal en la escuela. Estoy muy emocionado de estar con todos ustedes aquí hoy. He sido un desarrollador full-stack durante los últimos 10 años, trabajé con tecnologías como Wearable en el back end, y por supuesto, Vue.js en el front end. Pero eso es suficiente sobre mí. Solo quería informarte rápidamente con quién estás tratando, pero ahora pasemos al tema de hoy, ¿de acuerdo?

Y eso es mirar algunos patrones para el desarrollo de aplicaciones Vue.js a gran escala, ¿verdad? Entonces, nuestro objetivo durante esta sesión es responder a esta pregunta, ¿cuál es la mejor manera de estructurar una aplicación Vue.js para que pueda seguir siendo mantenible y extensible, incluso cuando llega a un tamaño muy grande, ¿verdad? ¿Por qué es importante esta pregunta? Porque probablemente todos hemos recibido una tarea para una aplicación en particular antes y hemos tenido este mismo sentimiento. Simplemente no sabemos por dónde empezar, ni siquiera sabemos cómo abordar el problema, tal vez porque las cosas están un poco desordenadas. Entonces, nuestro objetivo es eliminar este sentimiento aquí tanto como humanamente sea posible. Está bien, todos queremos disfrutar de nuestros trabajos y estar menos frustrados.

Bueno, voy a comenzar con este consejo clave para hacer una aplicación a gran escala, que es hacer que tu base de código sea predecible. Este primer consejo realmente no es tan emocionante, realmente no es tan llamativo, pero para ser honesto, esta es una de las claves, en mi opinión, para construir una aplicación mantenible. Hazlo lo más predecible posible siguiendo estándares, para que todos sepan dónde buscar y cómo funcionan ciertas cosas. Entonces, esto plantea la pregunta, ¿dónde existen los estándares para la comunidad de Vue.js? El primer lugar que me viene a la mente es la guía de estilo de Vue.js. Este es el lugar oficial para los estándares de estilo para el marco de Vue. Aquí hay un ejemplo de algunos estándares designados dentro del documento. Cuando se trata de nombrar tus componentes, en primer lugar, dice que todos tus componentes deben estar en Pascal case. También menciona que debes prefijar tus componentes base con la palabra, app, o base. Entonces, estos son todos esos componentes que vas a utilizar en toda tu aplicación, y son de uso más general, ¿verdad? Estas son cosas como AppButton, AppTable, AppModal, cosas así. Cosas que aceptan props hacia abajo y eventos hacia arriba, y probablemente no dependen de ningún estado global, ¿de acuerdo? En realidad, prefiero usar App en este caso porque siempre pone mis componentes base en la parte superior de mi directorio de componentes. También menciona que debes tener nombres de varias palabras para tus componentes. Esto es en realidad más que solo una cosa de estilo, también es para prevenir conflictos entre los elementos HTML existentes o futuros y tus nuevos componentes. Otro estándar es prefijar todos tus componentes de instancia única con la palabra, the. Estos son cualquier componente que solo se va a utilizar en la página una sola vez. Ahora, absolutamente podrían usarse en varias páginas, pero solo aparecen en una sola instancia de una página a la vez. Por lo general, estos son componentes de tipo diseño, cosas como el encabezado, el pie de página, la barra lateral, y así sucesivamente. También se menciona que debes prefijar los componentes hijos estrechamente acoplados. Por ejemplo, si tuvieras un componente para un artículo que siempre existía dentro de una lista de tareas, prefijarías ese nombre de componente con la lista de tareas, y luego el artículo. Una aplicación real de esto que utilicé en una base de código en mi trabajo anterior fue que tenía un componente de formulario de trabajo, y luego había un campo especial para elegir la ubicación donde se debería anunciar un trabajo llamado campo de mapa de ubicación de formulario de trabajo. Entonces, esto le dice a cualquier otro desarrollador dentro del proyecto que este componente realmente solo está destinado a ser utilizado en el contexto del formulario de trabajo. Y pueden obtener eso solo mirando el nombre del componente. Está bien, esto es genial, y hay otros consejos sobre cómo estilizar los nombres de tus componentes dentro de la guía de estilo también, pero esto es solo una buena muestra, y ciertamente hay mucho más disponible en la guía de estilo además de solo el nombramiento de componentes.

Pero esto es solo una buena muestra para mostrarte, oye, si implementas estos estándares, es una cosa cognitiva menos que las personas que se incorporan a tu proyecto tienen que pensar, porque son estándares que todos ya conocen, ¿vale?

Por cierto, justo en el momento de esta charla, es importante tener en cuenta esta advertencia en la parte superior de la guía de estilo, y es que actualmente está un poco desactualizada. La mayoría de los ejemplos están solo en la API de opciones, y no hay reglas con respecto a Script Setup y la Composition API. Sin embargo, como acabas de ver, muchas de las cosas para el estilo ni siquiera necesariamente tienen que ver con una API u otra. Todas las cosas de nombramiento de componentes podrían aplicarse a cualquier API. Así que esto sigue siendo un gran recurso, pero espera que se actualice en el futuro, ¿vale?

Otro recurso realmente excelente para los estándares es la tooling oficialmente recomendada para Vue.js, ¿de acuerdo? Se encuentra en la página de tooling de la documentación oficial de Vue.js. Proporciona referencia a cosas como Vite para tu servidor de desarrollo y Opinion para la gestión global del estado. Esto puede parecer que se da por sentado, pero tal vez he ignorado algunos de mis propios consejos en el pasado y quiero asegurarme de que no hagas lo mismo. ¿A qué me refiero? Bueno, uno de los proyectos en los que estaba trabajando antes de unirme a la escuela Vue, por supuesto, necesitaba una gestión global del estado. Bueno, no estaba emocionado con la DX que proporcionaba Vuex, y así que se me ocurrió mi propia solución de gestión global del estado basada en la API Vue.Observable en Vue 2. La historia corta es que, sí, hubo algunas mejoras en DX. Sin embargo, hubo más desventajas que ventajas. Hubo problemas de caché que no manejé que Vuex ya habría manejado por mí bajo el capó. Hubo problemas de incorporación cuando se trataba de mover a nuevas personas al proyecto a quienes tuve que explicarles esta solución personalizada que si solo hubiera usado Vuex ya estarían familiarizados con ella o al menos podría haberlos apuntado en la dirección de la documentación de Vuex, ¿verdad? Así que la clave aquí es si hay una solución oficialmente recomendada para tu problema, definitivamente piensa mucho antes de usar cualquier otra cosa, ¿vale?

Así que previsibilidad de la guía de estilo, previsibilidad de la tooling oficialmente recomendada, y finalmente otra gran fuente, creo, de previsibilidad es el metaframework NUX3, ¿vale? Toma muchas decisiones basadas en opiniones y es un gran jugador en la community de Vue.js, muchas personas estarán familiarizadas con las convenciones que proporciona. Así que definitivamente recomiendo tomar indicaciones de NUX3 cuando se trata de estructurar tu aplicación o simplemente usar NUX3 para empezar. Por cierto, verás que NUX3 aparece algunas veces más en esta charla porque creo que es un excelente software. Bueno, entonces el consejo número dos es aprovechar al máximo tu IDE. Después de todo, este es el software que vas a usar más para desarrollar tu aplicación. En primer lugar, eso significa asegurarte de instalar Volar, eso es probablemente bastante obvio. Sin embargo, el número dos también es asegurarte de que tienes ESLint instalado en todos tus proyectos. He trabajado en proyectos antes donde no hicimos esto. Déjame decirte, fue un dolor absoluto porque ESLint te ayudará a detectar elementos directamente dentro de tu IDE sin tener que esperar para descubrirlos en tiempo de ejecución. De hecho, te mostrará errores en tu IDE que incluso podrías no obtener errores duros para dentro del navegador, ¿vale?

Entonces, por ejemplo, en este pequeño fragmento de código, estamos usando un V4 para recorrer item en items pero hemos dejado la clave. Esto no daría error en el navegador pero mi IDE sabe ahora gracias a ESLint que realmente debería agregar esta clave a mi V4. Y lo mismo aquí abajo para este componente Hello World. Se está importando y registrando. Sin embargo, no se está utilizando en ninguna parte dentro de mi plantilla. Así que ESLint está salvando a mi usuario final de tener que descargar este código extra que nunca se utiliza. Correcto, obtengo esto esencialmente gratis solo instalando ESLint, ¿vale? Es una decisión absolutamente obvia. Similar a esto es asegurarte de que el formateo de tu IDE esté configurado adecuadamente.

Bueno, este podría ser el formateo que viene integrado con ESLint o podría ser un formateador más opinado como Prettier. Pero no importa qué, asegúrate de que tu IDE esté configurado para hacer este formateo automáticamente por ti, ya sea al guardar el archivo o lo que sea, solo asegúrate de no tener que cargar con esa carga cognitiva tú mismo. Simplemente no es necesario. La tooling puede hacerlo por ti, ¿vale?

Si te gustaría obtener más tips y trucos sobre cómo aprovechar al máximo tu IDE en el contexto de un proyecto de Vue.js, te recomiendo encarecidamente que eches un vistazo a este curso muy valorado que tenemos en Vue School. Mucha gente me ha dado muy buenos comentarios de que esto les ha ayudado a optimizar su flujo de trabajo. Vale, se llama Visual Studio Code para desarrolladores de Vue.js. Y en él, repasamos algunas de las cosas de las que acabo de hablar, pero también nos adentramos en cosas como utilizar los snippets de Vue.js que proporciona la community, crear tus propios snippets de Vue.js, optimizar tu flujo de trabajo para Git en términos de usar tu IDE, y mucho más. Así que definitivamente echa un vistazo a eso si Visual Studio Code es tu IDE de elección.

Por último, realmente, realmente, realmente recomiendo que consideres usar TypeScript en tus proyectos de Vue.js a gran escala. Van a llevar el conocimiento de tu IDE del código a un nivel absolutamente otro que simplemente no es posible sin TypeScript, ¿vale? Esto te ayudará a prevenir errores mientras estás desarrollando tu código, hará que tus refactorizaciones sean menos estresantes y menos riesgosas, y ayudará a dar a tu autocompletado superpoderes. Si no estás familiarizado con el uso de TypeScript en el contexto de un proyecto de Vue.js, en Vue School, sí, también tenemos un curso para ti allí. Te enseñaremos cómo escribir prompts de componentes, escribir eventos de componentes, escribir refs de plantillas, y mucho más, ¿vale? Y aunque seas completamente nuevo en TypeScript y no conozcas solo los conceptos básicos, tenemos un curso de Fundamentos de TypeScript para ti. ¿Vale? Simplemente no tengo tiempo para entrar en todos los detalles de esas cosas durante esta charla, pero quiero darte los recursos. Finalmente, Nuxt 3, nota, tiene TypeScript instalado por defecto. Y si eres completamente nuevo en TypeScript, realmente creo que usar Nuxt 3 es una excelente manera de experimentar y simplemente jugar y acostumbrarte a usar TypeScript en un nuevo proyecto. ¿Por qué? Bueno, porque simplemente está instalado por defecto. Puedes usar JavaScript todo lo que quieras. Puedes usar componentes regulares de JavaScript, y luego, según lo veas necesario, implementar un componente de TypeScript aquí y allá y espolvorearlo en tu proyecto progresivamente a medida que te acostumbras a él. ¿Vale? Realmente una excelente manera de empezar con TypeScript. Y por cierto, en el contexto de un proyecto de Nuxt, incluso obtienes algunos tipos especiales generados para ti sobre la marcha por el framework. Así que, por ejemplo, si tienes algunos puntos finales de API configurados internamente dentro del proyecto basados en una convención de archivos especial, el Nuxt especifica, puedes obtener autocompletado cada vez que llamas a fetch en cualquiera de esos puntos finales de API porque genera estos tipos sobre la marcha basados en las convenciones de la estructura de archivos. Así que eso es realmente genial. Hablando de estructura de archivos, siempre me hacen esta pregunta, ¿cómo debería organizar mis archivos para mi proyecto a gran escala? Y mi respuesta simple hoy en día es simplemente usar los estándares que proporciona Nuxt. Y de hecho, simplemente adelante y usa los estándares que están realmente dentro del proyecto. De hecho, comienza tu proyecto con Nuxt3 porque no solo obtienes los grandes estándares, sino que obtienes algo de magia genial encima de esos estándares. Por ejemplo, cualquier componente que se crea dentro del directorio de componentes se auto-importa para ti. No tienes que importarlos manualmente a lo largo de tu proyecto. Lo mismo ocurre con los composables, ¿vale? Los plugins también se auto-registran y las páginas dentro del directorio de páginas se convierten automáticamente en rutas. Esto se llama enrutamiento basado en archivos. Así que hay muchas cosas buenas allí cuando se trata de la estructura de archivos de Nuxt, ¿vale? Grandes convenciones pero también gran funcionalidad.

El consejo número cuatro es elaborar una convención de nomenclatura para sus rutas. Esto no es algo que esté especificado oficialmente para Vue.js en ningún lugar. Sin embargo, muchos otros frameworks por ahí sí tienen convenciones de nomenclatura de rutas. Y la que ves en la pantalla frente a ti ahora se ha tomado directamente de los docs de Laravel. Así que podría estar trabajando en un frontend de Vue.js y otros desarrolladores que están en mi equipo que están familiarizados con Laravel también podrían estar trabajando en este frontend y podrían tener una forma predecible de trabajar con rutas si sigo la misma convención para mi frontend. Así que tu equipo podría no usar Laravel. Eso está perfectamente bien. Mi punto es tener algún tipo de convención en su lugar. Y si necesitas inspiration para una, definitivamente te sugiero que revises los docs de Laravel porque esta convención es realmente genial. ¿De acuerdo? El consejo número cinco es envolver tu código de terceros.

Este es un concepto que Josh Deltner explica muy bien en su artículo titulado Nuxt Enterprise Patterns Provider Abstractions. ¿De acuerdo? ¿Por qué deberíamos hacer esto? Bueno, disminuye nuestra posibilidad de inicio de sesión de terceros y aumenta el área de superficie para optimizaciones específicas de la aplicación. Es posible que en realidad no entiendas lo que eso significa. Así que permíteme mostrarte con un pequeño ejemplo de código.

¿De acuerdo? Así que vamos a suponer que estamos usando Axios en nuestro proyecto para hacer nuestras solicitudes AJAX. Ahora, Axios es lo suficientemente popular como para que yo no sugiera envolver Axios. Yo sugeriría usarlo directamente. Sin embargo, es una biblioteca buena y común que creo que ayuda a las personas a entender este patrón. Así que no envolvería esto en tus aplicaciones, pero lo haría para dependencias de terceros similares.

Bueno, digamos que tienes Axios. Para envolver Axios, podrías crear una clase llamada HTTP y luego definir un método get en esa clase. Bajo el capó, todo lo que realmente estás haciendo es llamar al método get de Axios. Y luego podrías hacer lo mismo para los otros tipos de métodos y así sucesivamente. Pero, ¿por qué en el mundo querría hacer esto, Daniel? Quiero decir, no me pagan por línea, ¿verdad? Bueno, la ventaja aquí es que si, por alguna razón, alguna vez tuviéramos que reemplazar esa dependencia por algo más, podría hacerlo muy fácilmente en un solo lugar. Así que, aquí, hemos cambiado Axios por la función nativa del navegador fetch. Y lo hermoso es que solo hemos tenido que cambiarlo en un lugar, es decir, en nuestra clase HTTP. No tuvimos que buscar en toda la base de código, hacer un montón de búsquedas y reemplazos desordenados, solo tuvimos que centrarnos en este único archivo. Y lo otro hermoso de esto es que todos los demás desarrolladores que trabajan en el proyecto que están usando esta clase HTTP en todo el proyecto, ni siquiera tienen que saber que he actualizado la dependencia. Simplemente siguen usando la clase HTTP como de costumbre, ¿de acuerdo?

Así que, esta es una solución realmente genial cuando se trata de dependencias de las que tal vez no estés tan seguro, que piensas que podrían no tener la longevidad. Podrías ser reemplazado más adelante por algo más. Así que, no estoy diciendo que envuelvas todo tu código de terceros, pero sé selectivo y sí envuelve algo de tu código de terceros, ¿de acuerdo? Otro gran beneficio de envolver este código de terceros es que se presentan oportunidades para extender la funcionalidad para casos de uso específicos de la aplicación. Así que, por ejemplo, digamos que quería manejar todos mis errores HTTP de una manera particular en mi aplicación. Bueno, en ese punto, es tan fácil como añadir un try-catch dentro de mi única clase. Ahora, por supuesto, esta experiencia de usuario no es genial, pero entiendes la idea. Puedo tener estas optimizaciones específicas de la aplicación todas envueltas en mi clase. Y luego, cuando voy a usar la clase en toda la aplicación, no tengo que preocuparme por informar de estos errores al usuario o lo que sea. Lo mismo podría aplicarse a un mecanismo de caché. Bueno, creo que entiendes la idea. Por cierto, esto también funciona para componentes y no solo para bibliotecas de ayuda funcionales. Así que, por ejemplo, este componente app-icon que tengo aquí está hecho para hacer mi solución de iconos de mi aplicación genérica e incluso extenderla para que pueda usar dos soluciones de iconos diferentes a la vez, así que ves aquí mi app-icon envuelve font awesome así como los iconos de design material, y he proporcionado una única interfaz que es el componente app-icon para implementar los iconos en toda mi aplicación.

Por ejemplo, este componente app-icon que tengo aquí está hecho para hacer mi solución de iconos de mi aplicación genérica e incluso extenderla para que pueda usar dos soluciones de iconos diferentes a la vez, así que ves aquí mi app-icon envuelve font awesome así como los iconos de diseño material, y he proporcionado una única interfaz que es el componente app-icon para implementar los iconos en toda mi aplicación.

Genial. Bueno, entonces el consejo número seis es interactuar con tus backends a través de un SDK. Bien, echa un vistazo a estas dos líneas aquí. ¿Cuál de estas preferirías escribir? ¿Preferirías escribir la solicitud completa, algo así, o preferirías escribir algo corto y simple, como esto? Para mí, la respuesta es clara. Quieres hacer la opción número dos, ¿verdad? Bueno, hay varias ventajas diferentes si eliges esta opción. Número uno, y más simplistamente, te ayuda a prevenir errores tipográficos, ¿vale? No tendrás que preocuparte por los errores tipográficos en la ruta de tu punto final de API. Pero también te proporciona la oportunidad de hacer la normalización de datos del lado del cliente en un solo lugar. Piensa en convertir todas tus cadenas de fecha que vienen del backend a objetos de fecha reales en JavaScript, o cualquier otro dato derivado tal vez, como cosas calculadas que necesitas hacer, o algo así. Vale, eso puede ser envuelto en el SDK real, y tu código cliente real no tiene que pensar en ello, ¿vale? También es más fácil con los SDKs detectar errores y proporcionar seguridad de tipo. Por cierto, no tienes que escribir estos SDKs por ti mismo. Hay muchas soluciones por ahí que vienen con SDKs de JavaScript ya construidos para ti. Así que cosas como Firebase son realmente geniales para esto, que por cierto, usamos en la masterclass de Vue.js 3 como backend, y Superbase, que se autodenomina alternativa de código abierto a Firebase, es una solución que realmente me gusta, donde incluso proporcionan un comando para generar automáticamente tus tipos de TypeScript basados en la estructura de tu base de datos. Y esto hace que sea realmente, realmente genial trabajar con ello, ¿vale? Por cierto, si te gusta Laravel, también hay esta biblioteca de consultas de Laravel, biblioteca de generación de consultas que hace mucho lo mismo que algunas de estas otras dos de las que acabo de hablar. Así que te sugeriría que lo revisaras si te gusta Laravel.

Genial, ese es mi tiempo contigo hoy. Quería dejarte con solo unas pocas recomendaciones para algunos cursos de Vue School que creo que te ayudarán a construir mejores aplicaciones a gran escala. El número uno es el curso de TypeScript con Vue JS 3, del que ya hemos hablado un poco. El siguiente es nuestro curso Pina la tienda Vue agradable. Esto te ayudará a tener una gran comprensión de la solución oficial de gestión de estado Pina para Vue, y por último está envolviendo pruebas rápidas con V-test. Por cierto, también acabamos de terminar de lanzar este gran nuevo curso llamado Chatbot AI con Vue JS y GPT-4. Si estás interesado en implementar AI en tus aplicaciones, tus aplicaciones Vue JS, definitivamente te sugiero que lo revises. Y la certificación oficial de Vue JS se ha lanzado y se están aceptando pre-órdenes. Así que esto es algo que el equipo de Vue School está haciendo en colaboración con el equipo central de Vue. Si te gustaría demostrar tus habilidades de desarrollo de Vue JS a posibles empleadores o posibles clientes, esta es una gran manera de hacerlo. Muchas gracias a todos por su tiempo. Y espero que hayan obtenido algunos conocimientos valiosos de la charla de hoy. Todos ustedes tengan un maravilloso día y sigan programando. Gracias. ______________________________________________________________________________________________________ __________________________________________________________________ ______________________________________________________________________ __________________________________________________ __________________________________________________________