Angular

[2018]
Introducción a Angular
Desde su creación hace ya más de 4 años, Angular ha sido el framework
preferido por la mayoría de los desarrolladores Javascript. Este éxito ha
provocado que los desarrolladores quieran usar el framework para más y más
cosas.

De ser una plataforma para la creación de Web Apps, ha evolucionado como

motor de una enorme cantidad de proyectos del ámbito empresarial y de ahí
para aplicaciones en la Web Mobile Híbrida, llevando la tecnología al límite
de sus posibilidades.

Es el motivo por el que comenzaron a detectarse problemas en Angular 1, o

necesidades donde no se alcanzaba una solución a la altura de lo deseable.
Son las siguientes.

Javascript:

Para comenzar encontramos problemas en la creación de aplicaciones debido

al propio Javascript. Es un lenguaje con carácter dinámico, asíncrono y de
complicada depuración. Al ser tan particular resulta difícil adaptarse a él,
sobre todo para personas que están acostumbradas a manejar lenguajes más
tradicionales como Java o C#, porque muchas cosas que serían básicas en
esos lenguajes no funcionan igualmente en Javascript.

Desarrollo del lado del cliente:

Ya sabemos que con Angular te llevas al navegador mucha programación

que antes estaba del lado del servidor, comenzando por el renderizado de las
vistas. Esto hace que surjan nuevos problemas y desafíos. Uno de ellos es la
sobrecarga en el navegador, haciendo que algunas aplicaciones sean lentas
usando Angular 1 como motor.

Por otra parte tenemos un impacto negativo en la primera visita, ya que se

tiene que descargar todo el código de la aplicación (todas las páginas, todas
las vistas, todas las rutas, componentes, etc), que puede llegar a tener un peso
de megas.
TypeScript / Javascript:

Como base hemos puesto a Javascript, ya que es el inicio de los problemas

de escalabilidad del código. Ayuda poco a detectar errores y además produce
con facilidad situaciones poco deseables.Angular promueve el uso de
TypeScript a sus desarrolladores. El propio framework está desarrollado en
TypeScript, un lenguaje que agrega las posibilidades de ES6 y el futuro ES7,
además de un tipado estático y ayudas durante la escritura del código, el
refactoring, etc. pero sin alejarte del propio Javascript (ya que el código de
Javascript es código perfectamente válido en TypeScript). La sugerencia de
usar TypeScript para desarrollar en Angular es casi una imposición porque
la documentación y los generadores de código están pensados en TypeScript.
Se supone que en futuro también estarán disponibles para Javascript, pero de
momento no es así. De todos modos, para la tranquilidad de muchos,
TypeScript no agrega más necesidad de procesamiento a las aplicaciones con
Angular , ya que este lenguaje solamente lo utilizas en la etapa de desarrollo
y todo el código que se ejecuta en el navegador es al final Javascript, ya que
existe una transpilación previa.
Lazy SPA:
Ahora el inyector de dependencias de Angular no necesita que estén en
memoria todas las clases o código de todos los elementos que conforman una
aplicación. En resumen, ahora con Lazy SPA el framework puede funcionar
sin conocer todo el código de la aplicación, ofreciendo la posibilidad de
cargar más adelante aquellas piezas que no necesitan todavía.
Renderizado Universal:
Angular nació para hacer web y renderizar en HTML en el navegador, pero
ahora el renderizado universal nos permite que no solo se pueda renderizar
una vista a HTML. Gracias a ésto, alguien podría programar una aplicación
y que el renderizado se haga, por ejemplo, en otro lenguaje nativo para un
dispositivo dado.
Otra cosa que permite el renderizado universal es que se use el motor de
renderizado de Angular del lado del servidor. Es una de las novedades más
interesantes, ya que ahora podrás usar el framework para renderizar vistas
del lado del servidor, permitiendo un mejor potencial de posicionamiento en
buscadores de los contenidos de una aplicación. Esta misma novedad
también permite reducir el impacto de la primera visita, ya que podrás tener
vistas "precocinadas" en el servidor, que puedes enviar directamente al
cliente.
Data Binding Flow:
Uno de los motivos del éxito de Angular 1 fue el data binding, pero éste tenía
un coste en tiempo de procesamiento en el navegador, que si bien no
penalizaba el rendimiento en todas las aplicaciones sí era un problema en
aquellas más complejas. El flujo de datos ahora está mucho más controlado
y el desarrollador puede direccionarlo fácilmente, permitiendo optimizar las
aplicaciones. El resultado es que en Angular las aplicaciones pueden llegar
a ser hasta 5 veces más rápidas.
Componentes:
La arquitectura de una aplicación Angular ahora se realiza mediante
componentes. En este caso no se trata de una novedad de la versión , ya que
en la versión de Angular ya se introdujo el desarrollo basado en
componentes.
Sin embargo, la componetización no es algo opcional como en Angular 1.5,
sino es una obligatoriedad. Los componentes son estancos, no se comunican
con el padre a no ser que se haga explícitamente por medio de los
mecanismos disponibles, etc. Todo esto genera aplicaciones más
mantenibles, donde se encapsula mejor la funcionalidad y cuyo
funcionamiento es más previsible. Ahora se evita el acceso universal a
cualquier cosa desde cualquier parte del código, vía herencia o cosas como
el "Root Scope", que permitía en versiones tempranas de Angular modificar
cualquier cosa de la aplicación desde cualquier sitio.
Angular CLI
Dentro del ecosistema de Angular encontramos una herramienta
fundamental llamada "Angular CLI" (Command Line Interface). Es un
producto que en el momento de escribir este artículo todavía se encuentra en
fase beta, pero que ya resulta fundamental para el trabajo con el framework.

Angular CLI no es una herramienta de terceros, sino que nos la ofrece el

propio equipo de Angular. En resumen, nos facilita mucho el proceso de
inicio de cualquier aplicación con Angular, ya que en pocos minutos te
ofrece el esqueleto de archivos y carpetas que vas a necesitar, junto con una
cantidad de herramientas ya configuradas. Además, durante la etapa de
desarrollo nos ofrecerá muchas ayudas, generando el "scaffolding" de
muchos de los componentes de una aplicación. Durante la etapa de
producción o testing también nos ayudará, permitiendo preparar los archivos
que deben ser subidos al servidor, transpilar las fuentes, etc.

Node y npm
Angular CLI es una herramienta NodeJS, es decir, para poder instalarla
necesitaremos contar con NodeJS instalado en nuestro sistema operativo,
algo que podemos conseguir muy fácilmente yendo a la página de
https://nodejs.org y descargando el instalador para nuestro sistema.

Además se instala vía "npm". Por npm generalmente no te tienes que

preocupar, pues se instala al instalar NodeJS. No obstante es importante que
ambas versiones, tanto la de la plataforma Node como el gestor de paquetes
npm, se encuentren convenientemente actualizados.

Instalar Angular CLI

Esto lo conseguimos desde el terminal, lanzando el comando:

npm install -g @angular/cli

Durante el proceso de instalación se instalará el propio Angular CLI junto

con todas sus dependencias. La instalación puede tardar varios minutos
dependiendo de la velocidad de tu conexión a Internet.
Una vez instalado dispondrás del comando "ng" a partir del cual lanzarás
cualquiera de las acciones que se pueden hacer mediante la interfaz de
comandos de Angular. Puedes comenzar lanzando el comando de ayuda:

ng --help

Crear el esqueleto de una aplicación Angular

Uno de los comandos que puedes lanzar con Angular CLI es el de creación
de un nuevo proyecto Angular . Este comando se ejecuta mediante "new",
seguido del nombre del proyecto que queramos crear.

ng new mi-nuevo-proyecto-angular

Lanzado este comando se creará una carpeta igual que el nombre del
proyecto indicado y dentro de ella se generarán una serie de subcarpetas y
archivos que quizás por su número despisten a un desarrollador que se inicia
en Angular. Si es así no te preocupes porque poco a poco nos iremos
familiarizando con el código generado.

Además, como hemos dicho, se instalarán y se configurarán en el proyecto

una gran cantidad de herramientas útiles para la etapa del desarrollo front-
end. De hecho, gran cantidad de los directorios y archivos generados al crear
un nuevo proyecto son necesarios para que estas herramientas funcionen.
Entre otras cosas tendremos:

 Un servidor para servir el proyecto por HTTP

 Un sistema de live-reload, para que cuando cambiamos archivos de
la aplicación se refresque el navegador
 Herramientas para testing
 Herramientas para despliegue del proyecto
 Etc.

Una vez creado el proyecto inicial podemos entrar en la carpeta con el

comando cd.

cd mi-nuevo-proyecto-angular
Servir el proyecto desde un web server
Angular CLI lleva integrado un servidor web, lo que quiere decir que
podemos visualizar y usar el proyecto sin necesidad de cualquier otro
software. Para servir la aplicación lanzamos el comando "serve".

ng serve

Eso lanzará el servidor web y lo pondrá en marcha. Además, en el terminal

verás como salida del comando la ruta donde el servidor está funcionando.
Generalmente será algo como esto (pero te sugerimos verificar el puerto en
la salida de tu terminal):

http://localhost:4200/

Podrías modificar el puerto perfectamente si lo deseas, simplemente

indicando el puerto deseado con la opción --port:

ng serve --port 4201

Una vez hayas abierto en navegador y accedido a la URL de localhost, con

el puerto indicado, verás la pantalla de inicio de la aplicación que se acaba
de crear. Tendrá un aspecto similar al de la siguiente imagen (ten en cuenta
que esta página es solo una especie de "hola mundo" y que su aspecto puede
cambiar dependiendo de la versión de Angular que estés usando.
Archivos y carpetas con un proyecto de Angular
Comenzaremos explicando los archivos y carpetas que encuentras en una
aplicación recién creada con el Angular CLI, tal como lo encontrarás si usas
Angular 4, y en versiones más adelantadas de Angular . Más adelante en este
mismo artículo explicaremos también carpetas que aparecían en las primeras
versiones de Angular, que no son exactamente los mismos. El motivo
principal de estas diferencias es que el tooling que se usa en Angular cambió
poco después de liberar la versión , por ejemplo con la incorporación de
WebPack. Con ello también la estructura de las carpetas básicas de un
proyecto Angular cambió. No es una diferencia muy grande, y creemos que
es útil que mantengamos en el manual ambas alternativas.

Archivos sueltos:
Encontrarás varios archivos sueltos en la carpeta raíz de tu proyecto. Te
señalamos algunos importantes que debes conocer:

index.html
Este archivo es información básica del proyecto recién creado. Te puede dar
una idea inicial de qué es lo que encontrarás en estas carpetas y cómo usar el
proyecto. Complementará sin duda las explicaciones de este manual de
Angular. Encontrarás algunos comandos explicados del CLI, como "ng
serve" el cuál ya hemos tratado, para servir el proyecto. También comentará
que tienes que hacer para realizar el build, comando "ng build" y llevar a
producción una aplicación.

.angular-cli.json
Es un archivo oculto (en Linux o Mac, pues comienza por ".") en el que se
almacenan configuraciones del CLI de Angular.

package.json
Este es el archivo que resume las dependencias del proyecto, las librerías
sobre las que nos apoyamos, que se gestionan por medio de npm.

tslint.json
Este archivo sirve para configurar el linter, el programa que nos alertará
cuando tengamos problemas de estilo en el código.

.editorconfig
Este es un archivo que sirve para definir la configuración para el editor de
código que estemos utilizando. Permite centralizar la configuración, de
modo que sea común para todos los desarrolladores que vayan a trabajar en
el proyecto.

Carpeta src
Es la carpeta donde están las fuentes del proyecto. Esta carpeta es la que
usaremos para desarrollar la aplicación y donde iremos colocando
componentes y otro tipo de artefactos necesarios para poner en marcha
nuestras ideas.

Entro de "src" encuentras muchos archivos que seguramente te serán

familiares, como el index.html, que hace de raíz del proyecto. Es interesante
que abras ese archivo para comprobar cómo es la raíz de una aplicación
Angular. Te debería llamar la atención el código que encontrarás en el body:

<app-root></app-root>

Ese "app-root" es el componente raíz de la aplicación. En el desarrollo

basado en componentes es un patrón normal que toda la aplicación se
construya en un componente principal, del que colgará todo un árbol de
componentes especializados en hacer cada una de las cosas necesarias.

Otro de los detalles que encontrarás en "src" son varios archivos con
extensión ".ts". Son archivos con código TypeScript. Recuerda que en
Angular se programa usando TypeScript y que en el proceso de transpilado
de la web, realizado por WebPack, ese código pasará a traducirse a
Javascript. No hace falta que te preocupes mucho todavía, pues ya lo
estudiaremos con calma. Puedes abrir si quieres el main.ts, que es el código
de TypeScript principal de la aplicación, el punto de inicio de ejecución,
aunque ya te advertimos que este archivo prácticamente no lo tendremos que
tocar.

Dentro de "src" encontrarás también una carpeta llamada "app", que contiene
el código del componente principal, que está dividido en varios archivos. Si
abres el archivo ".html" verás el código de presentación del componente, que
es el que se muestra cuando se visualiza la aplicación recién creada.

En la carpeta "src" hay muchos otros archivos, pero no queremos aburrirte

con todos los detalles, pues los tendremos que analizar poco a poco.

Carpeta node_modules
Es la carpeta donde npm va colocando todas las dependencias del proyecto,
es decir, el código de todas las librerías o componentes que estemos usando
para basarnos en el desarrollo de una aplicación. Por ejemplo, el propio
Angular es una dependencia.

dist:

Es la versión de tu aplicación que subirás al servidor web para hacer público

el proyecto. En dist aparecerán todos los archivos que el navegador va a
necesitar y nunca código fuente en lenguajes no interpretables por él.
(Observa que no hay archivos .ts dentro de dist). Ojo, pues muy
probablemente tengas que iniciar el servidor web integrado en Angular CLI
para que aparezca la carpeta "dist" en el directorio de tu proyecto. Puedes
obtener más información sobre cómo lanzar el servidor web en el artículo de
Angular CLI.

Public:

Es donde colocas los archivos estáticos del proyecto, imágenes y cosas

similares que se conocen habitualmente como "assets". Estos archivos
también se moverán a "dist" para que estén disponibles en la aplicación una
vez subida al servidor web desde donde se va a acceder.

node_modules:

Son los archivos de las dependencias que mantenemos vía npm. Por tanto,
todas las librerías que se declaren como dependencias en el archivo
package.json deben estar descargados en esta carpeta node_modules. Esta
carpeta podría haber estado dentro de src, pero está colgando de la raíz
porque vale tanto para las pruebas, como para la aplicación cuando la estás
desarrollando.

tmp:

Es una carpeta que no tocaremos, con archivos temporales que generará

Angular CLI cuando esté haciendo cosas.

Typings:

Esto son definiciones de tipos usados por las librerías que usa un proyecto
en Angular . Estos tipos te sirven para que el editor, gracias a TypeScript,
pueda informarte con el "intellisense" en el acto de escribir código, sobre las
cosas relacionadas con esas librerías.
De momento eso es todo, esperamos que esta vista de pájaro te sirva de
utilidad para reconocer la estructura básica de un proyecto a desarrollar con
Angular . En el siguiente artículo entraremos en detalle ya sobre el código,
analizando por dentro algunas de estas carpetas y archivos generados desde
Angular CLI y realizando nuestras primeras pruebas.
Código de una aplicación Angular
Index.html
Es de sobra sabido que las aplicaciones web comienzan por un archivo
llamado index.html. Con Angular además, dado que se construyen páginas
SPA (Single Page Application) es todavía más importante el index.html,
pues en principio es el archivo que sirve para mostrar cualquier ruta de la
aplicación.

Archivo main.ts
Como hemos visto, no existe un Javascript definido o incluido en el
index.html, pero sí se agregará más adelante para que la aplicación funcione.
De hecho, si pones la aplicación en marcha con "ng serve -o" se abrirá en tu
navegador y, al ver el código fuente ejecutado podrás ver que sí hay código
Javascript, colocado antes de cerrar el BODY del index.html.

1.- imports de dependencias a librerías externas

Estos import son código de otros proyectos, dependencias de nuestra
aplicación. Están gestionados por npm y han sido declarados como
dependencias en el archivo package.json que deberías conocer. Tienen la
forma:

import { enableProdMode } from '@angular/core';

En este caso nos fijamos en '@angular/core' que es una de las librerías

dependientes de nuestra aplicación, instaladas vía npm, cuyo código está en
la carpeta "node_modules". En esa carpeta, de código de terceros, nunca
vamos a tocar nada.

2.- Imports a código de nuestro propio proyecto

También encontraremos imports a elementos que forman parte del propio
código de la aplicación y que por tanto sí podríamos tocar. Los distingues
porque tienen esta forma:

import { AppModule } from './app/app.module';

Aquí nos fijamos en la ruta del módulo que se está importando
'./app/app.module', que es relativa al propio main.ts.

En la ruta al archivo que se está importando falta el ".ts", ya que el archivo

es un TypeScript. Pero realmente no se debe colocar, puesto que ese archivo
.ts en algún momento se traducirá por un archivo .js. Para no liarse, recuerda
que los import a archivos TypeScript no se coloca la extensión.

Obviamente, para profundizar habría que entender qué es cada import de los
que se van realizando, los cuales tendremos tiempo de analizar llegado el
momento. Además de los imports, que es código que se va requiriendo, hay
un detalle que encontramos al final del fichero:

platformBrowserDynamic().bootstrapModule(AppModule)
.catch(err => console.log(err));

Esto es el bootstrap, el arranque, de la aplicación, que permite decirle a

Angular qué tiene que hacer para comenzar a dar vida a la aplicación. Al
invocar al sistema de arranque estamos indicando qué módulo (AppModule)
es el principal de la aplicación y el que tiene los componentes necesarios
para arrancar.

Al final, el bootstrap provocará que Angular lea el código del módulo y sepa
qué componentes existen en el index, para ponerlos en marcha, provocando
que la aplicación empiece a funcionar, tal como se haya programado.

Fíjate que para arrancar la aplicación se hace uso de los elementos que hemos
importado en las líneas anteriores, entre ellos platformBrowserDynamic y
AppModule.

Archivo app.module.ts
De entre todos los imports que se hace en el main.ts hay uno fundamental,
que nos sirve para tirar del hilo y ver qué es lo que está pasando por abajo,
para hacer posible que todo comience a funcionar. Se trata de app.module.ts,
que podemos considerar como el módulo principal de la aplicación. En este
fichero nos encontramos, como viene ya siendo habitual, varios imports de
elementos que vienen de otros módulos, pero hay además dos cosas que
pueden ser clave para entender el flujo de ejecución.
Import de nuestro componente raíz
En el módulo principal, app.module.ts, encontramos el import al componente
raíz de la aplicación (esa etiqueta HTML no-estándar que aparecía en el
BODY del index).

import { AppComponent } from './app.component';

Este componente es importante en este punto porque es el primero que

estamos usando y porque es el único que te ofrecen ya construido en la
aplicación básica creada con el CLI de Angular.

Al importar el componente lo que estamos obteniendo es una referencia

"AppComponent", donde estará la clase creada para implementar el
componente.

Decorador @NgModule
Esta es la primera vez que quizás estás conociendo los decoradores, algo que
viene directamente otorgado por TypeScript. Los decoradores permiten
asignar metadata a funciones, clases u otras cosas. Las funciones decoradoras
tienen un nombre y las usamos para asignar esos datos, que podrían
modificar el comportamiento de aquello que se está decorando.

El decorador completo en la versión de Angular que estamos usando (4) es

este:

@NgModule({
declarations: [
AppComponent
],
imports: [
BrowserModule
],
providers: [],
bootstrap: [AppComponent]
})
 Como ves, a la función decoradora la alimentamos con un objeto pasado por
parámetro, en el que indicamos diversos datos útiles para la clase
AppModule. Este decorador se irá editando y agregando nuevas cosas a
medida que vayamos desarrollando, por lo que nos resultará bastante familiar
a poco que comencemos a desarrollar con Angular.

En el decorador hay una propiedad llamada "bootstrap", que contiene un

array con los componentes que Angular tiene que dar vida, para conseguir
que las cosas comiencen a funcionar: bootstrap: [AppComponent]. Esto le
dice a Angular que hay en el index.html hay un componente implementado
con la clase AppComponent, que tiene que ejecutar.

Componente raíz de la aplicación

Para llegar al meollo del código, tenemos que observar, aunque todavía por
encima, el componente raíz. Lo habíamos usado en el index.html:

<app-root></app-root>

Pero echemos un vistazo al código del componente. Su ruta la puedes deducir

del import que se ha realizado en el app.module.ts, o sea
"src/app/app.component.ts".

De momento solo queremos que encuentres tu segundo decorador, con el

código siguiente.

@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
 El selector o etiqueta que implementa este componente: "app-root".
Justamente es la etiqueta extraña que había en el index.html.
 El archivo .html su template: "./app.component.html".
 Los estilos CSS que se usan en el componente: "./app.component.css"
Con lo que acabas de ver, será fácil abrir encontrar el archivo donde está el
template. ¿no? Puedes abrirlo y verás el código HTML que aparecía al poner
en marcha la aplicación. (Comando "ng serve -o" del CLI)
package.json
Vamos a comenzar por analizar este archivo, ya que muchas cosas son
declaradas inicialmente en él. Al analizar este archivo encontraremos el
origen de muchas de las librerías que usa Angular .

Como debes saber, package.json es un archivo en el que se declaran las

dependencias de una aplicación, gestionadas vía npm. Su código es un JSON
en el que se declaran varias cosas.

Inicialmente hay que ver la propiedad "dependencies". En ella encontrarás

la librería Angular separada en varios módulos. Esta es una de las
características de la nueva plataforma de desarrollo promovida por Angular
, la modularización del código. Encontrarás que una aplicación Angular
necesita ya de entrada diversos módulos como son "common", "compiler",
"core", etc.

SystemJS
Para comenzar por nuestro análisis del código, vamos a abrir el archivo
"src/index.html". Como dijimos, la carpeta src es donde se encuentran las
fuentes de tu proyecto. En ella encontramos un index.html que es la raíz de
la aplicación. Todo empieza a ejecutarse a través de este archivo.

Te llamará la atención el código siguiente:

{{#each scripts.polyfills}}<script src="{{.}}"></script>{{/each}}

Ese código hace un recorrido por una serie de librerías y las va colocando
dentro de etiquetas SCRIPT para incluir su código en la aplicación. De
momento lo que debes saber sobre este código es que por medio de él se
cargan librerías externas que necesita Angular y que hemos visto declaradas
en las "dependencies" del archivo package.json. Lo que nos interesa saber es
que así se está cargando, entre otras, la librería SystemJS.

Ahora, en el final de index.html encontrarás allí un script. Cuando llegamos

a este punto, SystemJS ya está cargado y en este Script se realiza una
inicialización de esta librería para cargar los elementos necesarios para
comenzar a trabajar:

<script>
System.import('system-config.js').then(function () {
System.import('main');
 }).catch(console.error.bind(console));
</script>
Encontramos el objeto "System", que es una variable global definida por la
librería SystemJS. Por medio del método "import" consigue cargar módulos.
Apreciarás que se está cargando inicialmente un archivo llamado "system-
config.js".

Luego vemos el método then() y catch(). Estos métodos los deberías de

reconocer, pues son pertenecientes a un patrón bien conocido por los
desarrolladores Javascript, el de promesas. El método then() se ejecutará
cuando se termine de cargar el módulo "system-config.js" y el método
catch() se ejecutaría en caso que no se haya podido cargar ese archivo.
Gracias a then(), después de haber cargado "system-config.js" entonces se
cargará "main", que enseguida veremos qué es.

En este punto te preguntarás ¿Dónde está system-config.js?. Quizás no lo

encuentres, pero veas en la misma carpeta "src" el archivo system-config.ts.
Ese es un archivo TypeScript que contiene el código de system-config.js
antes de transpilar con el TypeScript Compiler.

TypeScript es un lenguaje para el programador. Lo que usa el navegador es

Javascript. El TypeScript compiler se encargará de hacer esa conversión del
.ts a un .js.

El archivo system-config.ts generalmente no lo vas a tener que tocar, porque

Angular CLI te lo irá actualizando. Si lo abres sin duda irás reconociendo
algunas líneas, cosas que necesitará SystemJS. No vamos a entrar ahora en
el detalle, de momento quédate con que es código generado.

Por su parte la referencia a "main" que teníamos antes en los import del
index.html System.import('main'), es un import. No le ponen ni siquiera la
extensión del archivo "main.js" y esto es porque "main" es un alias declarado
en el system-config.ts. Fíjate en el código del archivo, en estas líneas:

// Apply the CLI SystemJS configuration.

System.config({
map: {
'@angular': 'vendor/@angular',
'rxjs': 'vendor/rxjs',
'main': 'main.js'
},
packages: cliSystemConfigPackages
});
El objeto "map" tiene una lista de alias y archivos que se asocian. Siendo que
"main" corresponde con "main.js". Nuevamente, no encontrarás un "main.js"
entre los archivos del proyecto, en la carpeta "src", porque lo que tendremos
es un main.ts que luego se convertirá en el main.js. Ahora puedes abrir
main.js. Verás que su código nuevamente hace uso de SystemJS, realizando
diversos imports. Estos imports son como los que conoces en ECMAscript 6
y básicamente lo que te traen son objetos de diversas librerías.

Encontrarás este código en main.js, o algo similar:

import { bootstrap } from '@angular/platform-browser-dynamic';

import { enableProdMode } from '@angular/core';
import { TestAngularAppComponent, environment } from './app/';

Por ejemplo, estás diciéndole que importe el objeto "bootstrap" de la librería

"@angular/platform-browser-dynamic". Esa librería está declarada dentro
de "system-config.ts" .

Luego verás otras líneas, que es el bootstrap, o inicio de la aplicación

Angular. No vamos a entrar en detalle, pero es lo equivalente al "ng-app"
que colocabas antes en el código HTML de tu index. Esto, o algo parecido
ya se podía hacer con Angular 1 y se conocía como el arranque manual de
Angular.

Componente principal de una aplicación

Seguimos analizando index.html y encontramos en el código, en el cuerpo
(BODY) una etiqueta que llamará la atención porque no es del HTML
tradicional. Es el uso de un componente y su código será algo como:

<mi-nombre-proyecto-app>Loading...</mi-nombre-proyecto-app>
Ese es el componente raíz de nuestra aplicación Angular . Hablaremos de
componentes con detalle más adelante. De momento para lo que te interesa
a ti, que es reconocer el flujo de ejecución básico, hay que decir que su
código está en la carpeta "src/app".

En esa carpeta encontrarás varios archivos del componente que analizaremos

con calma más adelante. De momento verás un archivo ".html" que contiene
la vista de este componente y un archivo ".css" que contiene el CSS. Si tu
componente se llamaba "mi-nombre-proyecto-app", estos archivos se
llamarán "mi-nombre-proyecto.component.html" y " mi-nombre-
proyecto.component.css". Para terminar esta primera zambullida al código
te recomendamos editar esos archivos. Es código HTML y CSS plano, por
lo que no tendrás ningún problema en colocar cualquier cosa, siempre que
sea HTML y CSS correcto, claro está.

Para quien use Angular 1 ya reconocerá una estructura como esta:

{{title}}
Es una expresión que Angular sustituirá por un dato que se declara en el
archivo .ts del componente. De momento lo dejamos ahí.

Ejecutar el proyecto
Para comprobar si tus cambios en el HTML del componente han tenido
efecto puedes probar el proyecto. La ejecución de esta aplicación ya la vimos
en el artículo de Angular CLI, por lo que no necesitarás mayores
explicaciones. De todos modos, como resumen, sigue los pasos:

Desde la raíz del proyecto, con el terminal, ejecutamos el comando:

ng serve
Luego nos dirigimos a la URL que nos indican como resultado de la
ejecución del comando, que será algo como:

http://localhost:4200/
Entonces deberías ver la página funcionando en tu navegador, con el HTML
editado tal como lo has dejado en el archivo .html del componente principal.
En futuros artículos profundizaremos sobre muchos de los puntos relatados
aquí. De momento creemos que esta introducción al código debe aclararte
muchas cosas, o plantearte muchas otras dudas.
 Entendiendo el código del componente
El código de este componente está generado de antemano en la carpeta
"src/app". Allí encontrarás varios ficheros que forman el componente
completo, separados por el tipo de código que colocarás en ellos.

 app.component.html: Equivale a lo que conocemos por "vista" en la

arquitectura MVC.
 app.component.css: Permite colocar estilos al contenido, siendo que éstos
están encapsulados en este componente y no salen afuera.
 app.component.ts: Es el corazón de nuestro componente, un archivo con
código TypeScript, que se traducirá a Javascript antes de entregarse al
navegador. Por si te sirve la comparación, sería el equivalente al
controlador en el MVC, aunque en Angular desapareció el controlador tal
como se conocía en AngularJS (1.x).
 app.component.spec.ts: Un archivo TypeScript destinado a tareas de
testing de componentes.
Vista del componente: app.component.html
En este archivo encontrarás diverso contenido, expresado en código HTML.
Como hemos dicho, este archivo es lo que sería la vista y admite toda clase
de código HTML, con etiquetas estándar y el uso de otros componentes.
Además podemos colocar expresiones, declarar bindig entre componentes,
eventos, etc.

Los que no conozcan de todo eso que estamos hablando (expresiones,

eventos, binding, etc.) no se preocupen, porque lo veremos más adelante.

Dentro del HTML de la vista, entre otras cosas, encontrarás:

{{title}}
Eso es una expresión. Angular lo sustiruirá por el contenido de una variable
"title" antes de mostrarlo al cliente. Esa variable se define en la declaración
del componente.

Declaración del componente: app.component.ts

Este es el archivo con el script necesario para la creación del componente,
creado mediante código TypeScript. Es como el controlador en el patrón
MVC, solo que en Angular no se le llama controlador, o "controller". Ahora
es una clase normal, de programación orientada a objetos, como las que nos
ofrece ES6, sólo que aquí es TypeScript quien nos la facilita.
 Si abres el archivo app.component.ts encontrarás varias cosas.

 El import de "component" dentro de @angular/core

 Una función decoradora que hace la acción de registrar el componente
 La clase que hace las veces de controlador
La función decoradora observarás que declara diversas cuestiones.

@Component({
moduleId: module.id,
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
Una de ellas es el "selector" de este componente, o el nombre de la etiqueta
que se usará cuando se desee representar. Mediante la propiedad
"templateUrl" asociamos un archivo .html que se usará como vista del
componente. Por último se define su estilo mediante la propiedad
"styleUrls", indicando a un array de todas las hojas de estilo que deseemos.

En la clase del componente, que se debe colocar con un export para que se
conozca fuera de este módulo, es la parte que representa el controlador en
una arquitectura MVC. En ella colocaremos todas las propiedades y métodos
que se deseen usar desde la vista.

export class AppComponent {

title = 'proyecto-angular works!';
}
Esas propiedades representan el modelo de datos y se podrán usar
expresiones en las vistas para poder visualizarlas.

Observa además que el nombre de la clase de este componente tiene una

forma especial. Mientras que el nombre de la etiqueta del componente (su
"selector") tiene las palabras separadas por guiones, aquí tenemos una
notación "PascalCase" típica de las clases (class de programación orientada
a objetos). Esto es una constante: En el HTML que no se reconocen
mayúsculas y minúsculas se separan las palabras por guiones por guiones,
colocando todo en minúscula. Por su parte, los mismos nombres en
Javascript se escriben con "PascalCase", todo junto y con la primera letra de
cada palabra en mayúscula.
Alterando el código de nuestro componente
Para terminar este artículo vamos a hacer unos pequeños cambios en el
código del componente para comprobar si la magia de Angular está
funcionando. Algo muy sencillo sería comenzar por crear una nueva
propiedad en la clase del componente. Pero vamos además a colocar un
método para poder usarlo también desde la vista.

export class ProyectoAngularAppComponent {

title = 'Manual de Angular de DesarrolloWeb.com';
visible = false;
decirAdios() {
this.visible = true;
}
}

Esta clase "class" se escribe en un archivo TypeScript, pero realmente lo que

vemos es casi todo Javascript válido en ES6 y ES7. TypeScript entiende todo
ES6 e incluso algunas cosas de ES7.
Ahora vamos a ver el código HTML que podría tener nuestra vista.

<h1>
{{title}}
</h1>
<p [hidden]="!visible">
Adiós
</p>
<button (click)="decirAdios()">Decir adiós</button>
En este HTML hemos incluido más cosas de las que puedes usar desde
Angular. Habíamos mencionado la expresión, entre llaves dobles, que
permite volcar el contenido de propiedades del componente. También
encuentras el uso de una propiedad de un elemento, como es "hidden", entre
corchetes (nuevo en Angular ). Además de la declaración de un evento
"click" que se coloca entre parénteis.