Aunque signals es una de las principales novedades que trae Angular 16 en esta entrada haremos un resumen completo para que no te pierdas nada de las nuevas características de esta versión, como el renderizado del lado del servidor.

Signals

Signals es una de las principales novedades de Angular 16 ya que va a convertirse en el nuevo modelo reactivo de Angular. Aunque está todavía incluido como una versión preliminar, ya se encuentra de una manera lo suficientemente estable como para que no sufra cambios drásticos de aquí en adelante.

Lo que está bastante claro es que signals está para quedarse y que RxJS y ZoneJS van a ser el pasado de la reactividad en Angular.

¿Pero porqué?

Esta es la pregunta más evidente que hay que hacerse. RxJS y ZoneJS han sido la manera de manejar los datos de manera reactiva en Angular durante bastante tiempo, pero hay que reconocerlo era una manera bastante farragosa a la hora de manejar cosas algo más complejas que declarar una simple variable.

Además la manera que tiene ZoneJs a la hora de verificar cambios era demasiado ineficiente, sobre todo si lo comparamos con signals que es mucho más quirúrgico a la hora de buscar y realizar estos cambios.

¿Va a dejar de funcionar RxJS?

No, los dos sistemas van a ser compatibles entre sí. Y van a compaginarse en el tiempo. Vas a poder definir variables reactivas con signals y RxJS. Así como convertir signals a Observables de RxJS mediante el método toObservable.

¿Cómo declaro una signal?

En el caso de la declaración de las signals es muy sencillo, la biblioteca viene ya incluida en @angular/core , veamos un ejemplo

import {Component, signal, WritableSignal} from '@angular/core';

@Component({
  selector: 'app-signals',
  templateUrl: './signals.component.html',
  styleUrls: ['./signals.component.css']
})
export class SignalsComponent {
  /// definición del estado con sginals
  count: WritableSignal<number> = signal(0);
}

Como vemos importamos signals y nos devuelve un objeto de Writable<> del tipo de dato que le metamos como valor inicial a la función signals.

A la hora de usarla dentro de las plantillas o código deberemos de tratarla como una función que almacena el valor, veamos un ejemplo de plantilla

<div>
  <h3>Valor: {{count()}}</h3>
</div>

Este caso como siempre lo metemos dentro de los {{}} y ponemos el nombre de la señal seguido de los () para acceder a su valor

¿Y cómo cambio su valor?

En el caso de que queremos cambiar su valor disponemos de diferentes maneras:

• set: permite cambiar su valor en base a pasar un valor concreto
• update: cambia su valor en base a una lambda, por si necesitamos hacer algún cálculo antes de pasar el valor a cambiar
• mutate: cambiar el valor almacenado en el signal pero sin redeclarar de nuevo la variable, sino simplemente mutándola, lo cual mejoraría el rendimiento en variables con muchos datos

¿Y si una señal depende del cambio de otra señal?

En este caso lo que haremos es hacer uso de las señales computadas, donde podemos hacer que una señal cambie cuando otra lo haga. Veamos un ejemplo

import {Component, computed, Signal, signal, WritableSignal} from '@angular/core';

@Component({
  selector: 'app-signals',
  templateUrl: './signals.component.html',
  styleUrls: ['./signals.component.css']
})
export class SignalsComponent {

	count: WritableSignal<number> = signal(0);
	computada: Signal<number> = computed(() => this.count() +1 );
    
    // cuando se ejecute inc cambiará también computada
    inc() {
    	this.count.update(value => value + 1);
  	}
}

¿Esto es todo con las señales?

No hay un montón más de cosas, como por ejemplo, los effect, la compatibilidad con RxJS, etc.. pero como puede cambiar un poco hasta que se estabilice lo veremos un poco más adelante

Mejoras del SSR y la Hidratación

Una de las características más importantes a día de hoy es la capacidad de los frameworks de frontend a la hora de presentarse a nivel de Server Side Rendering o SSR. La manera que tenía de hacerlo Angular era poco eficiente y costosa a nivel de rendimiento.

Una manera de medir estos rendimientos es usar Core Web Vitals, que es una herramienta interna de google que mira el comportamiento de una aplicación frontnend en sus tres aspectos principales: carga, interatividad y estabilidad visual.

Esta manera de medir se irá afinando con el tiempo para ir forzando a mejorar estas características en las aplicaciones desarrolladas. Como un impulso para mejorar tu aplicación día a día. Tal como lo hizo en su momento Lighthouse.

El caso es que usando este nuevo sistema de hidratación se han visto mejoras según Google del 45% en estos Core Web Vitals en las aplicaciones en producción.

Se eliminar el parpadeo que podían provocar los cambios en las aplicaciones ante actualizaciones de la visualización de datos.

Así como puede usarse el atributo ngSkipHydration para manejar mejor esta adopción, de manera más progresiva.

Además se está planteando para Angular Universal técnicas de hidratación parcial y resumibilidad (como la que usa Qwik) para futuras versiones de Angular.

En nuestro caso os recomendamos que miréis el proyecto Analog que es una manera más sencilla de usar SSR y SSG en aplicaciones angular.

Otras Mejoras

Además de estos importantes cambios se han agregado algunas mejoras extra con la liberación de Angular 16:

• Componentes standalone: estos componentes permiten crear componentes simples hechos en angular y se han incluido en el comando ng maneras de crearlos de manera sencilla (ng generate @angular/core:standalone y ng new –standalone)
• Configuración de ZoneJS: se ha añadido una nueva opción que podemos cargar en el proceso de bootstrap de la aplicación llamada provideZoneChangeDetection que permite cambiar la manera en la que calcula los cambios
• Mejoras en las herramientas: Se ha integrado una preview de integración con esbuild que mejora el rendimiento de la compilación hasta en un 72% para el modo de desarrollo. Debes modificar el angular.json para si quieres usarlo para el build de la aplición.
• Mejoras en las pruebas de unidad con Jest y Web Test Runner: Angular está introduciendo el soporte de Jest de manera experimental y Karma dejará de usarse en favor de Web Test Runner. Este blog post tienes más información.
• Se ha agregado una funcionalidad de auto importación de componente y pipes en el servicio de lenguaje para evitar errores cuando se usan en plantillas.
• Soporte de Typescript 5.0, decoradores EcmaScript, eliminación de ngcc.
• Soporte para service workers y app shell para aplicaciones independientes
• Expansión del soporte de CSP en el CLI
• Y muchas más cosas