Estructura de una aplicación Angular 5

A lo largo de los artículos precedentes hemos ido viendo pinceladas de como funciona una aplicación Angular 5. Sin embargo, es necesario que tengamos una idea en perpectiva más clara, ya que, según vayamos avanzando, deberemos crear nuevas estructuras y aprender nuevas técnicas y, si no tenemos claro como funciona Angular 5 no seremos capaces de hacer nada que merezca la pena.

Lo cierto es que la estructura de una aplicación en Angular 5 es bastante compleja. Es normal, si tenemos en cuenta todas las funcionalidades que implementa el framework, y que iremos conociendo en los artículos de esta serie. Como contrapartida, lo bueno es que, a pesar de esa complejidad, está muy bien estructurada. Los creadores de Angular 5 se han esforzado muchísimo en darnos una estructura fácil de comprender y aprender. El resto, sólo son instrucciones de código.

En este artículo vamos a mostrar una visión global esquemática de la estructura de cualquier aplicación Angular 5, desde la aplicación «en vacío» como hemos estado viendo en los artículos anteriores, lo que necesitaremos para entender todo lo que aprenderemos después.

ESTRUCTURA BÁSICA

Sabemos que lo que ejecuta genera una serie de contenidos para renderizar en el navegador está en un componente (o en más de uno, claro). Una aplicación Angular está formada por dos tipos básicos de elementos: los componentes y los servicios. Estos, a su vez, se agrupan en módulos. Además, como en cualquier aplicación web existen enlaces que nos llevan de un contenido a otro, hay un sistema de enrutamiento que permite saltar de un módulo a otro. A grandes rasgos, el esquema de una aplicación web desarrollada con Angular puede parecerse al siguiente:

Este esquema está muy resumido, ya que, dentro de los módulos, podemos encontrar, por ejemplo, otros enrutadores que permitan acceder a distintos componentes o servicios del módulo, o de otros módulos. La estructura final puede ser tan compleja como lo requiera tu aplicación. Por contra, en la aplicación que hemos estado viendo, sólo hay un componente, y ningún servicio específico, así que, como ves, el esquema de arriba es muy generalista, sólo para tener una visión básica de conjunto.

EL MÓDULO

Y, por si te lo estás preguntando, sí. El componente con el que hemos estado enredando hasta ahora está encapsulado en un módulo, aunque hasta el momento no hayamos hablado de ello. Observa que dentro del directorio app tienes un archivo llamado app.module.ts. La página index.html no accede directamente al componente. Esto era sólo una primera aproximación para entender la importancia del selector, y donde se colocaba el código. Como el componente está encapsulado en el módulo, la página accede al componente dentro del módulo. Veamos cómo. El listado del fichero app.module.ts es el siguiente:

Es cierto que cuando una etiqueta HTML llama a un componente (que es el que tiene el código), lo relaciona a través del selector que coincide con la etiqueta. Eso ya lo hemos visto. Sin embargo, como el componente está encapsulado en el módulo, hay que pasar «a través» de esta envoltura. Vamos a analizarla someramente para ver como actúa:

En primer lugar, observa las dos primeras líneas. Se importan dos elementos propios de Angular. Uno de ellos es el BrowserModule, que permite que la aplicación corra en los navegadores, y el otro es el NgModule, que permite, como vamos a ver enseguida, definir qué es lo que «maneja» (de momento emplearemos ese término tan heterodoxo) el módulo. Cómo ves, estos elementos se importan desde carpetas del propio Angular, que se encuentran en node_modules, dentro de @Angular. No necesitamos saber como funcionan internamente estos elementos. Nos basta con saber que deben estar ahí.

En la línea 4 vemos que se importa el AppRoutingModule. Observa que esto no está dentro de node_modules, sino en la carpeta app, por lo que aparece como una ruta relativa. Esto hace referencia al enrutamiento dentro del módulo. Como aún no hemos hablado de enrutamientos, de momento lo dejamos ahí. Volveremos sobre el tema cuando veamos como se gestionan los enrutamientos en Angular.

A continuación observa la línea 6 (la primera destacada). fíjate que importa el componente que vamos a usar (AppComponent). Si te acuerdas, en el fichero app.component.ts las tres últimas líneas son las siguientes:

En Angular todo son clases: los módulos, los componentes que hay dentro… todo. El módulo importa una clase que es exportada por el componente.

Siguiendo con el fichero app.module.ts, lo siguiente que encontramos, entre las líneas 9 y 19 es lo que se llama el decorador (ya hemos comentado algo sobre este término). Un decorador es una función de Angular, con su nombre precedido con el signo @, que aporta operativa a la clase con la que estamos trabajando. No dejes que el término «decorador» te confunda, pensando que tiene algo que ver con CSS, o con cualquier aspecto gráfico, o visual, porque no es así. Es la forma en que los fabricantes de Angular llaman a estas funciones.

Dentro del decorador encontramos la clave declarations. En ella se referencian los componentes que se usan en este módulo, y que tienen que haber sido importados arriba. En este caso, sólo es AppComponent, porque este componente es lo único que, por ahora, tenemos.

También dentro del decorador encontramos la clave imports. Bajo este epígrafe se declaran las importaciones que son necesarias para que este módulo funcione correctamente. En este caso son dos: BrowserModule y AppRoutingModule. Cómo ves, son dos de las importaciones que se hacen al principio, antes del propio decorador. Lo de BrowserModule es bastante intuitivo. Si debemos importarlo arriba, para que Angular se entienda con el navegador, suena lógico que debamos contar con este módulo en el decorador. Lo de AppRoutingModule, aunque aún no estamos usando enrutamientos, también debe figurar. Acuérdate que, cuando creamos el proyecto, en este artículo, usamos el modificador --routing true. En este momento, parece un poco pretencioso, porque, como hemos dicho, de momento no estamos usando enrutamientos. Sin embargo, en la práctica, cualquier aplicación Angular usará siempre enrutamientos, por lo que debemos declararlos también en el decorador. Soy consciente de que, por ahora, suena a «tenemos que hacerlo así, por acto de fé». Cuando entremos en enrutamientos entenderás perfectamente la lógica de esto.

La clave providers la tenemos vacía y, por ahora, no vamos a entrar en qué hace, o cómo o por qué está ahí.

La clave bootstrap puede inducir un poco a confusión, al principio, porque, seguramente, cuando la has visto, has pensado en el popular framework CSS. No tiene nada que ver. Esta palabra, que puede traducirse por «arranque» o «inicio», almacena una matriz con los nombres de los componentes que tienen que cargarse cuando se inicia el módulo. Como, en este caso, sólo tenemos uno (AppComponent) ese es el que mencionamos aquí.

Finalmente, en la línea 20, vemos que el módulo se exporta como una clase (ya hemos dicho que en Angular todo son clases). El módulo se exporta para que pueda ser recogido, en este caso, por el HTML. Como el módulo importa el componente, y este se relaciona, a través de su propiedad selector, con una etiqueta del HTML, pues ya tenemos toda la estructura montada y funcionando.

¿POR QUÉ AppModule?

En el esquema que aparece en este artículo vemos que la página de entrada «habla», en primera instancia, con lo que hemos llamado el módulo principal, que es, precisamente, el AppModule del que estamos hablando. Pero ¿cómo «sabe» la aplicación que el módulo principal es precisamente ese, y no otro? Bien. Para eso tenemos que echarle un vistazo a un archivo en el directorio src del sitio, que se llama main.ts:

Si bien no vamos a entrar a detallar todo lo que hace este archivo, observa que en la línea 11 nos dice que el módulo de arranque (bootstrapModule) es, precisamente, AppModule, que se importa completo en la línea 4.

CONCLUYENDO

Sé lo que estás pensando en este momento. Para el resultado final que obtenemos, estamos trabajando con una estructura excesivamente compleja y recargada. El HTML llama a un módulo que, a su vez, tiene un montón de importaciones, y carga un componente que se relaciona con una etiqueta del HTML. El módulo, a su vez, debe ser exportado, para que el HTML lo recoja. Y encima, tenemos una importación de unos enrutamientos, que aún no sabemos como funcionan, pero que están ahí, recargando más la estructura. Y todo esto se transpila antes de enviarlo al navegador, para generar un montón de JavaScripts que son los que despliegan el contenido y lo renderizan en el navegador. Y para colmo, el resultado final se podría haber creado directamente en HTML, con una docena de líneas de código. Pues sí, tienes toda la razón. PAra la página que se crea por defecto, todo esto es matar moscas a cañonazos. Sin embargo, era necesario tener una visión global de lo que es una aplicación Angular, porque, como verás, cuando vayamos avanzando, todo esto tendrá sentido. El hecho de poder crear un código mantenible, reutilizable y escalable no es baladí, pero requiere de toda esta estructura (y más, como veremos).

En estos primeros artículos no queda otra que armarse de paciencia, y aceptar muchas cosas por pura buena voluntad. Sin embargo, cuando nuestra aplicación crezca, todo esto tendrá sentido.

   

Deja un comentario