Do you want to switch to Platzi in English?
3

"Mi" Arquitectura en Vue.

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:

  • Deben de ser ‘dummies’, deben de seguir el principio de responsabilidad única.
  • Esto quiere decir que tu componente debe de hacer sólo su trabajo y nada más. Ejemplo, una tabla debe ordenar los datos en columnas y filas
    dependiendo de datos pasados desde un padre.
  • Deben tener sólo la lógica necesaria.
  • No debe interactuar conel exterior, directamente. La única forma de interactuar conel exterior es con eventos.
  • Deben ser independientes. Esto quiere decir que pueden y deben funcionar por su cuenta.
  • Deben ser reutilizables.
  • Deben ser “estilables” desde fuera.

1.2.- Regla de oro de los componentes:

https://cdn-images-1.medium.com/max/1600/1*3rhYZXBHEPmBhF3SQ_O3Yg.png

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.

Escribe tu comentario
+ 2
0
1992Puntos

Muchas gracias por compartir ésta información, de verdad me ha ayudado con mis proyectos. Quisiera saber si tienes experiencia trabajando Vue js con Php nativo / laravel, tienes alguna idea de cómo sería la arquitectura en ese caso?