Primeros pasos en Angular 5 (III)

Aunque ya hemos visto como arrancar una aplicación en Angular, y tenemos una cierta idea de cómo la página principal, o entry point, llama a un «bloque de contenidos» que sabemos que se llama, genéricamente, componente, aún no conocemos ciertos aspectos relevantes de esta introducción, que vamos a tratar de dilucidar aquí.

Vamos a ver cómo se carga nuestra aplicación en el navegador, como determinar la forma en que se carga, y algunos otros puntos que consideramos básicos para luego poder seguir avanzando, como es la adición y uso de librerías de terceros.

La mayor parte de este artículo se centrará en detalles que forman parte del archivo package.json. Ya lo vimos muy por encima en un artículo anterior, y ahora vamos a seguir ahondando.

EL ARRANQUE DE LA APLICACIÓN

Como ya sabes, hemos puesto en marcha un servidor que escucha por el puerto 4200. Lo hicimos al teclear, en la terminal de mandatos, la instrucción:

npm start

Lo primero que vamos a hacer es detener ese servidor, con las teclas Ctrl-C. Se nos muestra la pregunta ¿Desea terminar el trabajo por lotes (S/N)? Pulsamos S y la tecla INTRO y ya tenemos detenido el servidor, y en la línea de mandatos aparece el prompt a la espera de nuevas instrucciones. Si ahora intentas recargar la página (o cargarla de cero, si hubieras cerrado tu navegador), no te funcionaría, porque ya no hay nada que haga que Angular escuche por puerto alguno.

Abre con tu editor el archivo package.json y fíjate en la línea 7 (si no has modificado este fichero, y está como se instaló originalmente). Verás lo siguiente:

"start": "ng serve",

Eso sirve para que, cuando npm ejecuta el comando start, lo que hace es llamar a ng serve. Ahora vamos a modificar esa línea, con tres pequeños cambios:

"start": "ng serve --aot -o --port 4500",

Esto hace que el servidor de Angular arranque, con unas opciones algo diferentes a las que tiene por defecto:

La opción --aot. Cuando se inicia el servidor, o se modifica el código con el servidor iniciado, se produce una transpilación de los typescripts a JavaScripts. Eso ya lo sabemos. La cuestión es que, por defecto, esa transpilación se realiza en el modo que se conoce como JiT (Just in Time). Básicamente, se trata de que la transpilación se produce en el cliente, a partir de los typescripts enviador por el servidor. Con la opción --aot se produce una compilación diferente, llamada Ahead of Time. Esto significa que la transpilación se produce en el servidor, y al cliente le llegan los códigos finales. Esta forma de hacer las cosas optimiza el tiempo de carga y renderización, en aplicaciones SPA, o con lazy load (ya veremos estos conceptos), etc. Por lo tanto, a partir de ahora usaremos ya siempre esta opción, salvo casos concretos en los que, durante el desarrollo, nos convenga desactivarla. Si quieres saber más sobre estos modos de transpilación te recomiendo, como no, echarle vistazo al tema en la página oficial de Angular (https://angular.io/guide/aot-compiler).

La opción --open (abreviadamente, -o). Hace que, cuando se arranque el servidor, se abra automáticamente el navegador por defecto y se cargue la aplicación Angular, sin que tengamos que llamarla específicamente, como habíamos hecho hasta ahora.

La opción --port. Seguida, como ves, de un número, hace que el servidor escuche a Angular por un puerto específico (por defecto, es el 4200). En la mayor parte de los casos, no necesitaremos esto, pero si tu puerto 4200 está escuchando a otro servicio (lo que puede pasar si estás trabajando con varias herramientas web simultáneamente), puedes usar un puerto de tu elección para cargar tus aplicaciones Angular.

El comando ng serve puede usar otros parámetros. La lista la tienes en https://github.com/angular/angular-cli/wiki/serve.

A partir de ahora, en este proyecto, y otros con los que trabajemos en el futuro, pondremos, como norma, el mandato ng serve así:

"start": "ng serve --aot -o",

LO QUE SE CARGA EN EL NAVEGADOR

Este es otro punto que debemos conocer para entender mejor como funciona una aplicación Angular. Arranca el servidor como ya sabes, escribiendo en la terminal de VSC la instrucción npm start. Tras unos segundos, y si has configurado ng serve en package.json como te he comentado en el apartado anterior, se abre tu navegador por defecto y se carga la aplicación que ya tenemos, con su rótulo, la imagen con el logo de Angular, y tres enlaces. Ahora, haz clic con el botón derecho sobre una zona en blanco de la página, y pulsa la opción Ver código fuente de la página (en Chrome se llama así; si tu navegador es otro, la opción puede llamarse de otro modo, pero púlsala igual). Verás algo como lo siguiente:

Como ves, no hay código HTML que genere los contenidos que ves. Tenemos, eso sí, la etiqueta <pr-root></pr-root>, de la que ya hemos hablado, y que sabemos que el navegador, por defecto, no entiende ni interpreta de ningún modo. Todo esto está en el index.html de nuestro proyecto.

Y también vemos que hay unas llamadas a unos archivos JavaScript. Estos son el resultado de haberse transpilado los TypeScripts correspondientes, y son los que colocan el contenido de la página, de forma dinámica (por eso no se ve en el código fuente), entre <pr-root> y </pr-root>. Para ver que esto es así, abre, si no la tienes ya, la cosola del navegador, y busca la pestaña Elements (o equivalente en tu navegador). Observarás el código completo, como si lo hubieras escrito, directamente, en el HTML.

AGREGANDO LIBRERÍAS DE TERCEROS

En gran catidad de ocasiones en las que debemos contar con librerías de terceros en nuestra aplicación. La gran mayoría de las librerías que podamos necesitar en un framework JavaScript como es Angular pueden instalarse con npm o bower indistintamente. Algunas específicamente deberán ser instaladas con npm o con bower sólamente. Por eso tenemos instalados los dos gestores de dependencias.

También debes entender que, dado que Angular es un framework para frontend, lo normal es que la mayor parte de librerías que tengas que instalar deban ser dependencias disponibles tanto para desarrollo como para produccón, por lo que deberán estar referenciadas en el apartado dependencies de package.json, no en devDependencies. Teclea las siguientes instrucciones, a modo de ejemplo, en la terminal de VSC:

npm install --save jquery
npm install --save moment
npm install --save milligram
npm install --save bootstrap

Ahora observa como ha cambiado el apartado dependencies de package.json:

En las líneas resaltadas ves cómo se han añadido las correspondientes dependencias.

Sin embargo, las nuevas librerías no están, aún, disponibles para usar en nuestra aplicación Angular. Veamos que ha sucedido. Las librerías se han copiado en directorios específicos, que se han creado automáticamente al efecto, dentro de la estructura de la carpeta node_modules. Esta es una carpeta creada y gestionada por el CLI de Angular, en la que nosotros no debemos de tocar nada «a mano». El gestor de paquetes npm ha instalado las librerías de terceros, precisamente, ahí, por esa razón: porque es algo que nosotros no vamos a manipular. Sin embargo, es necesario referenciarlas en el archivo .angular-cli.json, situado en la raíz de nuestro proyecto, para que estén disponibles para el proyecto. Si abres este archivo con tu editor te encontrarás con lo siguiente:

Observa las líneas resaltadas, donde se detallan los archivos de estilos (clave styles) y JavaScript (clave scripts), que deben formar parte de la aplicación. Como las librerías que hemos añadido en este ejemplo están constituidas por archivos de estos tipos, es en estas claves donde deberemos referenciarlas. Estas referencias deberán apuntar a las ubicaciones donde se han alojado las librerías, y debemos crearlas manualmente. Es de las pocas cosas que Angular no hace por nosotros. En concreto, en este ejemplo, las claves mencionadas deberían quedar así:

Más adelante volveremos sobre este tema.

CONLUYENDO

En este artículo hemos aprendido a modificar el arranque de la aplicación Angular, a identificar donde están y donde no están los elementos en el código que renderiza el navegador, y a instalar librerías de terceros. Ya es hora de que aprendamos más sobre la anatomía de aplicaciones Angular en el próximo artículo.

   

Deja un comentario