Hay una pregunta que me persigue a todas horas vaya a donde vaya… ¿Qué es eso de Angular 4?

La pregunta adopta varios matices: ¿Que pasará con Ionic 2 ahora que ha salido Angular 4? ¿Tengo que elegir entre aprender Angular 2 o 4? …

 
Quédate tranquilo.

 
En serio.

 
No sufras más.

 
Angular 4 no es un cambio radical como pasó tras AngularJS. Angular 4 es simplemente Angular. Igual que Angular 2. Deja que te lo explique…

Angular adopta SEMVER

El motivo detrás de toda esta discusión, es la adopción por parte de Angular de lo que se conoce como Semantic Versioning (o SEMVER).

¿Que es el Semantic Versioning?

El sistema SEMVER es un conjunto de reglas para proporcionar un significado claro y definido a las versiones de proyecto de software.

El sistema SEMVER se compone de 3 números, siguiendo la estructura X.Y.Z, donde:

• X se denomina Major: indica cambios rupturistas
• Y se denomina Minor: indica cambios compatibles con la versión anterior
• Z se denomina Patch: indica resoluciones de bugs (compatibles)

Básicamente, cuando se arregla un bug se incrementa el patch, cuando se introduce una mejora se incrementa el minor y cuando se introducen cambios que no son compatibles con la versión anterior, se incrementa el major.

Así de fácil. De este modo cualquier developer sabe qué esperar ante una actualización de su librería favorita.

Si sale una actualización donde el major se ha incrementado, sabes que tendrás que ensuciarte las manos con el código para pasar una app existente a la nueva versión.

¿Que tiene esto que ver con Angular?

Cuando en 2016 se publicó la versión estable de Angular 2, decidieron adoptar el sistema SEMVER. De este modo, Angular 2 pasó a llamarse Angular (a secas) en su versión 2.0.0.

¿Entonces… hay cambios rupturistas en Angular 4?

¿rupturistas?

¿Cómo de rupturistas?

Esta claro que todo proyecto de SW que quiera avanzar a buena velocidad, en algún momento introducirá cambios que por desgracia no serán compatibles con versiones anteriores, forzándote a tocar tu código para actualizarte.

Sin embargo, no estamos hablando de cambios críticos sino menores. Por ejemplo, el mero hecho de actualizar la versión de TypeScript que usa Angular de la v1.8 actual a la v2.2, implicará cambios no compatibles.

Angular 4 es solo la mejora a medio plazo del Angular 2 actual, en la que se ha ido trabajando de forma paralela sin aplicar restricciones de compatibilidad.

Como verás en el resumen de cambios es prácticamente idéntico.

¿Por qué Angular 4?

Buena pregunta. Lo lógico sería que la siguiente versión sea la Angular 3 ¿no?

El problema es que las librerías core de Angular están en un único repositorio de GitHub (github.com/angular/angular) y todas ellas usan SEMVER pero se distribuyen como paquetes separados de NPM.

Pues resulta, que mientras el resto de paquetes de Angular 2.4.0 están justamente en esa versión (@angular/core, @angular/http, etc) el paquete @angular/router está en su versión 3.4.0 debido a cambios no retrocompatibles que se hicieron en su momento a nivel interno.

El equipo de Angular pensó que era mejor pasar directamente a la versión 4 y así volver a tener todos los paquetes de Angular alineados a la misma versión, haciendo más sencillo un futuro mantenimiento de las librerías.

Entonces…¿lo llamo Angular, o qué?

A la hora de citar Angular, deberías usar:

• AngularJS: Si te refieres a Angular 1.x o anterior
• Angular: Si te refieres a Angular 2.x o posterior, de forma genérica
• El número de versión (Angular 2.4, 4.0, etc): Si te refieres a la release que contiene una característica concreta
• La versión SEMVER completa (Angular 2.2.3): Si quieres indicar la versión que contiene un bug concreto .

En mis artículos intento seguir esta nomenclatura, así que ya sabes, cuando digo AngularJS me refiero a la versión 1 de Angular, mientras que cuando digo Angular me refiero en general a la versión más reciente, la linea que siguen Angular 2 y 4.

Novedades de Angular 4.0

Los principales cambios que incorpora Angular 4 son:

Sintaxis if…else dentro de los templates

En Angular 4 la directiva estructural *ngIf acepta un parámetro else asociado a un ng-template que se mostrará en caso de no cumplirse la condición del if.

<!-- if/else syntax example -->
<ng-template #forbidden>
  <p>Sorry, you are not allowed to read this content</p>
</ng-template>

<p *ngIf="isAuth; else forbidden;">
  <p>Some secret content</p>
</p>

Módulo de animación separado

Este, por ejemplo, es un cambio que SI rompe con la compatibilidad.

• En la versión anterior, la librería de animaciones de Angular pertenecía al paquete @angular/core.
• En Angular 4 en cambio, las animaciones se han movido a su propio módulo: @angular/animations.

La finalidad de este cambio es reducir el tamaño de tu app en caso de que no uses su sistema de animaciones. La contrapartida, no obstante, es que si te actualizas a Angular 4 y sí hacías uso del módulo de animaciones, tendrás que actualizar 1 línea de código para que funcione.

Uso de StrictNullChecks de TypeScript

Javascript diferencia entre los tipos null y undefined, pero con la versión anterior de TypeScript no era posible darle esos valores a una variable de otro tipo.

En la nueva versión, TypeScript permite definir explícitamente cuales de estos tipos que puede tener una variable.

//strict null checks example
let a = String | null; // puede ser null
let b = Number | undefined; // puede ser undefined
let c = Array<Number> | null | undefined; // puede ser null o undefined

Integración de Angular Universal como módulo de Angular

Angular Universal es la solución que proporciona Angular para el Server-side rendering, es decir, para servir tu contenido ya renderizado desde el servidor (con el objetivo de mejorar tu SEO, servir más rápido la página inicial, etc).

Hasta ahora el paquete Angular Universal era algo completamente externo a Angular, pero a partir de Angular 4 ha pasado a convertirse en un módulo propio de Angular, accesible en @angular/platform-server.

Mejoras de rendimiento gracias a FESM

La nueva versión de Angular incluye versiones planas de sus módulos en el formato de Módulos de ECMAScript (Flattened ECMAScript Modules, o FESM por sus siglas).

Esto te puede sonar a chino y lo cierto es que nunca te vas a pelear con ello directamente. No obstante, este cambio implica una mejora considerable en el rendimiento de la app ya que facilita las tareas de tree-shaking reduciendo tu bundle de código, y agilizando la compilación y carga en el navegador.

Roadmap previsto de Angular

En el proyecto en Github de Angular hay una planificación prevista para las próximas releases, tanto a corto como a medio plazo.

Angular plantea una Major Release cada 6 meses, con un alto nivel de compatibilidad con la versión anterior.

Si le das un vistazo, verás que el 22 de Marzo de 2017 es la fecha en la que tenían previsto publicar la versión estable de Angular v4.0.0, que debería ser equivalente (salvo las mejoras introducidas) a la versión 2.4.12.

Además, puedes ver también como plantean una Major Release cada 6 meses, con un alto nivel de compatibilidad con la versión anterior.

De este modo añadirán nuevas características a Angular no condicionadas al legacy de código, pero a la vez garantizan que la migración de una versión a la siguiente sea un proceso tan simple que la mayoría de desarrolladores lo aceptarán sin problemas.

Conclusiones

Espero que esto te haya servidor para perder el miedo a Angular 4 y tener más claro, de ahora en adelante, como funciona la nomenclatura de Angular que se adoptó en 2016.

Personalmente, creo que el paso a SEMVER es para bien, por que ayuda a los desarrolladores a entender en qué medida puede afectar a su código una actualización. Además, demuestra el interés que tienen Google y la comunidad Angular en convertir esta plataforma en un proyecto sostenible a largo plazo.

Gracias por leer esto y si te ha gustado… ¡recuerda compartirlo! 🙂