DEV Community: akotech

Angular 17 - Nuevo Control de Flujo Integrado.

akotech — Mon, 20 May 2024 12:14:27 +0000

Una de las principales novedades introducidas en Angular 17 es la nueva sintaxis de Control de Flujo integrada en los templates, que viene a hacer innecesario el uso de directivas estructurales como *ngIf, *ngFor, o *ngSwitch.

Esta nueva sintaxis nos ofrece tres bloques principales de los cuales hablaremos a lo largo de este artículo:

@‍if
@‍switch
@‍for

Si lo prefieres, el contenido de este artículo también lo tienes
en formato video aquí.

@‍if (condition)

El bloque @if, como podemos intuir, nos permitirá renderizar una parte del template cuando se cumpla una determinada condición.

Su sintaxis es muy similar a la que encontramos en JavaScript:

Indicamos la condición a chequear entre paréntesis.
Y entre un par de llaves incluimos el contenido a renderizar cuando dicha condición se cumpla.

@if (price > 100) {
    <p>El precio es mayor que 100</p>
}

Para los casos en los que necesitemos exportar el resultado de la condición, como por ejemplo sucede a la hora de usar la pipe async, podremos seguir utilizando as <nombre_variable_local>, del mismo modo que hacíamos en el *ngIf.

@if (user$ | async; as user) {
  <p>{{ user.name }}</p>
  <p>{{ user.email }}</p>
}

‍

@‍else

Una de las mejorías más significativas de esta nueva sintaxis en comparación con el uso de *ngIf es a la hora de definir un contenido alternativo cuando la condición no se cumpla.

Y es que ahora simplemente tendremos que añadir un bloque @else con dicho contenido alternativo.

@if (price > 100) {
  <p>El precio es mayor que 100</p>
} @else {
  <p>El precio NO es mayor que 100</p>
}

‍

@‍else if

Y eso no es todo, ya que ahora tenemos incluso la opción de añadir bloques @else if intermedios en el caso de necesitar condiciones adicionales.

@if (price > 100) {
  <p>El precio es mayor que 100</p>
} @else if (price < 100) {
  <p>El precio es menor que 100</p>
} @else {
  <p>El precio es 100</p>
}

@‍switch (expression)

Y esto de las múltiples condiciones nos da pie para hablar del siguiente bloque, que es el @switch. Este bloque nos permite evaluar una expresión y en función del resultado de la misma, renderizar unos elementos u otros.

Por ejemplo imaginemos que tenemos un componente con una propiedad media que puede ser del tipo Photo | Video | Audio

interface Photo { type: 'photo'; ...}
interface Video { type: 'video'; ...}
interface Audio { type: 'audio'; ...}

@Component({...})
export class SomeComponent {
  media!: Photo | Video | Audio;
}

A la hora de renderizar esta propiedad en el template, podríamos utilizar una combinación de bloques @if, @else if y @else, para cubrir las 3 diferentes posibilidades.

@if (media.type === "photo") {
  <img [src]="media.url" />
} @else if (media.type === "video") {
  <video>
    <source [src]="media.url" />
  </video>
} @else {
  <audio>
    <source [src]="media.url" />
  </audio>
}

Pero para estos casos concretos en los que una misma expresión puede evaluar a una serie de diferentes valores una opción más sencilla y expresiva es utilizar un @switch.

Su uso es muy sencillo:

Añadimos un bloque @switch indicando entre paréntesis la expresión a evaluar (en este caso media.type).
Y entre sus llaves añadimos un bloque @case para cada uno de los posibles valores que incluya el contenido a mostrar en cada uno de los casos.

@switch (media.type) {
  @case ("photo") {
    <img [src]="media.url" />
  }
  @case ("video") {
    <video>
      <source [src]="media.url" />
    </video>
  }
  @case ("audio") {
    <audio>
      <source [src]="media.url" />
    </audio>
  }
}

‍

@‍default

Si el resultado de la expresión del @switch no coincidiera con ninguno de los @case definidos, por supuesto, no se renderizaría nada. Pero si preferimos mostrar un contenido alternativo en el caso de que esto suceda, tenemos la opción de añadir un bloque @default con ese contenido por defecto.

@switch (media.type) {
  @case ("photo") {
    <img [src]="media.url" />
  }

  ...

  @default {
    <p>Tipo no reconocido</p>
  }
}

A diferencia de lo que ocurre en las sentencias switch-case de JavaScript, aquí, al menos de momento, no hay lo que se conoce como fall-through. Por lo que no necesitaremos hacer break en los diferentes cases. Ni tampoco tenemos la opción de definir dos o más @case para un mismo bloque.

‍

Mejor Inferencia de Tipos

Este nuevo formato nos ofrece una ventaja en comparación con el antiguo *ngSwitch. Y es que ahora los bloques @case son conscientes del contexto.

// A nivel del Switch media es del tipo 'Photo | Video | Audio' 
@switch (media.type) {
  @case ("photo") {
    // Dentro de este @case es capaz de inferir 
    // que media solo puede ser del tipo 'Photo'
    <img [src]="media.url" />
  }
  ...
}

@‍for (item of iterable; track expression)

El bloque @for es esencial a la hora de renderizar el contenido de listas, ya que nos permite repetir una parte del template para cada uno de los elementos de las mismas.

<ul>
  @for (user of users; track user.id) {
      // este contenido se repetirá para usuario que
      // que contenga la propiedad users.
    <li>{{ user.name }}</li> 
  }
</ul>

‍

track

En el @for tendremos que proporcionar obligatoriamente una expresión de trackeo, para que este pueda identificar cada uno de los elementos del listado entre actualizaciones, para así, realizar las mínimas operaciones a la hora de actualizar el DOM.

Por ejemplo:

Si tenemos una lista de primitivas donde cada valor es único, podemos usar el propio elemento como identificador.
```
@for (month of months; track month) 
```
Si tenemos una lista de entidades, la propiedad identificadora de las mismas.
```
@for (user of users; track user.id)
```
Si estamos refactorizando una aplicación antigua queremos reutilizar un método trackBy previamente definido, podemos llamar a este pasando el índice y elemento de cada iteración.
```
@for (user of users; track trackByUserId($index, user))
```
Y si no tenemos una manera clara de identificar cada elemento, podemos revertir por defecto el índice de la iteración. (Usando esta opción las animaciones de los elementos podrían no funcionar correctamente)
```
@for(value of numbers; track $index)
```

‍

Propiedades del bucle

Cómo vemos en los últimos ejemplos estamos usando el índice directamente sin tener que exportarlo a una variable manualmente. Y es que ahora todas las propiedades internas del bucle se exportan automáticamente a una variable con el nombre de las mismas precedidas por el símbolo del dólar $index, $count, $even, $odd, $first, $last.

Eso sí para los casos en los que tengamos bucles anidados tenemos la opción de seguir exportando dichas propiedades a variables con nombres alternativos para evitar conflictos de nombres.

// exportamos el índice como userIndex en el loop externo
@for (user of users; track user.id; let userIndex = $index) { 
  ...
  @for (address of user.addresses; track address) {
    <li>
       {{ address }}
       // usamos userIndex en el loop anidado
       <button (click)="deleteAddress(userIndex, $index)">delete</button> 
    </li>
  }
  ... 
}

‍

@‍empty

La nueva sintaxis incluye además un nuevo bloque @empty que nos permite definir directamente un contenido alternativo para los casos en los que el listado este vacío.

<ul>
  @for (user of users; track user.id) {
    <li>{{ user.name }}</li>
  } @empty {
    <li>No hay usuarios.</li>
  }
</ul>

Migración automática

Si necesitas refactorizar una aplicación antigua a este nuevo procedimiento, no te preocupes porque el equipo de Angular ha incluido una migración para realizar este proceso de manera automática.

Ejecutando el comando:

ng generate @angular/core:control-flow

La cli transformará todas las directivas estructurales de tu aplicación al nuevo formato.

Y aunque esta transformación no es perfecta ya que por ejemplo no es capaz de inferir cuando utilizar los nuevos bloques @empty o @else if, si te quitará la mayor parte del trabajo de refactorización.

Conclusión

Esta nueva sintaxis del Control de Flujo nos ofrece a los desarrolladores un procedimiento mucho más intuitivo y simple a la hora de definir el contenido condicional y repetitivo de nuestras aplicaciones.

Si deseas apoyar la creación de más contenido de este tipo, puedes hacerlo a través nuestro Paypal

YouTube · X · GitHub

@Input ({ transform })

akotech — Fri, 26 Apr 2024 08:31:39 +0000

A partir de Angular 16.1 tenemos una nueva opción transform en los @Input, que nos permite transformar los valores recibidos antes de que estos sean asignados en la propiedad.

@Input({ transform: (value: any) => SomeType) }) aProperty: SomeType

En este artículo hablaremos de su funcionamiento y veremos cual es la problemática principal que viene a solucionar.

Si lo prefieres, el contenido de este artículo también puedes encontrarlo en formato video aquí.

`@Input` que no son `string`

Los inputs son una pieza fundamental ya que nos permiten pasar información desde un componente padre a un hijo.

Pero tienen una limitación y es que si declaramos el input con un tipo distinto a string estamos obligados a usar el formato del vínculo de propiedades.

Si tomamos como ejemplo un input disabled del tipo boolean

@Input() disabled: boolean;

Lo ideal sería poder asignar este input utilizando cualquiera de los siguientes formatos:

//❌ Error: '""' no se puede asignar a boolean
<ako-child disabled /> 

//❌ Error: '"disabled"' no se puede asignar a boolean
<ako-child disabled="disabled" />

<ako-child [disabled]="true" /> // ✅
<ako-child [disabled]="false" /> // ✅

Pero si intentamos asignarlo usando el atributo directamente, como se pasan siempre como string, nos dará error.

La solución naíf

En principio, la solución parece sencilla. Simplemente añadimos esos dos string literales al tipo y problema solucionado.

@Input() disabled: '' | 'disabled' | boolean;

Pero esto nos obligaría a que cada vez que esta propiedad fuera usada, tener que implementar una lógica que chequeara los diferentes tipos. Algo realmente tedioso.

Usando un setter

Tanto es así, que la solución de facto hasta ahora cuando se daba este tipo de situaciones era:

Añadir una propiedad para uso interno marcándola con el tipo deseado.
Asociar el @Input a un setter que aceptara todos esos diferentes tipos de valores, los transformara al tipo deseado y guardara dicho valor en dicha propiedad de uso interno.

_disabled: boolean = false;

@Input() set disabled(value: '' | 'disabled' | boolean | undefined) {
  this._disabled = typeof value === 'string' ? true : !!value;
}

Aunque este procedimiento en sí es sencillo, según el número de @Input va aumentando, nos hace incrementar las líneas de código de nuestra aplicación sin agregar ningún valor añadido.

Las funciones transformadoras (16.1+)

Es principalmente por esto por lo que Angular en la versión 16.1 ha introducido en los @Input una nueva opción transform en la cual podremos asignar una función transformadora.

@Input({ transform: (value:any) => any })

Estas funciones tendrán que definir un parámetro por el que recibirán el valor original pasado desde el padre. Y devolver el valor transformado, el cual será finalmente asignado en la propiedad asociada al input.

La función transformadora tendrá que ser a su vez :

Ligera, para que su ejecución sea rápida.
Y Pura, para no generar efectos secundarios fuera de la misma.

Funciones ya incluidas en el framework

No poder usar los atributos directamente para asignar boolean y number son los casos más comunes en los que esta limitación de los @Input se hará presente. Por ello el framework ya nos ofrece de entrada las funciones transformadoras para estos dos formatos.

export function booleanAttribute(value: unknown): boolean {
  return typeof value === 'boolean' ? value : (value != null && value !== 'false');
}

export function numberAttribute(value: unknown, fallbackValue = NaN): number {
  const isNumberValue = !isNaN(parseFloat(value as any)) && !isNaN(Number(value));
  return isNumberValue ? Number(value) : fallbackValue;
}

Ambas disponibles en el paquete @angular/core

Precaución al usarlas

Estas funciones se han creado de una manera genérica para cubrir el mayor número de casos posibles, por lo que es importante tener en cuenta la implementación de las mismas si vamos a usarlas tal cual.

Y es que si nos fijamos, vemos como ambas marcan su parámetro de entrada como del tipo unknown, lo que permitiría que el padre pasara cualquier tipo de valor por ese input.

//parent.component.html
<ako-child disabled="someRandomValue" /> // ✅

<ako-child [disabled]="{ some: 'Value' }" /> // ✅
<ako-child [disabled]="4405" /> // ✅

//child.component.html
@Component(...)
export class ChildComponent {
  @Input({ transform: booleanAttribute}) disabled: boolean = false;
}

Raro será que alguien al usar un @Input supuestamente booleano intente pasar un número o un objeto, pero si queremos asegurar un uso correcto de nuestros inputs siempre podemos crear nuestras propias funciones transformadoras que sean más restrictivas.

//parent.component.html
<ako-child disabled="disabled" /> // ✅
<ako-child disabled="someRandomValue" /> // ❌

<ako-child [disabled]="true" /> // ✅
<ako-child [disabled]="false" /> // ✅
<ako-child [disabled]="{ some: 'Value' }" /> // ❌
<ako-child [disabled]="4405" /> // ❌

//child.component.html
function disabledAttribute(value: '' | 'disabled' | boolean) {
  return booleanAttribute(value);
}

@Component(...)
export class ChildComponent {
  @Input({ transform: disabledAttribute}) disabled: boolean = false;
}

Otros usos

Salvar la limitación a la hora de usar atributos para inputs que no sean string es uno de los principales objetivos de esta nueva funcionalidad. Podemos usarlas para cualquier otro tipo de transformación. Por ejemplo:

Transformar un stringen un objeto Date

//parent.component.html
<ako-child date="2024-04-25" />

//child.component.html
function dateAttribute(value: string): Date {
  return new Date(value);
}

@Component(...)
export class ChildComponent {
  @Input({ transform: dateAttribute}) date?: Date;
}

Forzar que el input sea siempre un Array

//parent.component.html
<ako-child aProperty="100" />
<ako-child [aProperty]="[100,200,300]" />

//child.component.html
function toArray(value: unknown | unknown[]): unknown[] {
  return Array.isArray(value) ? value : [value];
}

@Component(...)
export class ChildComponent {
  @Input({ transform: toArray }) aProperty?: unknown[];
}

Y otros muchos más…

Conclusión

En definitiva esta nueva opción transform nos permite aplicar esas transformaciones a los valores recibidos por los @Input de una manera mucho más sencilla, limpia y reutilizable.

Si deseas apoyar la creación de más contenido de este tipo, puedes hacerlo a través nuestro Paypal

YouTube · X · GitHub

Obtener parámetros de la URL como @Input (Angular 16+)

akotech — Tue, 16 Apr 2024 18:56:08 +0000

A partir de Angular 16 podemos obtener desde un componente la información de una ruta simplemente utilizando @Input. En este artículo veremos el funcionamiento de este nuevo procedimiento, así como algunas consideraciones que tendremos que tener en cuenta a la hora de utilizarlo para evitar problemas potenciales.

Si lo prefieres, el contenido de este artículo también lo tienes en formato video aquí.

Tipos principales de información en las Rutas

A la hora de desarrollar una aplicación, es muy común tener que lidiar con rutas que definen cierta información de forma dinámica.

En Angular podemos destacar tres tipos principales de este tipo de información:

Los parámetros de ruta.
Los parámetros de consulta.
Y una serie de datos adicionales que puede tener asociada una ruta, tanto de forma manual en su propiedad data como a través de resolvers.

const routes = [
  { 
    path: 'products/:productId',  // :productId  es un parámetro de ruta
    component: ProductDetailsComponent,
    data: {
      experimental: true
    },
    resolve: {
      product: productResolver
    }
  },
  ...
]

// Los parámetros de búsqueda se encuentran después del '?' en la URL
// en este caso serían q y maxPrice
'myshop.com/catalog?q=teclado&maxPrice=100'

Procedimiento Tradicional

El procedimiento más habitual para obtener esta información desde un componente consiste en:

Inyectar la ruta actual (ActivatedRoute / ActivatedRouteSnapshot)
Y extraer la información a través de sus propiedades params, queryParams y data

// Información en forma de Observables
export class ProductDetailsComponent {
  route = inject(ActivatedRoute);

  productId$ = this.route.params.pipe(map(params => params['productId']));
}

Nuevo Procedimiento

Bien pues a partir de Angular 16, esta misma información también la podremos obtener simplemente añadiendo un @Input en el componente cuyo nombre coincida con el del parámetro o data que queramos obtener.

export class ProductDetailsComponent {
  @Input() productId;  
}

En el caso de que tuviéramos un ruta del tipo catalog?q=teclado con un parámetro de consulta q y quisiéramos vincularlo con una propiedad más descriptiva, podríamos conseguirlo indicando el nombre real del parámetro en el alias del @Input.
@Input('q') query;

¿Cómo activarlo?

Esta nueva característica no viene activada por defecto, por lo que tendremos que activarla manualmente en la configuración del Router.

Si estamos usando la configuración modular esto lo podremos conseguir asignando a true la opción bindToComponentInputs en el método forRoot.

@NgModule({
  imports: [
    RouterModule.forRoot(
      routes, 
      { bindToComponentInputs: true } // <---
    )
  ],
  exports: [RouterModule],
})
export class AppRoutingModule {}

Y en el caso de estar usando la configuración standalone, la podremos activar usando la función withComponentInputBinding() a la hora de proveer el Router.

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withComponentInputBinding()),
  ],
};

Una vez activada la característica el Router vinculará automáticamente todos los parámetros y data de las rutas con los inputs del componente cuyo nombre coincida con dichos parámetros.

Orden de prioridad

En el caso de tener múltiples parámetros o data con un mismo nombre.

// sameName para todos ellos 
{ 
  path: 'somepath/:sameName',
  data: {
    sameName: true
  },
  resolve: {
    sameName: someResolver
  }
}

'somepath?sameName=aValue'

El orden de prioridad que sigue el Router a la hora de vincular el @Input es el siguiente:

Resolvers
Data
Parámetro de Ruta
Parámetro de Consulta

Consideraciones a tener en cuenta

Los valores de los `@Input` no están asegurados hasta `ngOnInit`

Partiendo del siguiente ejemplo con la configuración tradicional:

export class ProductDetailsComponent {
  id$ = this.route.params.pipe(
    map((params) => params['id'])
  );
  product$ = this.id$.pipe(
    switchMap((id) => this.catalogService.getProduct(id))
  );

  constructor(
    private catalogService: CatalogService,
    private route: ActivatedRoute
  ) {}
}

Podríamos estar tentados de refactorizarlo con el nuevo procedimiento de la siguiente manera:

export class ProductDetailsComponent {
  @Input() id; // <- extraemos el id usando el input
  product$ = this.catalogService.getProduct(this.id); //<- utilizamos directamente el id

  constructor(private catalogService: CatalogService) {}
}

Pero los valores de los @Input en Angular no están garantizados hasta que el componente haya sido inicializado, o lo que es lo mismo hasta que se ejecute el lifecycle hook de ngOnInit.

Por tanto en este caso tendríamos que mover la inicialización de la propiedad product$ a dicho hook.

export class ProductDetailsComponent implements OnInit{
  @Input() id;
  product$: Observable<Product | null>;

  constructor(private catalogService: CatalogService) {}

  ngOnInit() {
    this.product$ = this.catalogService.getProduct(this.id);
  }
}

Podemos perder la reactividad en rutas reutilizables

La opción anterior de usar el ngOnInit para la inicialización de las propiedades dependientes de @Input funcionaría sin problemas en la mayoría de los casos.

Pero en los casos en los que el Router reutilice el componente para la siguiente navegación (ej.- si navegamos directamente de los detalles de un producto a los detalles de otro), como el ngOnInit no se ejecutaría para esa segunda navegación, la propiedad del producto no se reasignaría.

En casos simples como este podríamos solucionarlo simplemente sustituyendo la propiedad idpor un setter y mover ahí la asignación del producto.

export class ProductDetailsComponent {
  @Input() set id(newId) {
    this.product$ = this.catalogService.getProduct(newId);
  }
  product$: Observable<Product | null>;

  constructor(private catalogService: CatalogService) {}
}

Para casos complejos mejor usar inputs como Señales (v17.1+)

Para casos más complejos en los que tengamos múltiples pasos dependientes de los inputs, podríamos también usar los setters, pero el riesgo de convertir la lógica en ilegible es alto, sobre todo si la complejidad de la lógica es alta.

// routes.ts
{
  path: 'catalog',
  component: CatalogComponent,
  resolve: {
    products: allProductsResolver,
  },
},

// URL example: myshop.com/catalog?f=teclado&orderBy=priceASC
export class CatalogComponent {
  @Input() products!: Products; // <- extraido del resolver

  //f y orderBy extraidos de los parámetros de consulta
  @Input('f') set nameFilter(val: string) {
    this.filteredProducts = filterByProductName([this.products, val ?? null]);
    this.orderBy = this._order;
  }

  _order: string = '';
  @Input() set orderBy(val: string) {
    this._order = val;
    this.orderedProducts = sortByPrice([this.filteredProducts, val ?? null]);
  }

  filteredProducts: Products = [];
  orderedProducts: Products = [];

  constructor(private route: ActivatedRoute) {}

}

Para estos casos lo más recomendable es usar una versión declarativa. Teniendo como opciones: los observables y las señales.

En el caso de los observables, la mejor opción bajo mi punto de vista, es olvidarnos de los Inputs y utilizar el procedimiento anterior, extrayendo la información desde ActivatedRoute . Podríamos usar un versión mixta utilizando BehaviorSubjects y asignándolos desde los setters de los Inputs.

export class CatalogComponent {
  @Input() products!: Products;

  _nameFilter$ = new BehaviorSubject('');
  @Input('f') set nameFilter(val: string) {
    this._nameFilter$.next(val);
  }

  _order$ = new BehaviorSubject('');
  @Input() set orderBy(val: string) {
    this._order$.next(val);
  }

  filteredProducts$?: Observable<Products>;
  orderedProducts$?: Observable<Products>;

  constructor(private route: ActivatedRoute) {}

  ngOnInit() {
    this.filteredProducts$ = combineLatest([
      of(this.products),
      this._nameFilter$,
    ]).pipe(map(filterByProductName));

    this.orderedProducts$ = combineLatest([
      this.filteredProducts$,
      this._order$,
    ]).pipe(map(sortByPrice));
  }
}

Pero lo único que conseguiríamos es complicar innecesariamente el código sin ningún beneficio. Por lo que bajo mi punto de vista no merece la pena.

La opción que si merece la pena y tenemos disponible desde la v17.1+ es la de usar los inputs como señales. El funcionamiento de estos es igual que el de los @Input tradicionales, pero exponen los valores a través de una señal.

// usando el decorador
@Input() id: string;

// usando la función input (con i minúscula)
id = input<string>(); // id sería del tipo InputSignal<string>

Usando estos inputs en conjunto con las señales computadas el ejemplo quedaría de la siguiente manera:

export class CatalogComponent {
  products = input<Products>();
  nameFilter = input<string>('', { alias: 'f' }); //<-- también podemos usar alias
  orderBy = input<string>('');

  filteredProducts = computed(() =>
    filterByProductName([this.products(), this.nameFilter()])
  );
  orderedProducts = computed(() =>
    sortByPrice([this.filteredProducts(), this.orderBy()])
  );
}

Siendo esta, bajo mi punto de vista, una de las opciones más simples y elegantes que hay disponibles ahora mismo.

A simple vista no sabemos de donde procede el valor del Input

Uno de los ‘problemas’ a la hora de usar este nuevo procedimiento, es que a primera vista no sabemos si los valores de los inputs definidos en un componente vienen de un supuesto padre o si son extraídos de alguna parte de la ruta.

Técnicamente la procedencia del valor es irrelevante para el correcto funcionamiento del componente. Pero si queremos ser más claros a la hora de definir nuestros inputs, tenemos la opción de usar alias a la hora de importar las dependencias @Input e input desde @angular/core .

import {..., Input as RouteParam } from '@angular/core'

export class ProductDetailsComponent {
  @RouteParam() set id(newId) {
    this.product$ = this.catalogService.getProduct(newId);
  }

  ...
}

import { 
  ...,
  input as resolvedData,
  input as queryParam,
} from '@angular/core';

export class CatalogComponent {
  products = resolvedData<Products>();
  nameFilter = queryParam<string>('', { alias: 'f' }); //<-- también podemos usar alias
  orderBy = queryParam<string>('');

  ...
}

Conclusión

Este nuevo procedimiento nos puede ser muy útil a la hora de simplificar la extracción de la información de las rutas, pero deberemos tener cuidado a la hora de elegir la implementación para evitar posibles errores potenciales.

Si deseas apoyar la creación de más contenido de este tipo, puedes hacerlo a través nuestro Paypal

YouTube · X · GitHub

Cómo prevenir el abandono accidental de una ruta gracias a la guarda canDeactivate

akotech — Wed, 14 Jun 2023 12:36:25 +0000

A la hora de crear nuestras aplicaciones en Angular hay situaciones en la que abandonar una ruta puede llevar asociada la pérdida de información no guardada, como por ejemplo en aquellas rutas en las que tengamos un formulario.

Esta situación puede resultar realmente frustrante para el usuario sobre todo si los cambios que había realizado el usuario eran numerosos.

En este artículo veremos cómo podemos prevenir esta situación utilizando la guarda CanDeactivate del Router.

Si lo prefieres, el contenido de este artículo también lo tienes en formato video aquí.

¿Qué es una guarda?

Lo primero que necesitamos es saber qué son las guardas. Las guardas son una especie de puntos de control que podemos añadir en las diferentes etapas del proceso de navegación del Router para permitir, detener o redireccionar la navegación en base a unos criterios que nosotros establezcamos.

En este caso, nos centraremos únicamente en la guarda del tipo canDeactivate, la cual se ejecuta justo antes de desmontar el componente asociado a la ruta en la cual hayamos aplicado la guarda.

const someRoutes: Routes = [
  ...,
  {
    path: ':id',
    component: SomeEditComponent, // <--
    canDeactivate: [withoutUnsavedChangesGuard],
  },
]

¿Cómo crear una guarda?

Una guarda, en sí misma, es simplemente una función que puede devolver uno de tres valores posibles:

truepara permitir la navegación
falsepara detenerla
O un objeto UrlTree para redireccionar la navegación a una ruta distinta.

Hasta hace poco, la única forma de definir la lógica de las guardas, era como métodos de un servicio inyectable.

// deprecated v15.2+
@Injectable({ providedIn: 'root' })
export class MyGuard implements CanDeactivate<unknown> {

  canDeactivate(...): boolean | UrlTree | ... {
    //lógica de la guarda
  }

}

Pero las guardas basadas en clases han sido recientemente marcadas como obsoletas en favor de las guardas funcionales introducidas en la versión 14.1, las cuales nos permiten definir directamente la lógica de nuestras guardas en una función independiente.

export const myGuard: CanDeactivateFn<unknown> = (...) => {
  //lógica de la guarda
}

En los ejemplos de este artículo usaremos una guarda funcional, pero ese mismo código podría ser perfectamente definido dentro del método equivalente de un servicio en el caso de que estés usando una versión más antigua de Angular.

La Guarda `CanDeactivate`

En el caso concreto de la guarda CanDeactivate, la función de la misma podrá definir los siguientes 4 parámetros:

type CanDeactivateFn<T> = (
  component: T, 
  currentRoute: ActivatedRouteSnapshot, 
  currentState: RouterStateSnapshot, 
  nextState: RouterStateSnapshot
) => boolean | UrlTree | ...

component: Donde recibirá la referencia del componente asociado a la ruta.
currentRoute: Con el snapshot de la ruta actual
currentState: Con el snapshot del estado del Router actual
nextState: Con el snapshot del estado del Router de la siguiente navegación solicitada

Ejemplo de ruta con Formulario

Visto esto y tomando como ejemplo una ruta asociada a un componente en el que tenemos un formulario.

// some.routes.ts
const someRoutes: Routes = [
  ...,
  {
    path: ':id',
    component: SomeEditComponent,
  },
]


// some-edit.component.ts
@Component(...)
export class SomeEditComponent {
  editForm!: FormGroup;

  ...

  // reseteamos el estado del formulario cuando
  // la info de este sea guardada correctamente.
  onSave(): void {
    const updatedInfo = this.editForm.getRawValue();

    this.someService
      .save(updatedInfo)
      .subscribe(() => this.editForm.reset(updatedInfo));
  }
}

Si quisiéramos proteger contra el abandono accidental de dicha ruta cuando ese formulario tenga cambios sin guardar, podríamos por ejemplo definir una guarda CanDeactivate que compruebe la propiedad dirty del formulario para saber si ha sido modificado, y en el caso de que así sea, solicitar una confirmación por parte del usuario para permitir o no el abandono de la ruta.

export const withoutUnsavedChangesGuard: CanDeactivateFn<SomeEditComponent> = (component) => {

  // Si tiene cambios sin guardar, solicitamos confirmación
  if (component.editForm.dirty) {
    return confirm('¿Desea descartar los cambios?');
  }

  // si no tiene cambios sin guardar permitimos
  // directamente la navegación a la siguiente ruta.
  return true;
};

Y una vez definida nuestra guarda funcional, ya lo único que tendríamos que hacer sería añadirla en el array de la propiedad canDeactivate de la ruta en cuestión y ya la tendríamos protegida contra el abandono accidental.

 const someRoutes: Routes = [
  ...,
  {
    path: ':id',
    component: SomeEditComponent,
    canDeactivate: [withoutUnsavedChangesGuard]
  },
]

Crear una guarda Reutizable

La solución anterior funciona correctamente. Y si solo tenemos que proteger una única ruta en toda la aplicación, este tipo de implementación es suficiente.

El problema que tenemos eso sí, es que al vincular directamente la guarda con un tipo especifico de componente (CanDeactivateFn<SomeEditComponent>), si necesitáramos proteger múltiples rutas, tendríamos que o bien adaptar la guarda para que tenga en cuenta todos esos distintos escenarios aumentando así su complejidad o, en su defecto, crear una guarda específica para cada una de las rutas.

Una mejor opción para estos casos, es generalizar la guarda vinculándola contra una interfaz en vez de contra un tipo específico de componente.

Para este caso por ejemplo podríamos crear una interfaz HasUnsavedChangesque incluya un método homónimo cuyo tipo de retorno sea un booleano y vincular nuestra guarda a dicha interfaz.

export interface HasUnsavedChanges {
  hasUnsavedChanges(): boolean;
}

export const withoutUnsavedChangesGuard: CanDeactivateFn<HasUnsavedChanges> = (component) => {
  ...
};

Como ahora el parámetro component, deberá tener la referencia a un componente que implemente esta interfaz, en vez de chequear contra la propiedad dirty del formulario como estábamos haciendo anteriormente, tendremos ahora que llamar a ese método de la interfaz genérica para saber si el componente vinculado tiene cambios sin guardar o no.

 export const withoutUnsavedChangesGuard: CanDeactivateFn<HasUnsavedChanges> = (component) => {
  if (component.hasUnsavedChanges()) { //<---
    return confirm('¿Desea descartar los cambios?');
  }

  return true;
};

Y por último para ahora usar esta guarda en cualquiera de las rutas de nuestra aplicación, ya lo único que tendríamos que hacer sería implementar esta nueva interfaz en el componente asociado a la ruta que queremos proteger, definiendo en el método de dicha interfaz la lógica que determine si el componente tiene cambios sin guardar.

@Component(...)
export class SomeEditComponent implements HasUnsavedChanges{
  editForm!: FormGroup;

  ...

  hasUnsavedChanges(): boolean {
    return this.editForm.dirty;
  }
}

EXTRA `window:beforeunload`

Con esto ya hemos visto el funcionamiento básico de la guarda CanDeactivate, pero antes de terminar es importante recalcar que el funcionamiento de esta guarda está limitado solo a la navegación interna de la aplicación. Esto quiere decir que la guarda que acabamos de implementar, no nos protegería si por ejemplo refrescáramos la página o cerráramos la pestaña actual del navegador.

Para este tipo de protección adicional tendríamos que apoyarnos en el evento beforeunload de la ventana del navegador.

Para ello podríamos por ejemplo añadir un @HostListener en el componente a proteger el cual haga uso del método hasUnsavedChanges que añadimos anteriormente.

@Component(...)
export class SomeEditComponent implements HasUnsavedChanges{
  editForm!: FormGroup;

  @HostListener('window:beforeunload', ['$event'])
  onUnloadHandler(e: BeforeUnloadEvent) {
    return this.hasUnsavedChanges() === false; 
  }

  ...

  hasUnsavedChanges(): boolean {
    return this.editForm.dirty;
  }
}

Conclusión

Como hemos visto haciendo uso de la guarda CanDeactivate podremos proteger de una manera sencilla todas aquellas rutas de nuestra aplicación en las que un abandono accidental pudiera provocar una pérdida de información.

Si deseas apoyar la creación de más contenido de este tipo, puedes hacerlo a través nuestro Paypal

YouTube · Twitter · GitHub

Cómo Deshabilitar Controles en un Formulario Reactivo

akotech — Thu, 16 Feb 2023 14:32:20 +0000

A la hora de trabajar con formularios en ocasiones necesitamos deshabilitar dinámicamente uno de sus controles en base al valor de otro de los controles del formulario.

Si alguna vez has intentado deshabilitar un control en un formulario reactivo vinculando a su propiedad disabled:

<input 
  type="text"
  formControlName="direccion"
  [disabled]="tipoDeEntrega.value === 'recogidaEnTienda'"
/>

Te habrás dado cuenta que el control no se deshabilita y además por consola se lanza un warning indicando que este no es el procedimiento para hacerlo.

En este artículo vamos a explorar unas cuantas alternativas que tenemos a la hora de conseguir esta funcionalidad.

Si lo prefieres en formato video, el contenido de este artículo también lo tienes aquí.

Conceptos Básicos

A la hora de habilitar/deshabilitar un control de formulario reactivo, tenemos dos procedimientos básicos:
‌

1- Establecer el estado inicial
Cuando creamos un control de formulario, este se crea siempre por defecto como habilitado.

new FormControl('valor_inicial')

Pero este comportamiento lo podemos modificar fácilmente, utilizando la versión expandida del valor inicial, pasando un objeto con las propiedades value y disabled

new FormControl({ value: 'valor_inicial', disabled: true})

‌

2- Modificar el estado de habilitación de un control

Para modificar el estado de habilitación de un control ya creado, todos los controles de formulario tienen un par de funciones enable() y disable() que nos permiten habilitarlos y deshabilitarlos respectivamente.

control.enable() // habilitará el control

control.disable() // deshabilitará el control

Una vez vistos estos conceptos básicos, veamos como los podemos aplicar para deshabilitar un control dinámicamente cuando el valor de otro control del formulario cambie.

Usando `valueChanges`

El procedimiento estándar a la hora de implementar esta funcionalidad es haciendo uso del observable valueChanges del control que queremos usar como base para monitorizar los cambios de su valor.

Por ejemplo en el siguiente extracto de un formulario de una supuesta tienda online:

deliveryForm = new FormGroup({
  tipoDeEntrega: new FormControl('envioADomicilio'),
  direccion: new FormControl(''),
});

Tenemos dos controles:

tipoDeEntrega cuyos valores pueden ser envioADomicilio o recogidaEnTienda.
y direccion que permite al usuario introducir una dirección de entrega.

Bien pues para deshabilitar el control de la direccion cuando el tipoDeEntrega seleccionado sea igual a recogidaEnTienda, podemos hacer lo siguiente:

const { tipoDeEntrega, direccion } = this.deliveryForm.controls;

tipoDeEntrega.valueChanges.subscribe(  
  (tipoSeleccionado) => 
    tipoSeleccionado === 'recogidaEnTienda'
      ? direccion.disable()
      : direccion.enable()
);

En donde:

Primero extraemos los controles del FormGroup
A continuación nos estamos subscribiendo al observable valueChanges del control del tipo de entrega, el cual emitirá una notificación cada vez que su valor cambie.
Y por último en el callback de esta subscripción chequeamos el tipo seleccionado. Si es igual a recogidaEnTienda deshabilitamos el control de la dirección llamando a su método disable() . Y en caso, contrario llamamos a su método enable() para volver a habilitarlo.

Cómo vemos nos estamos subscribiendo manualmente a un observable, lo que implica que somos también responsables de cancelar dicha subscripción cuando deje de ser necesaria. No lo hemos incluido en el extracto de código anterior para una mayor claridad, pero este sería un ejemplo de uso completo en un componente:

export class SomeComponent implements OnInit, OnDestroy {
  deliveryForm = new FormGroup({
    tipoDeEntrega: new FormControl('envioADomicilio'),
    direccion: new FormControl(''),
  });

  subscription?: Subscription;

  ngOnInit(): void {
    const { tipoDeEntrega, direccion } = this.deliveryForm.controls;

    this.subscription = tipoDeEntrega.valueChanges.subscribe(
      (tipoSeleccionado) =>
        tipoSeleccionado === 'recogidaEnTienda'
          ? direccion.disable()
          : direccion.enable()
    );
  }

  ngOnDestroy(): void {
    this.subscription?.unsubscribe();
  }
}

Creando una directiva personalizada

Como hemos visto el procedimiento de valueChanges en sí es relativamente sencillo. Pero si la complejidad del formulario es alta y/o no estamos muy cómodos usando observables, dicho procedimiento se puede volver tedioso y enrevesado.

Por ello vamos a ver una alternativa para devolver está funcionalidad al template, creando una directiva específica que nos proporcione una funcionalidad similar a la del vínculo a la propiedad disabled.

Bien, pues aquí tenemos el código de dicha directiva.

@Directive({
  selector: `
    [formControl][akoDisabledIf],
    [formControlName][akoDisabledIf]
  `,
  standalone: true,
})
export class ControlDisabledIfDirective {
  @Input('akoDisabledIf') set disabledIf(condition: boolean) {
    const control = this.ngControl.control;

    condition ? control?.disable() : control?.enable();
  }

  constructor(private ngControl: NgControl) {}
}

Veámosla por partes:

Lo primero que hemos hecho es limitar el uso de esta directiva únicamente a los elementos que también tengan aplicadas las directivas formControl o formControlName indicando esta circunstancia en el selector.
A continuación para obtener la referencia al FormControl asociado para poder habilitarlo/deshabilitarlo, hemos inyectado en el constructor NgControlcomo dependencia. Esta es una clase base de la que heredan todas las directivas de asociación de controles (formControl, formControlName y ngModel). En nuestro caso particular lo que nos permitirá es obtener la referencia a esa directiva FormControlDirective o FormControlName, dependiendo de la directiva usada en el template para vincular el control de formulario.
Y por último hemos definido un @Input con el mismo nombre que el selector de nuestra directiva (akoDisabledIf), para capturar esa condición booleana que definirá si el control debe ser habilitado o deshabilitado. En nuestro caso en este @Input hemos definido un setter que acepte dicha condición booleana como argumento. Y en el cuerpo, primero hemos extraído del ngControl que hemos inyectado la referencia al FormControl a través de su propiedad control. Y a continuación, estamos deshabilitando el control si la condición proporcionada es true y habilitándolo si esta es false.

Para ahora utilizar esta directiva simplemente tenemos que:

1.- Importarla en el contexto del componente que contiene el formulario, ya sea un @NgModule o un @Component standalone:

@NgModule({ 
  imports: [ControlDisabledIfDirective],
  ...
})

// -------

@Component({ 
  standalone: true,
  imports: [ControlDisabledIfDirective],
  ...
})

2.- Y hecho esto ya podemos utilizarla en el template que contiene el formulario, añadiéndola en el input a deshabilitar e indicando en la asignación la condición para deshabilitarlo.

<input
  type="text"
  formControlName="direccion"
  [akoDisabledIf]="tipoDeEntrega.value === 'recogidaEnTienda'"
/>

‌

Directiva para FormGroup y FormArray
La directiva anterior es específica para ser utilizada únicamente con un FormControl.

Pero del mismo modo podemos crear otra que nos permita deshabilitar un grupo de controles, tanto si es un FormGroup como un FormArray.

@Directive({
  selector: `
    [formGroup][akoDisabledIf],
    [formGroupName][akoDisabledIf],
    [formArrayName][akoDisabledIf]
  `,
  standalone: true,
})
export class ContainerDisabledIfDirective {
  @Input('akoDisabledIf') set disabledIf(condition: boolean) {
    const container = this.controlContainer.control;

    condition ? container?.disable() : container?.enable();
  }

  constructor(private controlContainer: ControlContainer) {}
}

Las únicas dos diferencias con la anterior son:

En el selector la hemos limitado para se aplique cuando el elemento también incluya una directiva reactiva de asociación de un contenedor de controles (formGroup, formGroupName, formArrayName).
Hemos sustituido la dependencia NgControl por ControlContainer en el constructor, que es en este caso la clase base de la que heredan las directivas de contenedor.

Esta nueva directiva nos permitiría deshabilitar todo un grupo de controles, asociándola en el template al elemento vinculado a dicho contenedor.

<div 
  formGroupName="unGrupoDeControles" 
  [akoDisabledIf]="condicionParaDeshabilitarElGrupo"
>
 ...
</div>

Usando `[attr.disabled]` y por qué no me gusta como opción.

Como hemos visto en el ejemplo inicial el vínculo a la propiedad disabled no funciona y lanza un warning por consola.
Debido a ello en diversas ocasiones he visto como se sustituye este vínculo a la propiedad por el vínculo al atributo.

<input 
  type="text"
  formControlName="direccion"
  [attr.disabled]="tipoDeEntrega.value === 'recogidaEnTienda' ? 'disabled' : null"
/>

Como al vincular al atributo no podemos asignar a true/false, ya que eso no generaría un HTML válido, tenemos que modificar la sentencia de la asignación, asignando 'disabled' cuando la condición sea verdadera y a null cuando esta sea falsa para que angular no añada este atributo.

En principio esta parece ser una alternativa válida ya que si compilamos la aplicación, el input se habilita y deshabilita correctamente. Pero esta opción tiene un problema. Y es que vinculando al atributo, el control de formulario únicamente se deshabilita en el DOM. Lo que quiere decir que el FormControl de la clase no se ve afectado y por tanto el valor del mismo tampoco elimina del valor del formulario.

Usando esta alternativa lo único que estamos consiguiendo es implementar una especie de función de solo-lectura. Y es precisamente por esto, por lo que esta opción carece de sentido para mí. Ya que si esta es la funcionalidad que buscamos la podríamos conseguir vinculando directamente a la propiedad readonly.

<input 
  type="text"
  formControlName="direccion"
  [readonly]="tipoDeEntrega.value === 'recogidaEnTienda'"
/>

Conclusiones Finales

Bien pues en este artículo hemos visto las dos opciones principales a la hora de habilitar/deshabilitar controles en los formularios reactivos.
La opción estándar y recomendada es usando el observable valueChanges desde la clase sin necesidad de involucrar al template.
Pero si no estamos del todo cómodos con esta opción siempre podemos hacer uso de unas directivas del estilo de las que hemos visto.

Si deseas apoyar la creación de más contenido de este tipo, puedes hacerlo a través nuestro Paypal

Control de Acceso Basado en Roles(RBAC) en Angular

akotech — Mon, 09 Jan 2023 09:39:59 +0000

El Control de Acceso Basado en Roles o RBAC por sus siglas en inglés, es uno de los paradigmas de seguridad más comunes en las aplicaciones de hoy en día. El principio básico de este consiste en otorgar a cada usuario únicamente los permisos imprescindibles para desarrollar las funciones asociadas a la posición o rol que cumplen dentro de la organización.

RBAC en el Desarrollo Web

Cuando hablamos de RBAC en el contexto del desarrollo web hay que hacer, eso sí, una distinción clara entre lo que esto significa en el backend y lo que significa en el frontend.

En el contexto del backend hablamos propiamente de ese sistema de seguridad en el que un usuario solo podrá acceder a ciertos recursos si está debidamente identificado y tiene otorgados los permisos para acceder a ellos.

Pero en el contexto del frontend debido a que el código fuente de la aplicación es accesible por el usuario, no podemos hablar de RBAC como un sistema de seguridad ya que sería relativamente sencillo sobrepasarlo para todo aquel usuario con un mínimo de conocimiento que supiera donde mirar. Por ello, en el frontend tenemos que considerarlo más como una forma de mejorar la experiencia del usuario (UX) que como un sistema de seguridad.

⚠️ Aplicar en el frontend las técnicas de RBAC que vamos a ver en este artículo, NO EXIMEN de tener que aplicar una protección real y efectiva en el backend.

RBAC en Angular

En este artículo hablaremos de dos elementos que tenemos disponibles para aplicar los principios de RBAC en Angular:

Las Guardas del Router para limitar el acceso a las diferentes rutas de nuestra aplicación.
y Las Directivas Estructurales para mostrar y ocultar los diferentes elementos de la UI en función de rol del usuario.

Este contenido también está disponible con un ejemplo práctico específico en el siguiente video.

Guardas del Router

Uno de los elementos principales que nos permitirán aplicar RBAC en Angular, son las guardas del Router. Las guardas son como una especie de puntos de control que podemos añadir en las rutas de nuestra aplicación para permitir, detener o redirigir la navegación en función de unos criterios que definamos.

const routes = [
  { 
    path: 'private-zone',
    canActivate: [IsLoggedInGuard], // <-- solo los usuarios que hayan iniciado sesión pueden acceder a la zona privada
    ...
  }
]

En sí mismas, las guardas no son más que simples funciones que tienen que devolver uno de los siguientes 3 valores:

true: para permitir que continúe el proceso de la navegación.
false: para detenerlo en seco.
O un objeto UrlTree: que como veremos más adelante representa una ruta alternativa a la que redirigir al usuario.

Estos valores los podrá devolver la función de la guarda de manera directa, o también en forma de Observable o Promesa, dependiendo de los requerimientos del proceso.

myGuard(): boolean | UrlTree | Observable<boolean | UrlTree> | Promise<boolean | UrlTree>

Existen 5 tipos de guardas que podremos establecer en cada una de las rutas de nuestra aplicación:

{
  path: 'some-path',
  canMatch: [],
  canLoad: [],
  canActivate: [],
  canActivateChild: [],
  canDeactivate: [],
  ... 
}

Para entender las diferencias que hay entre ellas debemos hablar primero de los pasos que sigue el Router a la hora de procesar las rutas de nuestra aplicación.

Proceso de Rutas

A la hora de procesar una petición de navegación, el Router de Angular procesa las rutas que hemos definido en nuestra aplicación siguiendo 3 pasos principales:

El primero es el Route Matching, que es el proceso en el que compara la ruta de la navegación solicitada con el path de cada unas de las rutas que hemos definido en nuestra aplicación en busca de coincidencias.
```
// https://myapp.com/dashboard

const routes = [
  { path: 'dashboard', ... },
  ...
];
```

Si durante el Route Matching una de las rutas que devuelve coincidencia está usando loadChildren para cargar un módulo extra, el Router procederá a cargar dicho módulo en la aplicación.

const routes = [
  { 
    path: 'orders', 
    loadChildren: () => 
      import('./orders/orders.module').then((m) => m.OrdersModule),
  },
  ...
];

⚠️ Este paso solo se ejecutará si dicho módulo no ha sido ya previamente cargado.

Y por último, una vez encontrada la coincidencia total para la navegación solicitada, se produce la activación de las rutas, que no es más que el renderizado de los componentes de cada uno de los segmentos en sus <router-outlet> correspondientes.

Tipos de Guardas

Bien pues los diferentes tipos de guardas nos permiten establecer esos puntos de control en la frontera de cada uno de estos procesos.

Como hemos anteriormente, en Angular tenemos actualmente 5 tipos de guardas disponibles que podremos establecer en cada una de las rutas de nuestra aplicación:

canMatch(v14.1+): Nos permite controlar dinámicamente si el Router puede usar o no una ruta en el proceso del Route Matching. (En esta guarda devolver false, en vez de detener la navegación, hace que el Router ignore esa ruta como si no existiera).
canLoad(deprecated): Nos permite controlar si el usuario tiene permiso o no para cargar el módulo indicado en la propiedad loadChildren de la ruta. Esta guarda ha sido recientemente marcada como obsoleta (v15) en favor de canMatch.
canActivate: Nos permite controlar si el usuario puede renderizar o no el componente asociado a la ruta.
canActivateChild: Nos permite controlar si el usuario puede renderizar o no los componentes de las rutas hijas de la ruta actual.
canDeactivate: Nos permite controlar si el usuario puede abandonar o no la ruta actual. Lo que nos permitiría por ejemplo impedir que un usuario abandone una ruta en la que tenga cambios sin guardar.

Creando nuestra primera Guarda

Para definir la lógica de una guarda, actualmente disponemos de dos opciones en Angular:

Implementando la interfaz del tipo de guarda requerido en la clase de un servicio inyectable.

@Injectable({ providedIn: 'root'})
export class MyGuard implements CanActivate { 
  ...

  canActivate(...): boolean | UrlTree | ... {
    // lógica de la guarda
  }
}

// Y pasando esta clase en el array de la propiedad canActivate de la ruta a aplicar
const routes = [
  { path: 'some-path', canActivate: [ MyGuard ] }
]

O definiendo la lógica como una guarda funcional (v14.2+)

export function myGuard(...): boolean | UrlTree | ... {
  //lógica de la guarda
}

// O también

export const myGuard: CanActivateFn = (...) => {
  //lógica de la guarda
}

// Y pasando esa función o const al array de la propiedad de la ruta
const routes = [
  { path: 'some-path', canActivate: [ myGuard ] }
]

isLoggedInGuard

Por ejemplo, una de las parejas de roles más comunes en las aplicaciones, es la pareja de Invitado / Usuario, donde la diferencia entre ambos roles es el hecho de que el usuario haya iniciado o no sesión.

Podríamos pues limitar el acceso a ciertas rutas solo para usuarios que hayan iniciado sesión creando la siguiente guarda.

//auth.service
export class AuthService {
  // expone estado de inicio de sesión en forma de Observable
  isLoggedIn$: Observable<boolean>; 
  ...
}


//is-logged-in.guard
@Injectable({ providedIn: 'root' })
export class IsLoggedInGuard implements CanActivate {
  constructor(private authService: AuthService) {}

  canActivate(): Observable<boolean | UrlTree> {
    return this.authService.isLoggedIn$; //<-- devolvemos el observable del AuthService
  }
}

Si ahora asignáramos esta guarda a una ruta con el path private-zone:

{
  path: 'private-zone',
  component: PrivateZoneComponent,
  canActivate: [IsLoggedInGuard],
}

A la hora de acceder a esta ruta, antes de renderizar el componente asociado el Router ejecutará la guarda asociada y, en este caso, se subscribirá automáticamente al observable retornado y esperará a que este emita su primer valor.

Si el primer valor emitido por el observable isLoggedIn$ es true (el usuario ha iniciado sesión), el Router procederá a renderizar dicho componente en el <router-oulet> correspondiente.
Si por el contrario el primer valor emitido por isLoggedIn$ es false, el Router detendrá el proceso de navegación en seco, sin ningún tipo de feedback para el usuario.

Para el caso en el que un usuario que no ha iniciado sesión intente acceder a una sección privada, en vez de detener la navegación en seco, una mejor solución en términos de UX, sería redirigirlo a la ruta /login para que pueda completar ese inicio de sesión.

Esto como hemos dicho anteriormente, lo podemos conseguir devolviendo desde la guarda un objeto UrlTree con la ruta alternativa.

Por lo que podríamos modificar nuestra guarda para conseguir esta funcionalidad de la siguiente manera:

//is-logged-in.guard
@Injectable({ providedIn: 'root' })
export class IsLoggedInGuard implements CanActivate {
  constructor(
    private authService: AuthService, 
    private router: Router // <-- inyectamos el Router
  ) {}

  canActivate(): Observable<boolean | UrlTree> {
    return this.authService.isLoggedIn$.pipe(
      //usamos el operador map para transformar false en el UrlTree para la ruta /login
      map((isLoggedIn) => isLoggedIn || this.router.createUrlTree(['/login'])) 
    );
  }
}

Ahora si el observable isLoggedIn$ emite inicialmente false, transformamos ese valor en el objeto UrlTree de la ruta /login usando el método createUrlTree() del Router, lo que hará que el usuario sea redireccionado a dicha ruta.

hasRoleGuard

Ya hemos visto como crear una guarda básica para limitar el acceso a una ruta cuando una condición estática se cumpla o no. Pero, ¿cómo podemos crear una guarda en donde los parámetros de esa condición sean dinámicos?

{
  path: 'some-section',
  canActivate: [hasRole(['Manager', 'Accountant'])],
  ...
},
{
  path: 'other-section',
  canActivate: [hasRole(['Manager', 'Clerk'])],
  ...
},

Como guarda funcional (v14.2+)
Con las relativamente nuevas guardas funcionales, esto lo podemos conseguir fácilmente de la siguiente manera:

//user.roles
export type Role = 'Clerk' | 'Accountant' | 'Manager';


// has-role.guard
export function hasRole(allowedRoles: Role[]) {
  return () =>
    inject(AuthService).user$.pipe(
      map((user) => Boolean(user && allowedRoles.includes(user.role))),
      tap((hasRole) => hasRole === false && alert('Acceso Denegado'))
    );
}

1.- Lo primero que hemos hecho es crear una función factoría que acepta como argumento un array con los roles permitidos, a partir de los cuales crea y devuelve la función de la guarda para esos roles.

export function hasRole(allowedRoles: Role[]) {
  return Guarda_funcional_creada_para_allowedRoles_proporcionados
}

2.- Para crear esa guarda hemos primero inyectado el AuthService usando la función inject del framework y de ese servicio hemos extraído la información del usuario actual a través de una propiedad user$.

inject(AuthService).user$

3.- A partir de la información de ese usuario y los roles proporcionados, hemos usado el operador map para realizar el chequeo de la guarda. Chequeando si hay un usuario logeado y si además el rol de ese usuario está incluido en los proporcionados en el array de roles permitidos.

map((user) => Boolean(user && allowedRoles.includes(user.role)))

4.- Y por último, para no fallar silenciosamente en caso de que el chequeo anterior devuelva false, hemos añadido un tap para mostrar una alerta en la aplicación usando en este caso el método alert del navegador para simplificar el ejemplo.

tap((hasRole) => hasRole === false && alert('Acceso Denegado'))

Como servicio inyectable
Como vemos la implementación de este tipo de guardas en las últimas versiones de Angular es muy sencilla. Esto no es así de simple para versiones anteriores, en las que tenemos que utilizar la inyección de dependencias para pasar la clase que tiene definido el método de la guarda, ya que en ese caso no le podemos pasar directamente el array de roles permitidos.

Para este tipo de casos, tendremos que apoyarnos en la propiedad data de las rutas para definir ese array de roles permitidos.

{
  path: 'some-section',
  canActivate: [HasRoleGuard],
  data: {
    allowedRoles: ['Manager', 'Accountant'],
  },
  ...
},

Y para ahora acceder a esta información desde el método de la guarda tendremos que hacer uso de uno de los parámetros de dicho método. En este caso la firma del método canActivate es la siguiente:

canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean | UrlTree | ...

Por lo que para acceder a esa información de la ruta, tendremos que usar el primer parámetro route para acceder a la propiedad data de la ruta. La guarda quedaría pues de la siguiente manera:

@Injectable({ providedIn: 'root' })
export class HasRoleGuard implements CanActivate {
  // inyectamos el AuthService en el constructor
  constructor(private authService: AuthService) {}

  canActivate(route: ActivatedRouteSnapshot): Observable<boolean> {
    // extraemos la información de la propiedad data de la ruta. 
    const allowedRoles = route.data?.['allowedRoles'];

    // usamos el user del AuthService y los roles extraídos de data para 
    // implementar nuevamente la lógica de la guarda
    return this.authService.user$.pipe(
      map((user) => Boolean(user && allowedRoles.includes(user.role))),
      tap((hasRole) => hasRole === false && alert('Acceso Denegado'))
    );
  }
}

Como vemos, esta implementación es algo más compleja con el inconveniente adicional de ser más propensa a errores, ya que usando la propiedad data de la ruta no tenemos ningún tipo de Intellisense en el editor ni protección de tipo de TypeScript que nos obligue/ayude a definir esa información extra que necesita la guarda.

Debido a esto, para definir guardas que requiera de algún parámetro extra dinámico, como este de los roles, es recomendable definirlas como guarda funcional. (Siempre y cuando eso sí estemos usando una versión de Angular igual o posterior a la v14.2)

Directivas Estructurales

Ya hemos visto como limitar el acceso a las diferentes rutas de nuestra aplicación usando las guardas. El segundo elemento que tenemos disponible para mejorar la UX en el contexto de RBAC son las directivas estructurales.

Las directivas estructurales nos permiten renderizar el contenido asociado de manera condicional. Este es el tipo de directivas al que pertenecen las directivas *ngIf o *ngFor.

Por ejemplo imaginemos que tenemos una aplicación en la que podemos tener usuarios con tres roles diferentes ('Clerk' | 'Accountant' | 'Manager'). Y en el header de dicha aplicación tenemos una serie de enlaces de navegación a las diferentes secciones de la misma.

Imaginemos también que usando las guardas ya hemos limitado el acceso a la sección de Contabilidad para que solo puedan acceder a ella los usuarios con los roles de Accountant o Manager. Aunque esto es suficiente a la hora limitar que un usuario fuera de esos roles acceda a dicha sección, una mejor solución es directamente no mostrar ese enlace a aquellos usuarios que no tengan permiso para acceder a la misma.

Aunque esto lo podríamos conseguir haciendo uso de la directiva *ngIf de la siguiente forma:

//header.component.ts
export class HeaderComponent {
  constructor(private authService: AuthService) {}
  ...

  userRoleIn(allowedRoles: Role[]): Observable<boolean> {
    return this.authService.user$.pipe(
      map((user) => Boolean(user && allowedRoles.includes(user.role))),
    );
  }
}


//header.component.html
<a *ngIf="userRoleIn(['Accountant', 'Manager']) | async" routerLink="/accounting">Contabilidad</a>

Esto nos obligaría a tener que repetir esta misma lógica una y otra vez en los diferentes componentes de la aplicación cada vez que quisiéramos mostrar u ocultar cierto elemento de la interfaz en base al rol del usuario.

Una mejor solución, por tanto, es crear nuestra propia directiva estructural que encapsule toda esta lógica del chequeo de roles y usarla directamente sobre el elemento del template pasándole únicamente el array de roles permitidos.

<a *showForRoles="['Accountant', 'Manager']" routerLink="/accounting">Contabilidad</a>

Veamos como podemos podemos conseguir esto.

Creando la directiva personalizada `*showForRoles`

Lo primero que tenemos que hacer es crear la directiva. Para ello simplemente tenemos que ejecutar el comando de la cli:

ng generate directive <nombre_de_la_directiva>

En nuestro caso la llamaremos showForRoles , lo que nos genera el siguiente archivo:

@Directive({
  selector: '[appShowForRoles]',
})
export class ShowForRolesDirective {
  constructor() {}
}

Una vez tenemos nuestra directiva creada, para ejecutar la lógica de los roles necesitamos traer a ella:

El listado de roles permitidos. Lo que podemos conseguir añadiendo un @Input con el mismo nombre de la directiva, lo que nos permitirá pasar el listado de roles en la asignación a la hora de usarla.

//show-for-roles.directive
@Directive({
  selector: '[appShowForRoles]',
})
export class ShowForRolesDirective {
  @Input('appShowForRoles') allowedRoles?: Role[];
  ...
}

// template en el que la usemos
<a *appShowForRoles="['Accountant', 'Manager']" ...>

Y la información del usuario. Para lo que simplemente tenemos que inyectar el AuthService en su constructor.

export class ShowForRolesDirective {
  ...
  constructor(private authService: AuthService) {}
}

Y una vez tenemos los datos necesarios para ejecutar la lógica, solo nos queda mover esa lógica del chequeo de roles a la directiva.

@Directive({
  selector: '[appShowForRoles]',
})
export class ShowForRolesDirective implements OnInit, OnDestroy {
  @Input('appShowForRoles') allowedRoles?: Role[];
  private sub?: Subscription;

  constructor(private authService: AuthService) {}

  ngOnInit(): void {
    this.sub = this.authService.user$.pipe(
      map((user) => Boolean(user && this.allowedRoles?.includes(user.role))),
    ).subscribe();
  }

  ngOnDestroy(): void {
    this.sub?.unsubscribe();
  }
}

Como en este caso nuestra lógica tiene como base el Observable del usuario del AuthService, estamos definiendo la lógica y subscribiéndonos en el lifecycle hook de ngOnInit. Sin olvidarnos de cancelar dicha subscripción en el ngOnDestroy .

Una vez tenemos la lógica del chequeo implementada, como esta va a ser una directiva estructural, solo nos queda añadir la lógica para renderizar o eliminar explícitamente el elemento en el que la hayamos aplicado.

Para ello necesitamos inyectar en el constructor dos dependencias más, ViewContainerRef y TemplateRef, las cuales nos permiten obtener la referencias al ng-template generado por el asterisco * delante de la directiva y el contenedor de la vista asociado a este.

export class ShowForRolesDirective implements OnInit, OnDestroy {
  ...
  constructor(
    private authService: AuthService,
    private viewContainerRef: ViewContainerRef,
    private templateRef: TemplateRef<any>
  ) {}
  ...
}

Y con estas dos referencias, lo único que tenemos que hacer para completar nuestra directiva es añadir un operador tap a continuación del map para ejecutar la lógica de renderizado.

export class ShowForRolesDirective implements OnInit, OnDestroy {
  ...
  ngOnInit(): void {
    this.sub = this.authService.user$.pipe(
      map((user) => Boolean(user && this.allowedRoles?.includes(user.role))),
      tap((hasRole) =>
          hasRole
            ? this.viewContainerRef.createEmbeddedView(this.templateRef)
            : this.viewContainerRef.clear()
      )
    ).subscribe();
  }
  ...
}

Si el usuario tiene el rol, usamos el método createEmbeddedView del contenedor para renderizar el template.
Y si no lo tiene, llamamos al método clear del contenedor, para asegurarnos que el contenedor no tiene nada renderizado, cosa que podría pasar si el usuario ve degradados sus permisos a lo largo del uso de la aplicación.

Y con esto ya tendríamos nuestra directiva terminada, cuyo código completo quedaría de la siguiente manera:

@Directive({
  selector: '[appShowForRoles]',
})
export class ShowForRolesDirective implements OnInit, OnDestroy {
  @Input('appShowForRoles') allowedRoles?: Role[];
  private sub?: Subscription;

  constructor(
    private authService: AuthService,
    private viewContainerRef: ViewContainerRef,
    private templateRef: TemplateRef<any>
  ) {}
  ngOnInit(): void {
    this.sub = this.authService.user$
      .pipe(
        map((user) => Boolean(user && this.allowedRoles?.includes(user.role))),
        distinctUntilChanged(), // <--- incluido para ejecutar la lógica de renderizado solo si cambia resultado de la condicion anterior.
        tap((hasRole) =>
          hasRole
            ? this.viewContainerRef.createEmbeddedView(this.templateRef)
            : this.viewContainerRef.clear()
        )
      )
      .subscribe();
  }
  ngOnDestroy(): void {
    this.sub?.unsubscribe();
  }
}

Una vez tenemos lista nuestra directiva solo nos queda declararla y exportarla desde un módulo de nuestra aplicación. (o marcarla como standalone en v14+)

@NgModule({
  declarations: [..., ShowForRolesDirective],
  ...
  exports: [..., ShowForRolesDirective],
})
export class AuthModule {}

A continuación importar este módulo en el módulo que declare el componente en el que la queramos usar.

@NgModule({
  declarations: [HeaderComponent, ... ],
  imports: [..., AuthModule],
})
export class MyOtherModule {}

Y por último ya podríamos usar nuestra directiva aplicándola directamente en el elemento que queramos mostrar condicionalmente, indicando en la asignación el array con el listado de roles para los que mostrar dicho elemento.

<a *appShowForRoles="['Accountant', 'Manager']" routerLink="/accounting">Contabilidad</a>

Conclusiones Finales

Aunque RBAC en el frontend no podemos considerarlo como un sistema de seguridad como tal usando las guardas, como hemos visto, podemos conseguir un nivel básico de protección contra el usuario común limitándoles el acceso a las diferentes rutas de la aplicación.
Y haciendo uso de las directivas estructurales podemos proporcionarles adicionalmente una mejor experiencia de usuario, mostrándoles únicamente aquellos elementos y/o enlaces con los que su rol les permita interactuar.

Si deseas apoyar la creación de más contenido de este tipo, puedes hacerlo a través nuestro Paypal

DEV Community: akotech

Angular 17 - Nuevo Control de Flujo Integrado.

@‍if (condition)

@‍else

@‍else if

@‍switch (expression)

@‍default

Mejor Inferencia de Tipos

@‍for (item of iterable; track expression)

track

Propiedades del bucle

@‍empty

Migración automática

Conclusión

@Input ({ transform })

@Input que no son string

La solución naíf

Usando un setter

Las funciones transformadoras (16.1+)

Funciones ya incluidas en el framework

Precaución al usarlas

Otros usos

Conclusión

Obtener parámetros de la URL como @Input (Angular 16+)

Tipos principales de información en las Rutas

Procedimiento Tradicional

Nuevo Procedimiento

¿Cómo activarlo?

Orden de prioridad

Consideraciones a tener en cuenta

Los valores de los @Input no están asegurados hasta ngOnInit

Podemos perder la reactividad en rutas reutilizables

Para casos complejos mejor usar inputs como Señales (v17.1+)

A simple vista no sabemos de donde procede el valor del Input

Conclusión

Cómo prevenir el abandono accidental de una ruta gracias a la guarda canDeactivate

¿Qué es una guarda?

¿Cómo crear una guarda?

La Guarda CanDeactivate

Ejemplo de ruta con Formulario

Crear una guarda Reutizable

EXTRA window:beforeunload

Conclusión

Cómo Deshabilitar Controles en un Formulario Reactivo

Conceptos Básicos

Usando valueChanges

Creando una directiva personalizada

Usando [attr.disabled] y por qué no me gusta como opción.

Conclusiones Finales

Control de Acceso Basado en Roles(RBAC) en Angular

RBAC en el Desarrollo Web

RBAC en Angular

Guardas del Router

Proceso de Rutas

Tipos de Guardas

Creando nuestra primera Guarda

isLoggedInGuard

hasRoleGuard

Directivas Estructurales

Creando la directiva personalizada *showForRoles

Conclusiones Finales

`@Input` que no son `string`

Los valores de los `@Input` no están asegurados hasta `ngOnInit`

La Guarda `CanDeactivate`

EXTRA `window:beforeunload`

Usando `valueChanges`

Usando `[attr.disabled]` y por qué no me gusta como opción.

Creando la directiva personalizada `*showForRoles`