@angular: 1. Introducción

Comienzo una serie sobre angular 2, que ya tocaba...

Willi Baumeister

archivado en: JavaScript / 12 Septiembre, 2016 / taller:

A finales del año 2014, google anunció las novedades que iba a traer la versión 2 de su conocido framework angular y se organizó un revuelo tremebundo, pues el cambio respecto a la familia 1.* era tan grande que ni siquiera iban a ser compatibles. Como tantos otros programadores, acogí la noticia con recelo y malhumor al pensar en las toneladas de código y conocimiento angularesco que iban a quedar deprecated en breve y, de hecho, dejé de escribir sobre el tema en The Bit Jazz Band. Ahora bien, en el momento de escribir estas líneas, a punto de empezar el otoño de 2016, creo que que la situación ha cambiado -o al menos mi opinión- y que vale la pena empezar a trastear con esta segunda versión, también conocida como @angular, por varias razones. A vuelapluma:

De la versión 1.5 en adelante, las actualizaciones de angular están encaminadas a equiparar las dos familias y los cambios entre unas y otras cada vez serán mayores. Si una compañía comienza a sacar sus proyectos al ritmo de las versiones nuevas que vayan saliendo, en apenas un lustro corre el riesgo de tener un reguero de tecnologías distintas, lo que en principio no es muy recomendable.

La familia 1.*, al menos las versiones conocidas hasta ahora, son incompatibles con el SEO. Los bots son todavía incapaces de renderizar correctamente el contenido de una single page application que trabaja contra un api-rest, por lo que nos ha obligado a realizar sobreesfuerzos absurdos. En teoría, con la versión 2 todo esto será menos problemático.

Va como una castaña en dispositivos poco potentes, como es el caso de los móviles, pero al parecer la 2 es hasta 5 veces más rápida.

A la que debes hacer algo que se sale del estándar -que es muy limitadico-, como una carga lazy-load o cualquier otra necesidad característica de las grandes aplicaciones, trabajar con angular 1.* se convierte en un infierno de apaños y recontra-apaños que se transforman en una deuda kármika insondable cuando tienes que preparar los test o, sencillamente, encajar tu aplicación en cualquier engranaje sobrearquitecturizado, que es el habitual de todas las grandes empresas, pá qué engañarnos.

Ionic, el framework por excelencia para hacer apps móviles, lleva por debajo angular 2.

La segunda versión viene de fábrica preparada para trabajar con los desarrollos de vanguardia del mundo front, como las progressive web apps o los web components.

En fin, podría enumerar más razones, pues de hecho lo que he visto me ha gustado mucho, pero en cualquier caso mis razones más o menos subjetivas carecen de importancia. El caso es que hace tiempo que han sacado una versión release que apenas tendrá cambios respecto a la final y @angular es ya una realidad de mercado. Es decir, tarde o temprano, según lo geeks que sean los jefes y clientes respectivos, tocará trabajar con este framework y, dado que la curva de aprendizaje es muy alta, más vale que no nos pille desprevenidos :P.

Termino esta introducción con tres apuntes más.

@angular está pensado para trabajar con typeScript. Se puede desarrollar en js vanilla o algún que otro metalenguaje diferente, como dart, pero nos estaríamos perdiendo cosas y el día a día se volvería más complicado (la documentación viene en ts, por ejemplo). Por lo tanto, si no conoces ts, te recomiendo que lo estudies un poco antes. Es sencillo y mola.

Ya conozco algún caso que otro donde se está trabajando en la versión 1.5 de angular pensando que luego será muy fácil migrar a la 2. Esto no es así. Entre ambas versiones hay un mundo de diferencias. Para el caso es como si alguien pensara convertir un wordpress en un symfony dándole a un botón. Cuestión aparte es que la versión 1.5 y es de esperar las siguientes  de esta familia sean cada vez mejores.

¿Significa lo anterior que debemos pasarnos ya mismo a @angular a partir de este instante? No. Cada proyecto tiene sus necesidades y en algunos casos puede que vaya mejor @angular, pero en otros casos quizás sea mejor la familia 1.* u otro framework o incluso ninguno. Son los programadores quienes deben usar las herramientas y no a la inversa. Es absurdo embarcarse en una tecnología solo porque está de moda.

Bueno, soltada la chapa, vamos con algo de código : ).

angular cli

El entorno de trabajo de @angular es muy complejo. Como ocurre con otros lenguajes, como java, se acabó el plug & play. Ahora debemos tener instaladas un montón de cosas de partida, tenemos que compilar el código final y hasta es recomendable que usemos algún tipo de IDE específico por su buen manejo de typeScript (el visual studio code, que por otra parte es fantástico). De hecho hay quien dice que @angular ya no es un framework, sino una plataforma. Esto tal vez pueda resultar chocante, pero, en realidad, ya está sucediendo  en la práctica, pues cualquier proyecto corporativo necesita un montón de librerías y utilidades a la que sea un poco grande: el gulp con tropecientas tasks, algún server local, el sass, algún bundleador, el jslint, el jsdoc, etcétera.

Instalar a mano todo el tinglado que necesita @angular es sencillamente suicida. Si acaso, podría valer partir de algún proyecto boilerplate con el git. Sin embargo, tenemos a nuestra disposición una herramienta formidable: angular-cli, con la que podemos preparar un entorno en un periquete.

Para trabajar sin problemas con angular-cli hay que tener instalada la versión 4 de node o superior y la 3 de npm o superior. Puedes saber qué versión tienes instalada ejecutando por consola:

node -v

npm -v

Angular CLI es un wizard, un asistente, que sirve para preparar el scaffolding básico de un proyecto, generar el esqueleto de algunas piezas, como los componentes, y lanzar algunas tareas automatizadas, como un lint, los test o los deploys de github. Equivale a tener integrado en una sola herramienta el yeoman, el gulp y demás herramientas front habituales de los proyectos empresariales.

Se instala de forma global con el npm:

npm install -g angular-cli

Y luego, desde el directorio en el que vamos a crear el proyecto, basta con escribir:

ng new nombreProyecto

Comienzan a bajarse una barbaridad de cosas y cuando termina ya solo nos queda levantar un servidor con el comando ng serve.

cd nombreProyecto

ng serve

Y ya está: en http://localhost:4200 tenemos el proyecto funcionando y un watcher que relanzará todo el tinglado en cuanto cambiemos algo. Más cómodo, imposible.

Introducción al scaffolding

Como podremos comprobar, la estructura de directorios y archivos que genera angular-cli es descomunal, decenas de miles de ficheros, pero no se tarda en familiarizarse con ella. Ya iremos viendo cada parte con calma, pero para ir entrando en materia baste con esta enumeración:

config: aquí se encuentran los archivos de configuración del proyecto, incluidos los relacionados con los test.

dist: como decía, hay que compilar el proyecto en bruto, entre otras razones porque estará en typeScript y aquí es donde se guarda la versión compilada, la que está lista para ser distribuida.

src: en este directorio, cuyo nombre viene de source (fuente), es en el que trabajaremos. Aquí van los archivos typeScript que luego compilamos.

typings: como ya deberías saber si estás leyendo esta entrada, typeScript es un metalenguaje tipado. Aquí se encuentran los archivos necesarios para que se adapten a esta peculiaridad las librerías vendor, las de terceros, como jasmine, que sirve para los tests.

tmp: como indica su nombre, aquí se guardan archivos temporales que deberían ser transparentes para el desarrollador.

node_modules: todas las herramientas que se necesitan mientras estamos trabajando, incluido el core de @angular.

Y luego en el raíz hay varios archivos de configuración general entre los que no podían faltar el .gitignore, el package.json, el .editorconfig... en fin, los de siempre y alguno más que ya iremos viendo.

Estructura básica

Vamos ahora a echarle un primer vistazo a la manera en que se engarzan las distintas piezas de arranque, un proceso donde juega un papel fundamental system.js, que es una librería para cargar archivos javaScript de la que ya comenté algo cuando traté los módulos typeScript.

Como es habitual, el punto de entrada de la aplicación se encuentra en el archivo index.html, que en tiempo de desarrollo recordemos que se encuentra en el directorio src. Si lo abrimos, de arriba abajo encontraremos los siguientes elementos:

1. El title y algunos meta tags que no necesitan mayor aclaración.

2. Un script que se carga de forma condicional si no estamos en la fase final, production, que sirve para re-lanzar el server local cuando se producen cambios.

{{#unless environment.production}}

<script src="/ember-cli-live-reload.js" type="text/javascript"></script>

{{/unless}}

3. Ya en el body, el componente principal de la aplicación.

<app-root>Loading...</app-root>

4. Un tinglado para cargar polyfills, esto es, scripts que sirven para emular cosas que aún no saben hacer los navegadores menos preparados (sí, el Explorer).

{{#each scripts.polyfills}}

<script src="{{.}}"></script>

{{/each}}

5. Y, por último, el script principal de systemjs, que es el que nos interesa comprender ahora.

<script>

// cargamos al configuración principal

System.import('system-config.js').then(function () {

/* Cargamos el resto de archivos que vamos a necesitar */

System.import('main');

}).catch(console.error.bind(console));

</script>

Este script se compone de dos partes: primero carga el archivo de configuración y luego, tras haberse cumplido la promesa, se trae, importa, lo que viene especificado en main.

La primera parte podemos encontrarla en src/system.config.ts y, aunque puede asustar a primera vista, no es complicada, solo tediosa, como todas las configuraciones de este estilo, y usando angular-cli apenas tendremos que tocar nada aquí, pero sí me interesa que nos detengamos un momento en el concepto de los «barriles» (barrels).

Un módulo no es más que un archivo que exporta parte o todo su contenido para que otros módulos puedan usarlo después de haberlo importado de forma explícita.

import {esto de aquí}

import {esto otro de allí}

...

esquema-angular

Como sería una tabarra tener que importar los cientos de piezas que conforman una aplicación @angular, decidieron que las que constituyen una entidad propia se pudieran agrupar en estos barrels, en estos contenedores, en los cuales se especifica qué debe importarse en el archivo index.ts que se encuentra en la raíz del directorio correspondiente.

Para que se entienda, en pseudo-codigo, podemos pensar en un módulo que sea una calculadora, el cual está formado a su vez por otros cuatro módulos, uno para cada operación. Si tuviéramos que importarlos todos para echar mano a la calculadora, sería muy pesado:

import {sumar}

import {restar}

...

En lugar de eso, podemos agruparlos todos en un directorio y ahí indicar en un archivo index.ts qué es exportable.

export * (todo) lo que hay en './calculadora';

De esta manera, solo tenemos que añadir la calculadora en nuestra lista de barriles y ya se encarga @angular de importar todo lo indicado en el index.ts de ese barril.

const barrels: string[] = [

'calculadora'

]

Espero que esto haya quedado más o menos claro, vamos con el segundo archivo que carga system: src/main.ts, que es donde se define el arranque, el bootstrap, de la aplicación.

Como ocurría con el inicio de la familia 1.*, en su versión básica apenas incluye unas pocas líneas, un par relacionadas con el arranque del core y luego el componente principal de la aplicación, que por defecto se denomina AppComponent, el cual se pasa como parámetro a la función bootstrap.

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

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

import { AppComponent, environment } from './app/';

if (environment.production) {

enableProdMode();

}

bootstrap(AppComponent);

Bueno, pues de momento lo dejo aquí.

|| Tags: , ,

valoración de los lectores sobre @angular: 1. Introducción

  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • 4.5 sobre 5 (4 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!

Aportar un comentario

*