angular para grandes aplicaciones (4)

Cómo organizar los archivos y el peligro de backizar el front

Jake Baddeley

archivado en: JavaScript / 17 octubre, 2015 / taller:

El otro día me preguntaron cómo funcionaba la comunicación entre dos módulos de angular que coexisten en una misma página. Como el tema encaja con esta serie de angular para grandes aplicaciones, reproduzco por aquí parte de la respuesta, pero antes de entrar en materia quiero abordar otro caso que me comentó un colega: la combinación de angular con grandes frames back MVC. En concreto, en el proyecto que me contó habían combinado Simfony con Angular y cuando digo combinado es porque la parte back seguía comportándose de forma tradicional. Es decir, pintaba las vistas, en las cuales se encajaban módulos angular. Algo así:

angular_multiples_modulos

No es el único caso similar que conozco. Bueno, mientras funcione, sea escalable y mantenible, no hay razón a priori para decir que esté mal en términos absolutos, pero creo que este tipo de combinaciones no funcionan y paso a explicar por qué.

Angular es un frame complejo, con una curva de aprendizaje muy alta, que alcanza su verdadero potencial en las single-page application (SPA) o aplicaciones de una sola página. Es en estos escenarios donde podemos aprovechar lo que realmente hace de angular un frame formidable, como el ruteo por estados, el patrón singleton de las factorías o la reutilización de directivas. Si lo utilizamos como un mero contenedor del js de una sola página, estaríamos matando moscas a cañonazos. Es más, ni siquiera sería la mejor opción, pues hay frames mucho más ligeros que cubren esta función de forma más efectiva, aunque la verdad es que para algo así yo solo usaría javaScript plano aka vanilla.js.

He trabajado mucho en back, en aplicaciones de decenas de miles de líneas de código, y sé por experiencia que al principio puede dar cierto vértigo pensar que la responsabilidad de una aplicación recaiga en el front... uf, con lo inestable que parece es javaScript. Y no digo que siempre deba ser así. Pero si se toma esa decisión, si esa es la mejor solución para el proyecto por la razón que sea, entonces hay que asumirla con todas sus consecuencias.

Dicho de otra manera: si el trabajo recae en la parte back, ya se esté gestionando con php, java, .net o lo que sea, y el javaScript solo se utiliza para gestionar componentes más o menos sofisticados, no vale la pena embarcarse en ese frame tan complejo que es angular. El resultado no compensa ni el coste en rendimiento del navegador ni los tiempos y costes de desarrollo.

Sin embargo, el que usemos angular para lo que sirve, esto es, para desarrollar SPAs que trabajan contra una api REST, no está reñido con el usar varios módulos, sobre todo en el caso de grandes aplicaciones. Ahora veremos cómo, pero antes conviene recordar cómo debería ser el scaffolding de la aplicación.

Estructuras básicas

Es tema de discusión cuál es la mejor manera de estructurar los archivos en una aplicación angular. En esencia hay dos tendencias. Una se conoce como angular-seed, está propuesta por el equipo de angular y se caracteriza por agrupar los controladores y las vistas relacionadas. Algo así:

app/

app.css

components/

directiva.js

filtro.js

vista1/

vista1.html

vista1.js

vista1_test.js

vista2/

vista2.html

vista2.js

vista2_test.js

app.js

index.html

La otra propuesta tiene su mejor ejemplo en el generator de angular de yeoman y sigue una estructura tradicional en los frames mvc, es decir, agrupa los archivos por tipología:

bower_componentes/

app/

css

fonts

images

scripts

controllers

controlador1

services

views

vista1

Ninguna de las dos propuestas afecta al rendimiento, las dos funcionan igual, sino que están diseñadas pensando en los procesos de desarrollo. Una piensa que es más cómodo tenerlo todo junto y otra que es mejor separar los archivos por su función.

A mí en general me gusta más la propuesta de Yeoman, sobre todo para grandes aplicaciones, pero también es cierto que para cosas pequeñas puede resultar más cómoda la otra estructura, sobre todo si los departamentos no están diferenciados y los programadores también asumen el cien por cien de la maquetación. Y creo que es mejor por cómo es el desarrollo natural de una aplicación grande: el grueso del trabajo se encuentra en el javaScript. Una vez maquetadas las vistas, salvo tres incidencias del explorer y algún matiz o cambio del diseño, raro es que se tengan que volver a tocar, por lo que me sobran en los directorios donde realmente se encuentra el material recurrente: controladores, directivas y servicios. Pero bueno, para gustos los colores.

Módulos

Decía al principio de este ladrillako que solo deberíamos tener un módulo principal, pero esto no impide que tengamos varios más complementarios. Para empezar podríamos separar algunas partes claramente diferenciadas. E insisto en que deben ser realmente cosas distintas. Por ejemplo, en una tienda on-line, quizás se podría diferenciar entre la parte que corresponde a la tienda propiamente dicha y la que aporta contenidos que le dan un valor añadido o información corporativa, como un blog o similar. Pero a la que tengan la menor relación, que usen el mismo servicio, que tiren de la misma directiva... entonces mejor agruparlas en una sola ng-app.

Otra cuestión diferente es que algunas funcionalidades con entidad propia, como podría ser la factoría rest o una sábana de componentes, se agrupe en un módulo que luego se inyecta en el módulo principal. Por ejemplo:

angular.module('factoryRest', [])

.factory("users", function() {

// todo el tinglado rest relacionado con users

});

angular.module('angularLab', [

'ngAnimate',

'factoryRest'

...

Este tipo de jugadas sí que es realmente útil en aplicaciones grandes, de cientos de archivos, pues nos permiten tener todo más organizadico, que es la única manera de no volverse tarumba cuando la criatura empieza a crecer.

Bueno, pues por hoy dejo este tema aquí.

|| Tags: ,

valoración de los lectores sobre angular para grandes aplicaciones (4)

  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • 5 sobre 5 (2 votos)

¿Te ha parecido útil o interesante esta entrada?
dormido, valoración 1 nadapensativo, valoración 2 un poco sonrisa, valoración 3 a medias guiño, valoración 4 bastante aplauso, valoración 5 mucho

Tú opinión es muy importante, gracias por compartirla!

Los comentarios están cerrados.