Listado de la etiqueta: frontend

Router Signals en Angular 21: navegación standalone sin cargar todo el Router

Siempre que necesitaba saber si una ruta estaba activa en Angular, inyectaba el Router completo y me suscribía a los eventos. En componentes simples de navegación, era matar moscas a cañonazos. Angular 21 introduce funciones standalone que devuelven Signals — cargás exactamente lo que necesitás, sin más.

El problema con inyectar el Router entero

// ❌ Antes: inyectar todo el Router para saber si una ruta está activa
import { Router, NavigationEnd } from '@angular/router';
import { filter } from 'rxjs/operators';

@Component({ ... })
export class SidebarComponent implements OnInit, OnDestroy {
  isDashboard = false;
  private sub = Subscription.EMPTY;

  constructor(private router: Router) {}

  ngOnInit() {
    this.sub = this.router.events
      .pipe(filter(e => e instanceof NavigationEnd))
      .subscribe(() => {
        this.isDashboard = this.router.url === '/dashboard';
      });
  }

  ngOnDestroy() { this.sub.unsubscribe(); }
}

isActive(): la función standalone con Signal

// ✅ Angular 21: función standalone, devuelve Signal
import { Component } from '@angular/core';
import { isActive } from '@angular/router';
import { RouterLink } from '@angular/router';

@Component({
  selector: 'app-sidebar',
  standalone: true,
  imports: [RouterLink],
  template: `
    <nav>
      <a routerLink="/dashboard" [class.active]="isDashboard()">Dashboard</a>
      <a routerLink="/usuarios" [class.active]="isUsuarios()">Usuarios</a>
      <a routerLink="/reportes" [class.active]="isReportes()">Reportes</a>
    </nav>
  `
})
export class SidebarComponent {
  isDashboard = isActive('/dashboard', { exact: true });
  isUsuarios  = isActive('/usuarios');
  isReportes  = isActive('/reportes');
}

Otras funciones standalone del Router

import { isActive, currentRoute, routeParams, queryParams, routeData } from '@angular/router';

@Component({ ... })
export class DetalleComponent {
  // Parámetros de ruta como Signal — sin ActivatedRoute
  params     = routeParams();
  usuarioId  = computed(() => this.params()['id']);

  // Query params como Signal
  qParams = queryParams();
  pagina  = computed(() => Number(this.qParams()['page'] ?? 1));

  // Data estática de la ruta
  data   = routeData();
  titulo = computed(() => this.data()['titulo'] ?? 'Sin título');
}

Navigation API experimental (v21.0)

// app.config.ts — habilitar Navigation API experimental
import { provideExperimentalNavigationApi } from '@angular/common';

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

Location strategies: control sobre el trailing slash (v21.2)

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withRouterConfig({
      trailingSlash: 'never'  // 'always' | 'never' | 'preserve'
    }))
  ]
};

Por qué el tree-shaking importa

Con las funciones standalone, el bundler puede eliminar del bundle final todo el código del Router que no se usa. Si solo usás isActive y routeParams, el resto no viaja al usuario. En aplicaciones grandes esto puede reducir el bundle inicial de forma significativa — especialmente relevante en conexiones móviles lentas.


Artículo anterior: Vitest reemplaza a Karma y Angular habla con tu IA: el nuevo ecosistema de herramientas | Serie Angular 20 → 21.2 | Próximo: Guía práctica: cómo migré un proyecto de Angular 19/20 a Angular 21.2 sin morir en el intento →

Vitest reemplaza a Karma y Angular habla con tu IA: el nuevo ecosistema de herramientas

Karma murió. No es una exageración: Angular 21 lo retiró como runner por defecto y lo reemplazó con Vitest. Y junto con eso llegó algo que no esperaba: soporte nativo para que asistentes de IA entiendan la estructura de un proyecto Angular en tiempo real con el protocolo MCP.

Por qué Karma quedó obsoleto

Karma fue el runner de tests de Angular durante más de una década. Abre un browser real, corre los tests ahí y reporta los resultados. Funcional, pero lento, difícil de configurar en CI y sin soporte nativo para el modelo Zoneless. En el mundo actual de testing, donde queremos ejecución rápida y paralela, Karma no competía.

Vitest: el nuevo estándar

  • Ejecución en paralelo: múltiples workers, tests más rápidos
  • Sin browser real: usa jsdom o happy-dom — más rápido y estable en CI
  • Soporte nativo Zoneless: sin el overhead de Zone.js en los tests
  • Watch mode inteligente: solo re-ejecuta los tests afectados por cambios
  • API compatible con Jest: si venís de Jest, la curva es mínima
# Configurar Vitest en un proyecto Angular 21 existente
ng generate @angular/build:vitest

# O en angular.json
{
  "test": {
    "builder": "@angular/build:unit-test",
    "options": {
      "runner": "vitest"
    }
  }
}

Tests con Vitest + Signals

import { TestBed } from '@angular/core/testing';
import { provideZonelessChangeDetection } from '@angular/core';
import { describe, it, expect } from 'vitest';
import { ContadorComponent } from './contador.component';

describe('ContadorComponent', () => {
  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [ContadorComponent],
      providers: [provideZonelessChangeDetection()]
    });
  });

  it('debería incrementar el contador', () => {
    const fixture = TestBed.createComponent(ContadorComponent);
    const comp = fixture.componentInstance;

    expect(comp.contador()).toBe(0);
    comp.incrementar();
    // Sin detectChanges() manual — Signals actualizan sincrónicamente
    expect(comp.contador()).toBe(1);
    expect(comp.doble()).toBe(2);
  });

  it('debería renderizar el valor actualizado', async () => {
    const fixture = TestBed.createComponent(ContadorComponent);
    fixture.detectChanges();

    const button = fixture.nativeElement.querySelector('button');
    button.click();

    await fixture.whenStable();
    expect(fixture.nativeElement.querySelector('p').textContent).toContain('1');
  });
});

ng mcp: Angular habla con tu IA

La feature que más me sorprendió de Angular 21.2: soporte nativo para el Model Context Protocol (MCP). Con un solo comando, Angular expone la estructura del proyecto a asistentes de IA locales para que entiendan el contexto en tiempo real.

# Levantar el servidor MCP de Angular
ng mcp

# Configuración en .cursor/mcp.json o claude_desktop_config.json:
{
  "mcpServers": {
    "angular": {
      "command": "ng",
      "args": ["mcp"],
      "cwd": "/path/to/mi-proyecto-angular"
    }
  }
}

Con el servidor MCP activo, el asistente de IA tiene acceso al árbol de componentes, rutas del router, servicios y sus dependencias, grafo de Signals y configuración del proyecto. En la práctica: cuando le pedís al asistente que genere un componente, lo hace correctamente dentro del contexto de tu proyecto — no código genérico que hay que adaptar.

Migrar de Karma a Vitest

# 1. Desinstalar Karma
npm uninstall karma karma-chrome-launcher karma-jasmine karma-jasmine-html-reporter

# 2. Ejecutar el schematic de migración
ng generate @angular/build:vitest

# 3. Verificar tests
ng test

# Los tests de Jasmine son mayormente compatibles
# Solo ajustar: jasmine.SpyObj → vi.Mocked cuando sea necesario

Artículo anterior: Novedades del template en Angular 21: regex, spread, instanceof y más | Serie Angular 20 → 21.2 | Próximo: Router Signals en Angular 21: navegación standalone sin cargar todo el Router →

Novedades del template en Angular 21: regex, spread, instanceof y más

Angular 21 trajo varias novedades al template que parecen pequeñas pero cambian el día a día. Regex literals directamente en el HTML, spread operator en arrays y objetos, instanceof en expresiones, exhaustive switch blocks. Menos lógica empujada al componente, más expresividad en el template.

Regex literals en el template (v21)

Antes, si quería filtrar con una expresión regular en el template, tenía que crear una propiedad en el componente. Ahora puedo usar el literal directamente.

// Antes: declarar el regex en el componente
// emailRegex = /@empresa\.com$/;

// Ahora: regex literal directo en el template
@if (userEmail() | match: /@empresa\.com$/) {
  <span class="badge">Email corporativo</span>
}

@if (/^\d{8}-\d$/.test(cuit())) {
  <span class="valid">CUIT válido</span>
}

Spread operator en templates (v21.1)

// Spread de arrays
@let todosLosItems = [...itemsActivos(), ...itemsArchivados()];

@for (item of todosLosItems; track item.id) {
  <li>{{ item.nombre }}</li>
}

// Spread de objetos en property binding
<mi-componente [config]="{ ...configBase(), ...configOverride() }" />

instanceof en expresiones del template (v21.2)

// Antes: casteo forzado en el componente
// get esError(): boolean { return this.resultado() instanceof Error; }

// Ahora: directo en el template
@if (resultado() instanceof Error) {
  <app-error-display [error]="resultado()" />
} @else if (resultado() instanceof Array) {
  <app-lista [items]="resultado()" />
} @else {
  <app-detalle [dato]="resultado()" />
}

Exhaustive switch blocks (v21.2)

type Estado = 'activo' | 'pausado' | 'eliminado';

@switch (usuario.estado()) {
  @case ('activo') {
    <span class="badge green">Activo</span>
  }
  @case ('pausado') {
    <span class="badge yellow">Pausado</span>
  }
  @case ('eliminado') {
    <span class="badge red">Eliminado</span>
  }
  // Sin @default: el compilador verifica que todos los casos estén cubiertos
}

Multiple switch case matching (v21.1)

// Múltiples valores en un @case
@switch (rol()) {
  @case ('admin', 'superadmin') {
    <app-panel-admin />
  }
  @case ('editor', 'revisor') {
    <app-panel-editor />
  }
  @default {
    <app-panel-usuario />
  }
}

@let: variables locales en el template

// Sin @let: el Signal se evalúa 3 veces
<p>Hola, {{ usuario().nombre }}</p>
<p>Email: {{ usuario().email }}</p>
<img [src]="usuario().avatar" />

// Con @let: evaluación única, más eficiente
@let u = usuario();
<p>Hola, {{ u.nombre }}</p>
<p>Email: {{ u.email }}</p>
<img [src]="u.avatar" />

ngTemplateOutlet con injector personalizado (v21.2)

<ng-container
  [ngTemplateOutlet]="miTemplate"
  [ngTemplateOutletContext]="{ $implicit: datos() }"
  [ngTemplateOutletInjector]="injectorPersonalizado">
</ng-container>

Artículo anterior: Signal Forms: cuando los formularios reactivos finalmente tienen sentido | Serie Angular 20 → 21.2 | Próximo: Vitest reemplaza a Karma y Angular habla con tu IA: el nuevo ecosistema de herramientas →

Signal Forms: cuando los formularios reactivos finalmente tienen sentido

Los formularios reactivos de Angular siempre me parecieron demasiado verbosos. Crear un FormGroup, definir los FormControl, suscribirse a valueChanges, acordarse de hacer unsubscribe… Signal Forms simplifica todo eso. El formulario es sincrónico, tipado y reactivo sin esfuerzo.

El problema con FormGroup y FormControl

// ❌ FormGroup clásico: verboso y con memory leaks potenciales
import { FormBuilder, Validators } from '@angular/forms';

@Component({ ... })
export class LoginClasico implements OnDestroy {
  private destroy$ = new Subject<void>();

  form = this.fb.group({
    email: ['', [Validators.required, Validators.email]],
    password: ['', [Validators.required, Validators.minLength(8)]]
  });

  constructor(private fb: FormBuilder) {
    this.form.valueChanges
      .pipe(takeUntil(this.destroy$))
      .subscribe(val => console.log(val));
  }

  ngOnDestroy() { this.destroy$.next(); this.destroy$.complete(); }
}

Signal Forms: la forma moderna

// ✅ Signal Forms: sincrónico, tipado, sin suscripciones
import { Component } from '@angular/core';
import { form, field } from '@angular/forms/signals';
import { Validators } from '@angular/forms';

@Component({
  selector: 'app-login',
  template: `
    <form (ngSubmit)="onSubmit()">
      <div>
        <label>Email</label>
        <input type="email" [formField]="loginForm.controls.email" />
        @if (loginForm.controls.email.invalid() && loginForm.controls.email.touched()) {
          <span class="error">Email inválido</span>
        }
      </div>
      <div>
        <label>Password</label>
        <input type="password" [formField]="loginForm.controls.password" />
      </div>
      <button type="submit" [disabled]="!loginForm.valid()">Ingresar</button>
    </form>
  `
})
export class LoginComponent {
  loginForm = form({
    email: field('', [Validators.required, Validators.email]),
    password: field('', [Validators.required, Validators.minLength(8)])
  });

  onSubmit() {
    if (this.loginForm.valid()) {
      const { email, password } = this.loginForm.value();
      console.log('Login con:', email);
    }
  }
}

Formularios dinámicos con Signal Forms

import { Component, computed } from '@angular/core';
import { form, field } from '@angular/forms/signals';
import { Validators } from '@angular/forms';

@Component({
  selector: 'app-registro',
  template: `
    <form>
      <input type="text" [formField]="registroForm.controls.nombre" placeholder="Nombre" />
      <input type="email" [formField]="registroForm.controls.email" placeholder="Email" />

      <label>
        <input type="checkbox" [formField]="registroForm.controls.esEmpresa" />
        Registro como empresa
      </label>

      @if (registroForm.controls.esEmpresa.value()) {
        <input type="text" [formField]="registroForm.controls.razonSocial" placeholder="Razón Social" />
        <input type="text" [formField]="registroForm.controls.cuit" placeholder="CUIT" />
      }

      <p>Completado: {{ camposCompletados() }}/{{ totalCampos() }}</p>
      <button [disabled]="!registroForm.valid()">Registrarse</button>
    </form>
  `
})
export class RegistroComponent {
  registroForm = form({
    nombre: field('', Validators.required),
    email: field('', [Validators.required, Validators.email]),
    esEmpresa: field(false),
    razonSocial: field(''),
    cuit: field('')
  });

  camposCompletados = computed(() =>
    Object.values(this.registroForm.controls)
      .filter(c => c.value() !== '' && c.value() !== false).length
  );

  totalCampos = computed(() =>
    this.registroForm.controls.esEmpresa.value() ? 5 : 3
  );
}

Migración gradual: FormGroup y Signal Forms coexisten

No hay que reescribir todo de una vez. Angular 21 permite tener ambos sistemas en paralelo. Mi estrategia: nuevos formularios con Signal Forms, los existentes se migran cuando hay un motivo concreto (bug, refactor, mejora de rendimiento).

Lo que más me gusta de Signal Forms

No tener que pensar en el ciclo de vida de las suscripciones. Con FormGroup siempre había ese riesgo latente de un memory leak por un valueChanges sin unsubscribe. Con Signal Forms, el formulario es un valor reactivo sincrónico: lo leo con loginForm.value(), verifico con loginForm.valid(), y Angular maneja el resto. Menos código, menos bugs.


Artículo anterior: Adiós Zone.js: cómo Angular 21 cambió la detección de cambios para siempre | Serie Angular 20 → 21.2 | Próximo: Novedades del template en Angular 21: regex, spread, instanceof y más →

Angular 21: el cambio de paradigma que no podés ignorar

Cuando Angular anunció que las Signals pasaban de experimental a estables, lo tomé como «otra API más para aprender». Me equivoqué. No era una API nueva: era un cambio de paradigma que afecta cómo se detectan cambios, cómo se construyen formularios, cómo funciona el router y hasta cómo escribimos los tests. Angular 21 consolida todo eso. Esta serie es lo que me hubiera gustado tener cuando arranqué la migración.

El contexto: por qué Angular cambió tan profundamente

Durante años, Angular usó Zone.js para detectar cuándo algo cambiaba en la aplicación y disparar la actualización del DOM. Zone.js intercepta todas las operaciones asíncronas — setTimeout, promesas, eventos — y notifica a Angular para que re-evalúe la vista. Funcionaba. Pero tenía un costo: bundle más grande, detección de cambios innecesaria, y comportamiento difícil de predecir en aplicaciones complejas.

Las Signals cambian el modelo de raíz: en lugar de «revisar todo cuando algo asíncrono ocurre», ahora cada valor sabe exactamente quién depende de él y notifica solo a esos dependientes. Es reactivo de verdad, no reactivo por polling.

Qué cambió de Angular 20 a Angular 21

ÁreaAntes (v20)Angular 21
Detección de cambiosZone.js por defectoZoneless por defecto en proyectos nuevos
FormulariosFormGroup / FormControlSignal Forms: form() y field()
RouterInyección de Router classFunciones standalone con Signals
TestingKarma + JasmineVitest por defecto
TemplateSintaxis estándarRegex literals, spread operator, instanceof
Tooling IAManualSoporte MCP nativo (ng mcp)
HTTPHttpClient observablehttpResource con Signals

httpResource: el nuevo cliente HTTP basado en Signals

Una de las novedades más destacadas de v21.2: httpResource. La respuesta de Angular a «¿cómo hago una llamada HTTP y el resultado sea un Signal?»

import { Component, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';

@Component({
  selector: 'app-usuarios',
  template: `
    @if (usuarios.isLoading()) {
      <p>Cargando...</p>
    } @else if (usuarios.error()) {
      <p>Error: {{ usuarios.error()?.message }}</p>
    } @else {
      <ul>
        @for (u of usuarios.value(); track u.id) {
          <li>{{ u.nombre }}</li>
        }
      </ul>
    }
  `
})
export class UsuariosComponent {
  // Sin subscribe, sin async pipe — el resultado es un Signal
  usuarios = httpResource<Usuario[]>('/api/usuarios');

  // Con parámetros reactivos: se re-fetcha cuando cambia el signal
  filtro = signal('admin');
  usuariosFiltrados = httpResource<Usuario[]>(() =>
    `/api/usuarios?rol=${this.filtro()}`
  );
}

La hoja de ruta de esta serie

  1. Este artículo: el panorama general del salto v20 → v21
  2. Adiós Zone.js: detección de cambios Zoneless en profundidad
  3. Signal Forms: formularios reactivos que finalmente tienen sentido
  4. Novedades del template: regex, spread, instanceof y más
  5. Vitest reemplaza Karma + soporte MCP nativo
  6. Router Signals: navegación standalone sin cargar todo el Router
  7. Guía práctica de migración de Angular 19/20 a Angular 21.2

Si estás trabajando con Angular en proyectos .NET — como yo, donde el backend es ASP.NET y el frontend es Angular — estos cambios son especialmente relevantes. La adopción de Signals reduce considerablemente el gap conceptual entre el modelo reactivo del frontend y los patrones async/await del backend. Empecemos.


Serie Angular 20 → 21.2 | Próximo: Adiós Zone.js: cómo Angular 21 cambió la detección de cambios para siempre →