Hola, les quiero compartir la manera en la que he estado trabajando mis aplicaciones en Vue.js.
1. Componentes.
1.1.- Componentes, no navajas suizas
Los componentes deben de seguir sus principios, y no más de la cuenta. Un componente no debe de hacer llamadas al store o a servicios, ya que éste deja de ser reutilizable en ese momento. Algunos de los principios que he manejado son los siguientes:
1.2.- Regla de oro de los componentes:
1.3.- Estados de componentes
Al momento de realizar el componente debemos de tener en cuenta tres estados para éstos:
1. Loading
2.- Success
3.- Error
1.4.- No todo es un componente.
Se debe evitar crear componentes demasiado pequeños. Esto es para evitar la sobrecarga de componentes/dependencias innecesarias.
Ej: un texto con una imagen, una imagen, un link con un icono.
1.5.- ¿Comunicación entre componentes?
Éste tema se tocó en el curso, pero es algo importante de remarcar:
Vue por sí sólo no permite la comunicación entre eventos ‘nesteados’ o que se encuentran en páginas diferentes. Pero, hay muchos
approaches para lograrlo.
Por ejemplo: https://www.npmjs.com/package/vue-bus
Con esto se evita el ‘callback hell’ de eventos entre componentes. Y el código queda más limpio.
2.- Páginas como modelos
Las páginas pueden funcionar como modelos de los componentes (VM). Esto es porque una página es el padre de todos los componentes, y es el
que va a proveer de datos a estos. Aquí es dónde están las llamadas a el store (Vuex), los getters, las ejecuciónde un action, etc. Esta página es el
proveedor de información hacia los componentes, es quién da estilos (en algunos casos) y es quien acomoda en el DOM los componentes.
3.- Código Modular (Divide y vencéras, en serio, muy en serio)
Los módulos son piezas de código reutilizables quese pueden implementar en cualquier sitio.
Esto se refiere en hacer el código modular. Hacer un módulo de JS es similar a crear un componente visual de Vue, debe seguir los mismos principios de los que ya hablamos.
Es muy común encontrarnos con funciones que hacemos en el día a día o configuraciones que vamos a re-utilizar. En estos casos se debe crear un módulo.
El caso quemás me gusta para la creaciónde un módulo es el de las peticiones al servidor. Sí estás usando axios o algo similar puedes crear un modulo singleton que tenga lalógica necesaria para aceptar cualquier parámetro y así hacer una petición al servidor con una función sin tener que hacer un fetch o una instanciaciónde axios cada que hacemos una petición. Así nuestro código queda muy limpio y reutilizable.
4.- Estilos en la APP (componentes, layouts.).
Este es un tema que he visto en muchas apps y ejemplos no está muy bien definido. Cómo yo lo he manejado y me ha funcionado es de la siguiente forma:
4.1.- Estilos a componentes internos (dentro de la carpeta components o internos de la empresa)
Si un componente es de uso interno y no es abierto al público se pueden tener estilos base definidos, pero siempre deben de estar preparados para
aceptar cualquier cambio de estilos.
4.2.- Estilos a componentes de terceros (o componentes que serán open-source)
Estos componentes deben de tener estilos mínimos, ya que no sabemos quién ni bajo qué necesidad los usará. Deben de ser estilables desde fuera, siempre.
4.3.- Estilos globales
Debemos tener un archivo css globalde toda nuestra aplicación (un tema, o theme), aquí es dónde se definirán fuentes, tamaño de texto etc. Pero también los estilos de algunos componentes
o de algún Layout.
Por ejemplo, si tenemos un componente que tiene el mismo estilo a través de toda nuestra aplicación, éste estilo debe de ir en el tema global, esto para evitar la re-escritura de css
Casi todo nuestro css debe de ir aquí. Hay algunas excepciones, casos muy específicos en los cuales los estilos pueden ir en su página padre (el VM).
Gracias a los pre-procesadores podemos tener varios archivos e imprtarlos en el principal para evirtar la sobrecarga y así sea más legible.
Quedo pendiente a sus comentarios / propuestas. Me gustaría escuchar como lo hacen ustedes. Mi twitter es: @ederyairr.
