Patrones para Aplicaciones Vue.js a Gran Escala

Y ese tema es examinar algunos patrones para el desarrollo de aplicaciones Vue.js a gran escala, ¿verdad? 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 escalable, incluso a medida que crece en tamaño, ¿verdad? ¿Por qué es importante esta pregunta? Porque probablemente todos hemos recibido una tarea para una aplicación específica antes y hemos tenido esta sensación exacta. 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 esta sensación aquí tanto como sea posible. Bien, todos queremos disfrutar de nuestro trabajo y estar menos frustrados.

De acuerdo, voy a comenzar con este consejo clave para crear una aplicación a gran escala, que es hacer que tu base de código sea predecible. Este primer consejo no es realmente emocionante, no es realmente llamativo, pero para ser honesto, este es uno de los aspectos clave, en mi opinión, para construir una aplicación mantenible. Hazla 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 framework Vue. Aquí tienes 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 agregar el prefijo 'app' o 'base' a tus componentes base. Entonces, estos son todos esos componentes que vas a usar en toda tu aplicación, y son casos de uso mucho más generales, ¿verdad? Son cosas como AppButton, AppTable, AppModal, cosas así. Cosas que aceptan props y emiten eventos, y probablemente no dependen de ningún estado global, ¿de acuerdo? En este caso, prefiero usar App porque siempre coloca mis componentes base en la parte superior de mi directorio de componentes. También menciona que debes tener nombres de componentes con varias palabras. Esto en realidad va más allá de ser solo un estilo, también es para evitar conflictos entre elementos HTML existentes o futuros y tus nuevos componentes. Otro estándar es agregar el prefijo 'the' a todos tus componentes de instancia única. Estos son componentes que solo se usarán en la página una sola vez. Ahora, definitivamente podrían usarse en varias páginas, pero solo aparecen en una instancia única de una página a la vez. Por lo general, son componentes de diseño, como el encabezado, el pie de página, la barra lateral, y así sucesivamente. También se menciona que debes agregar prefijos a los componentes secundarios estrechamente acoplados. Por ejemplo, si tuvieras un componente para un elemento que siempre existe dentro de una lista de tareas, agregarías el prefijo 'to-do list' al nombre del componente, y luego 'item'. Un ejemplo de aplicación real 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 debe anunciar un trabajo llamado campo de mapa de ubicación del formulario de trabajo. De acuerdo, esto le dice a cualquier otro desarrollador dentro del proyecto que este componente solo está destinado a ser utilizado en el contexto del formulario de trabajo. Y pueden entender eso solo mirando el nombre del componente. De acuerdo, esto es genial, y también hay otros consejos sobre cómo estilizar los nombres de tus componentes en la guía de estilo, pero esto es solo una buena muestra, y ciertamente hay mucho más disponible en la guía de estilo además del nombramiento de componentes.

Pero esto es solo una buena muestra para mostrarte que, si implementas estos estándares, es una cosa cognitiva menos en la que las personas que se integran a tu proyecto tienen que pensar, porque son estándares que todos conocen, ¿de acuerdo?

Por cierto, 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 está un poco desactualizada. La mayoría de los ejemplos están en la API de opciones solamente y no hay reglas con respecto a Script Setup y la API de composición. Sin embargo, como acabas de ver, muchas de las cosas de estilo no necesariamente tienen que ver con una API u otra. Todas las cosas de nombramiento de componentes podrían aplicarse a cualquiera de las API. Así que este sigue siendo un gran recurso, pero espera que se actualice en el futuro, ¿de acuerdo?

Otro recurso realmente bueno para los estándares es la herramienta recomendada oficialmente para Vue.js, ¿de acuerdo? Eso se encuentra en la página de herramientas de la documentación oficial de Vue.js. Proporciona referencias a cosas como Vite para tu servidor de desarrollo y Opinion para la gestión global del estado. Esto puede parecer obvio, pero tal vez he ignorado algunos de mis propios consejos en el pasado y quiero asegurarme de que no hagas lo mismo. ¿Qué quiero decir? Bueno, uno de los proyectos en los que estaba trabajando antes de unirme a Vue School, por supuesto, necesitaba una gestión global del estado. Bueno, no estaba emocionado con la experiencia de desarrollo que Vuex proporcionaba, así que ideé mi propia solución de gestión global del estado basada en la API Observable de Vue en Vue 2. En resumen, sí hubo algunas mejoras en la experiencia de desarrollo. Sin embargo, hubo más desventajas que ventajas. Hubo problemas de almacenamiento en caché que no manejé y que Vuex ya habría manejado por mí. Hubo problemas de integración cuando se trataba de incorporar nuevas personas al proyecto a las que tuve que explicar esta solución personalizada que, si simplemente hubiera usado Vuex, ya estarían familiarizadas con ella o al menos podría haberles señalado la documentación de Vuex, ¿verdad? Así que la lección clave aquí es que si hay una solución recomendada oficialmente para tu problema, definitivamente piensa mucho antes de usar cualquier otra cosa, ¿de acuerdo?

Entonces, la previsibilidad de la guía de estilo, la previsibilidad de las herramientas recomendadas oficialmente y, finalmente, otra gran fuente, creo, de previsibilidad es el metaframework NUX3, ¿de acuerdo? Toma muchas decisiones con opiniones y es un jugador tan importante en la comunidad de Vue.js que muchas personas estarán familiarizadas con las convenciones que ofrece. Así que definitivamente recomiendo tomar referencias de NUX3 cuando se trata de estructurar tu aplicación o simplemente usar NUX3 desde el principio. Por cierto, verás que NUX3 aparecerá algunas veces más en esta charla porque creo que es un excelente software. Bien, así que el segundo consejo es aprovechar al máximo tu IDE. Después de todo, es el software que más vas a usar para desarrollar tu aplicación. Eso significa, en primer lugar, asegurarte de instalar Volar, eso probablemente es bastante obvio. Sin embargo, en segundo lugar, también asegúrate de tener ESLint instalado en todos tus proyectos. He trabajado en proyectos en los que 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 a descubrirlos en tiempo de ejecución. De hecho, te mostrará errores en tu IDE que tal vez ni siquiera obtengas como errores graves en el navegador, ¿de acuerdo?

Por ejemplo, en este pequeño fragmento de código, estamos usando un V4 para iterar sobre item en items, pero nos hemos olvidado de la clave. Esto no daría un error en el navegador, pero mi IDE lo sabe ahora gracias a ESLint, realmente debería agregar esta clave a mi V4. Y lo mismo aquí para este componente Hello World. Se está importando y registrando. Sin embargo, en realidad no se está utilizando en ninguna parte de mi plantilla. Así que ESLint está evitando que mi usuario final tenga que descargar este código adicional que ni siquiera se usa. ¿Verdad? Obtengo esto esencialmente de forma gratuita solo instalando ESLint, ¿de acuerdo? Es una decisión obvia. Algo similar a esto es asegurarte de que el formateo de tu IDE esté configurado correctamente.

De acuerdo, esto podría ser el formateo que está integrado con ESLint o podría ser un formateador más orientado como Prettier. Pero sin importar qué, asegúrate de configurar tu IDE para hacer este formateo automáticamente por ti, ya sea al guardar el archivo o como sea, solo asegúrate de no tener que asumir esa carga cognitiva tú mismo. Simplemente no es necesario. La herramienta puede hacerlo por ti, ¿de acuerdo?

Si deseas más consejos y trucos sobre cómo aprovechar al máximo tu IDE en el contexto de un proyecto de Vue.js, te recomiendo encarecidamente que consultes este curso altamente valorado que tenemos en Vue School. Muchas personas me han dado muy buenos comentarios de que esto les ha ayudado a optimizar su flujo de trabajo. Está llamado 'Visual Studio Code para Desarrolladores de Vue.js'. En él, repasamos algunas de las cosas de las que acabo de hablar, pero también entramos en detalles sobre cómo utilizar los fragmentos de código de Vue.js proporcionados por la comunidad, cómo crear tus propios fragmentos de código de Vue.js, cómo optimizar tu flujo de trabajo para Git en términos de utilizar tu IDE, y mucho más. Así que definitivamente échale un vistazo si Visual Studio Code es tu IDE de elección.

Por último, realmente, realmente, realmente te recomiendo que consideres usar TypeScript en tus proyectos de Vue.js a gran escala. Esto llevará el conocimiento de tu IDE sobre el código a otro nivel que simplemente no es posible sin TypeScript, ¿de acuerdo? Esto te ayudará a prevenir errores mientras desarrollas tu código, hará que tus refactorizaciones sean menos estresantes y menos arriesgadas, y ayudará a que tu autocompletado tenga superpoderes. Si no estás familiarizado con el uso de TypeScript en el contexto de un proyecto de Vue.js, en Vue School también tenemos un curso para ti. Te enseñaremos cómo tipar las propiedades de los componentes, cómo tipar los eventos de los componentes, cómo tipar las referencias de la plantilla y mucho más, ¿de acuerdo? Y aunque seas completamente nuevo en TypeScript y no conozcas los conceptos básicos, también tenemos un curso de Fundamentos de TypeScript para ti. ¿De acuerdo? No tengo tiempo para entrar en todos los detalles de estas cosas durante esta charla, pero quiero darte los recursos. Por último, Nuxt 3, ten en cuenta que viene con TypeScript instalado por defecto. Y si eres completamente nuevo en TypeScript, creo que usar Nuxt 3 es una excelente manera de experimentar y acostumbrarte a usar TypeScript en un nuevo proyecto. ¿Por qué? Porque simplemente viene instalado por defecto. Puedes usar JavaScript todo lo que quieras. Puedes usar componentes de JavaScript normales y luego, según sea necesario, implementar un componente de TypeScript aquí y allá y agregarlo progresivamente a tu proyecto a medida que te acostumbras. ¿De acuerdo? Es una excelente manera de comenzar con TypeScript. Y por cierto, en el contexto de un proyecto de Nuxt, incluso obtienes algunos tipos especiales generados automáticamente por el framework. Por ejemplo, si tienes algunas endpoints de API configuradas internamente dentro del proyecto basadas en una convención de archivos especial que especifica Nuxt, puedes obtener autocompletado cuando llames a fetch en cualquiera de esos endpoints de API porque genera estos tipos automáticamente en función de las convenciones de la estructura de archivos. Así que eso es realmente genial. Hablando de la estructura de archivos, siempre me hacen esta pregunta, ¿cómo debo 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, ve adelante y usa los estándares que están dentro del proyecto. Comienza tu proyecto con Nuxt 3 porque no solo obtienes los excelentes estándares, sino que también obtienes algunas características geniales adicionales sobre esos estándares. Por ejemplo, cualquier componente que se cree dentro del directorio de componentes se importa automáticamente para ti. No tienes que importarlos manualmente en todo tu proyecto. Lo mismo ocurre con los composables, ¿de acuerdo? Los plugins también se registran automáticamente 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 cuando se trata de la estructura de archivos de Nuxt, ¿de acuerdo? Grandes convenciones pero también una gran funcionalidad.

El consejo número cuatro es establecer una convención de nombres para tus rutas. Esto no está especificado oficialmente en Vue.js en ningún lugar. Sin embargo, muchos otros frameworks tienen convenciones de nombres para rutas. La que ves en la pantalla ahora mismo se extrae directamente de la documentación de Laravel. Podría estar trabajando en un frontend de Vue.js y otros desarrolladores de mi equipo que estén familiarizados con Laravel también podrían estar trabajando en este frontend. Si sigo la misma convención, ellos podrían tener una forma predecible de trabajar con las rutas. Tu equipo puede no utilizar Laravel, y está perfectamente bien. Mi punto es tener alguna convención establecida. Si necesitas inspiración, te sugiero que consultes la documentación de Laravel, ya que esta convención es realmente buena. ¿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 déjame mostrarte con un pequeño ejemplo de código.

¿De acuerdo? Así que finjamos que estamos usando Axios en nuestro proyecto para realizar nuestras solicitudes AJAX. Ahora, Axios es lo suficientemente popular como para no sugerir envolverlo. 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. Entonces, no envolvería esto en tus aplicaciones, pero lo haría para dependencias de terceros similares.

De acuerdo, así que digamos que tienes Axios. Para envolver Axios, podrías crear una clase llamada HTTP y luego definir un método get en esa clase. Básicamente, lo que estás haciendo es llamar al método get de Axios. Y podrías hacer lo mismo para los otros tipos de métodos y así sucesivamente. Pero, ¿por qué querría hacer esto, Daniel? Quiero decir, no me pagan por escribir por línea, ¿verdad? Bueno, la ventaja aquí es que si, por alguna razón, alguna vez tuviéramos que reemplazar esa dependencia por otra cosa, podría hacerlo muy fácilmente en un solo lugar. Entonces, aquí hemos cambiado Axios por la función fetch nativa del navegador. Y lo bueno es que solo tuvimos que cambiarlo en un solo lugar, es decir, en nuestra clase HTTP. No tuvimos que buscar en todo el código base, hacer un montón de búsquedas y reemplazos complicados, solo tuvimos que centrarnos en este archivo único. Y lo otro bueno de esto es que todos los demás desarrolladores que trabajan en el proyecto y que usan 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?

Entonces, esta es una solución realmente excelente cuando se trata de dependencias en las que quizás no estés tan seguro, que crees que podrían no tener una larga vida útil. Es posible que se reemplacen más adelante por otra cosa. No estoy diciendo que envuelvas todo tu código de terceros, pero sé selectivo y envuelve parte de tu código de terceros, ¿de acuerdo? Otro gran beneficio de envolver este código de terceros es que muestra oportunidades para extender la funcionalidad para casos de uso específicos de la aplicación. Por ejemplo, digamos que quiero manejar todos mis errores HTTP de una manera particular en mi aplicación. Bueno, en ese momento, es tan fácil como agregar un try-catch dentro de mi clase única. Ahora, por supuesto, esta experiencia de usuario no es genial, pero captas la idea. Puedo tener estas optimizaciones específicas de la aplicación todas envueltas en mi clase. Y luego, cuando vaya a usar la clase en toda la aplicación, no tengo que preocuparme por informar estos errores al usuario ni nada por el estilo. Lo mismo se podría aplicar para un mecanismo de almacenamiento en caché. De acuerdo, creo que captas la idea. Por cierto, esto también funciona para componentes y no solo para bibliotecas de ayuda funcionales. Entonces, por ejemplo, este componente app-icon que tengo aquí está hecho para hacer que mi solución de iconos en mi aplicación sea genérica e incluso extenderla para que pueda usar dos soluciones de iconos diferentes al mismo tiempo, así que aquí mi app-icon envuelve font awesome así como los iconos de material design. Y he proporcionado una interfaz única que es el componente app-icon para implementar realmente los iconos en toda mi aplicación.

Entonces, por ejemplo, este componente app-icon que tengo aquí está hecho para hacer que mi solución de iconos en mi aplicación sea genérica e incluso extenderla para que pueda usar dos soluciones de iconos diferentes al mismo tiempo, así que aquí mi app-icon envuelve font awesome así como los iconos de material design, y he proporcionado una interfaz única que es el componente app-icon para implementar realmente los iconos en toda mi aplicación.

Genial. Muy bien, el consejo número seis es interactuar con tus backends a través de un SDK. Bien, mira estas dos líneas aquí. ¿Cuál de estas preferirías escribir? ¿Preferirías escribir la solicitud completa, algo como esto, 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. En primer lugar, y de manera más simple, te ayuda a prevenir errores de escritura, ¿vale? No tendrás que preocuparte por errores de escritura en la ruta de tu punto de conexión de API. Pero también te brinda la oportunidad de normalizar los datos en el lado del cliente en un solo lugar. Piensa en convertir todas tus cadenas de fecha provenientes del backend en objetos de fecha reales en JavaScript, o cualquier otro dato derivado tal vez, como cálculos que necesites hacer, o algo así. Vale, eso se puede envolver en el SDK real, y tu código de cliente real no tiene que preocuparse por eso, ¿vale? También es más fácil con los SDKs detectar errores y proporcionar seguridad de tipos. Por cierto, no tienes que escribir estos SDKs tú mismo. Muchas soluciones ya vienen con SDKs de JavaScript ya construidos para ti. Cosas como Firebase son realmente geniales para esto, que, por cierto, usamos en la masterclass de Vue.js 3 como backend, y Superbase, que es una alternativa de código abierto a Firebase, es una solución que me gusta mucho, 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, una biblioteca de generador de consultas que hace algo similar a las otras dos de las que acabo de hablar. Así que te sugiero que lo revises si te gusta Laravel.

Genial, eso es todo el tiempo que tengo hoy con ustedes. Quería dejarles algunas 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. Luego está nuestro curso Pina, la agradable tienda de Vue. Esto te ayudará a comprender mejor la solución oficial de gestión de estado Pina para Vue, y por último, envolver pruebas rápidas con V-test. Muy bien, por cierto, acabamos de lanzar este nuevo y genial curso llamado Chatbot de IA con Vue JS y GPT-4. Si estás interesado en implementar IA en tus aplicaciones, tus aplicaciones de Vue JS, definitivamente te sugiero que lo revises. Y la certificación oficial de Vue JS ya ha sido lanzada y se están aceptando pedidos anticipados. Esto es algo que el equipo de Vue School está haciendo en colaboración con el equipo principal de Vue. Si quieres demostrar tus habilidades de desarrollo de Vue JS a posibles empleadores o clientes potenciales, esta es una excelente manera de hacerlo. Muchas gracias a todos por su tiempo. Y espero que hayan obtenido conocimientos valiosos de la charla de hoy. Que tengan un maravilloso día y sigan programando. Gracias. ______________________________________________________________________________________________________ __________________________________________________________________ ______________________________________________________________________ __________________________________________________ __________________________________________________________