Forem: Angular Firebase

MCP Skills vs MCP Tools: La forma correcta de configurar MCP Server

Antonio Cardenas — Sun, 22 Mar 2026 08:59:35 +0000

Las skills y las herramientas MCP no son lo mismo — y confundirlos tiene un costo real. Aprende la diferencia, los problemas reales y cómo combinarlos para un flujo de trabajo agéntico que sí funcione.

Todo el mundo habla de MCP. Todo el mundo habla de skills.

La mayoría los usa como sinónimos — y ese es exactamente el problema.

No son lo mismo. No resuelven el mismo problema. Y si usas el incorrecto, lo vas a sentir: alucinaciones, contexto desbordado, agentes que pierden el hilo y flujos de trabajo que se rompen bajo presión.

Vamos a resolverlo.

El modelo mental

Piénsalo como una cocina.

Las herramientas MCP son tus electrodomésticos e ingredientes — el horno, el refrigerador, los vegetales frescos. Capacidad pura. Sin ellos, no se cocina nada.

Los skills son tus recetas — las instrucciones paso a paso que le dicen a un chef exactamente cómo convertir esos ingredientes en algo bueno. Sin ellas, tienes poder, pero sin dirección.

Un agente con solo herramientas MCP puede hacer cosas, pero no necesariamente sabe cómo hacerlas bien. Un agente con solo skills tiene excelentes instrucciones, pero no puede actuar sobre ellas.

Necesitas los dos.

¿Qué es una herramienta MCP?

El Model Context Protocol es un estándar abierto — ahora bajo la Agentic AI Foundation de la Linux Foundation — que le da a los agentes de IA una forma estandarizada de conectarse a sistemas externos: bases de datos, APIs, sistemas de archivos, GitHub, Slack, tu Angular CLI.

Cuando conectas un servidor MCP a tu cliente —ya sea Claude Code, la CLI de Gemini o un agente personalizado—, este accede a un conjunto de herramientas deterministas y tipadas. Cada herramienta tiene un esquema claro de entrada y salida. Cuando el agente la llama, se ejecuta — sin interpretación, sin riesgo de alucinación a nivel de ejecución. Es una llamada de API estructurada, no una sugerencia.

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

MCP es como el agente alcanza fuera de sí mismo. Es el sistema nervioso.

Usa MCP cuando el agente necesite:

Leer o escribir en un sistema real (base de datos, sistema de archivos, API)
Ejecutar acciones con entradas y salidas claras y auditables.
Conectarse a herramientas que no controlas
Integrar múltiples servicios a través de una interfaz consistente.

¿Qué es un skill?

Un skill es una carpeta que contiene un archivo Markdown (con frontmatter YAML) más scripts y recursos opcionales. No es ejecutable por sí solo — es un playbook.

Cuando la solicitud de un usuario coincide con los criterios de relevancia de un skill, el agente carga esas instrucciones dinámicamente y las sigue. Es como darle al agente memoria procedural de nivel experto, bajo demanda.

---
name: angular-component-review
description: Revisar componentes Angular para cumplimiento de Signals y arquitectura standalone
---

# Revisión de Componente Angular

Al revisar un componente Angular:
1. Verificar que todo el estado use `signal()` o `computed()` — nunca mutación directa
2. Confirmar que el componente es `standalone: true`
3. Asegurar que no queden dependencias de `NgModule`
4. Validar que se use `@if` / `@for` en lugar de `*ngIf` / `*ngFor`

El agente lo carga solo cuando es relevante. Cuando no lo es — no te cuesta nada.

Usa un skill cuando el agente lo necesite:

Seguir un proceso o checklist consistente.
Aplicar experiencia específica del dominio (tus estándares de código, criterios de revisión).
Codificar conocimiento que no cambia frecuentemente.
Reutilizar el mismo flujo de trabajo en distintas conversaciones.

Los desventajas reales

Aquí es donde la mayoría de las guías se detienen. No deberían.

MCP: El Impuesto de Tokens

Cada herramienta MCP que conectas inyecta su esquema completo en la ventana de contexto antes de que el agente procese un solo mensaje. Cada herramienta cuesta 550–1,400 tokens. Conecta GitHub, Slack y Sentry y estás mirando 55,000 tokens quemados de entrada — más de un cuarto del límite de 200k de Claude antes de hacer cualquier trabajo real.

Un equipo reportó conectar tres servidores MCP y consumir 143,000 de 200,000 tokens solo en definiciones de herramientas. Al agente le quedaban 57,000 tokens para la conversación real.

Y si usas Gemini con su ventana de contexto de 1M+ tokens, podrías pensar que puedes ignorar esto. No lo hagas. Incluso si te sobra espacio, inyectar 55,000 tokens de esquema JSON crudo en cada iteración de la conversación aumenta la latencia, incrementa los costos de la API y diluye el enfoque del modelo.

La buena noticia: clientes modernos como Claude Code y la CLI de Gemini han adoptado el progressive discovery para MCP — cargando solo nombres y descripciones de herramientas al inicio (~20–50 tokens cada una), y obteniendo los esquemas completos solo cuando el agente realmente necesita una herramienta. El overhead de tokens cayó ~85%. Pero esto solo funciona si tu configuración MCP está preparada para usarlo — y la mayoría todavía no lo está.

Skills: El Problema de la Desactualización

Los skills son archivos Markdown. No se actualizan solos. Si tus patrones de Angular evolucionan — digamos que migraste de setInput() a la nueva API declarativa en Angular 20 — tu Skill sigue enseñando la forma antigua hasta que alguien lo actualice manualmente.

Cuantos más skills creas, mayor es la carga de mantenimiento. Y si un skill está sutilmente equivocado, el agente lo seguirá con confianza — sin error, solo output silenciosamente incorrecto.

Ambos: El problema de selección

Dale a un agente demasiadas herramientas o demasiados skills y empieza a tomar las decisiones equivocadas — llama a la herramienta incorrecta, activa el playbook equivocado, o los combina de formas que producen instrucciones contradictorias. Los expertos recomiendan no superar 10–15 herramientas MCP activas al mismo tiempo.

Cómo combinarlos

El patrón más poderoso es usarlos como capas:

Capa 1 — MCP provee acceso.
Conecta solo lo que el agente genuinamente necesita para la tarea actual. Angular CLI, una base de datos, un sistema de archivos. Mantenlo simple.

Capa 2 — Skills proveen experiencia.
Crea un Skill que le diga al agente cómo usar esas herramientas en tu contexto específico. No solo "ejecuta el Angular CLI" — sino "al migrar un componente, ejecuta ng generate con estos flags, luego valida contra estos patrones."

Capa 3 — Skills pueden orquestar MCP.
Un skill puede definir un flujo de trabajo multipaso que llame a múltiples herramientas MCP en secuencia. Ejemplo: un skill de "Deploy & Notify" que usa el MCP de GitHub para hacer push, un MCP de CI/CD para lanzar el build, y un MCP de Slack para notificar al equipo — todo bajo un playbook coherente.

---
name: angular-migration-workflow
description: Flujo completo para migrar un componente Angular a patrones v21
---

# Flujo de Migración

1. Usa el MCP del Angular CLI para verificar la versión actual del componente
2. Ejecuta `ng update` para el paquete afectado
3. Aplica el schematic de migración zoneless
4. Revisa el output contra el Skill de angular-component-review
5. Ejecuta los tests y reporta resultados

Guía de Decisión Práctica

Situación	Usar
Necesito consultar una base de datos real	MCP
Necesito seguir un checklist de code review	Skill
Necesito hacer push a GitHub	MCP
Necesito aplicar el formato de commits de mi equipo	Skill
Necesito leer una API en vivo	MCP
Necesito enseñarle al agente mis reglas de arquitectura Angular	Skill
Necesito acceso Y proceso consistente	Ambos

Mejorando el Flujo de Trabajo

Algunos patrones que realmente funcionan en producción:

1. Un servidor MCP por dominio. No cargues todo al mismo tiempo. Crea configuraciones separadas para "desarrollo Angular", "despliegue" y "comunicación" — y activa solo la que necesitas para cada sesión.

2. Versiona tus Skills como código. Ponlos en tu repositorio. Revísalos cuando actualices tu stack. Un Skill para patrones de Angular 19 te va a perjudicar activamente en Angular 21.

3. Usa Skills para escribir guardrails de MCP. En lugar de confiar en que el agente sepa cuándo llamar a una acción MCP destructiva, escribe un Skill que diga explícitamente: "Antes de ejecutar cualquier ng update, siempre crea un branch de git primero."

4. Mide tu presupuesto de contexto. Antes de que el agente haga cualquier trabajo real, conoce cuántos tokens consume tu configuración MCP. Si superas el 30% de tu ventana de contexto solo en definiciones de herramientas, tienes un problema de configuración.

5. Deja que el agente mantenga los Skills simples. Para áreas de cambio rápido — como mantener actualizadas las convenciones de versión de Angular de tu equipo — deja que el agente actualice el archivo Skill cuando se lo indiques. Es más rápido que hacerlo manualmente y mantiene el Skill honesto.

La conclusión

MCP les da a los agentes la capacidad de actuar. Los skills les enseñan cómo actuar bien.

El debate de "MCP vs Skills" es falso. La pregunta real es: ¿necesitas acceso, experiencia, o ambos?

En la mayoría de los flujos de trabajo reales con Angular, necesitas los dos. Un agente que puede ejecutar tu CLI, pero no conoce tu arquitectura, es solo una forma más rápida de cometer los mismos errores. Un agente que conoce tus patrones, pero no puede tocar tu proyecto real, es solo un buscador caro.

Usados juntos, con límites claros y configuración lean, son la base del desarrollo agéntico que realmente funciona.

Anteriormente escribí sobre Angular 21, MCP y el fin de las migraciones manuales — un buen punto de partida si eres nuevo en la configuración del servidor MCP para Angular.

Actualizando a Angular 21 usando ng mcp

Antonio Cardenas — Sat, 13 Dec 2025 07:47:54 +0000

Angular 21 introduce el servidor Model Context Protocol (MCP). Aprende cómo conectar tu editor de IA directamente al CLI de Angular para automatizar actualizaciones, refactorizaciones y cambios arquitectónicos como Zoneless.

Solíamos tratar a la IA como a un extraño inteligente. Copiábamos y pegábamos mensajes de error o contenidos de archivos en ChatGPT, esperando que entendiera la arquitectura de nuestro proyecto. Era útil, pero estaba ciega.

Con Angular 21, ese extraño se ha mudado a tu casa.

El lanzamiento del servidor MCP del CLI de Angular (ng mcp) marca un cambio fundamental en la forma en que mantenemos las aplicaciones.

No es solo un nuevo comando; es un protocolo que permite a los agentes de IA (como Cursor, Windsurf o VS Code Copilot) "entrevistar" a tu proyecto, entender tus restricciones específicas y ejecutar migraciones que realmente compilen.

He aquí por qué la era de la "migración manual" podría estar terminando, y cómo sobrevivir al nuevo flujo de trabajo agéntico.

¿Qué es MCP? (El "puerto USB" para la IA)

El Model Context Protocol (MCP) es un estándar abierto que permite a los modelos de IA conectarse a herramientas y datos locales.

Piénsalo de esta manera:

Antes de MCP: Pegabas angular.json en el chat para que la IA conociera tu estructura de archivos.

Después de MCP: La IA simplemente pregunta al CLI de Angular: "Oye, lista todos los proyectos en este espacio de trabajo", y el CLI responde con la estructura exacta, los objetivos de compilación y las dependencias de bibliotecas.

En Angular 21, el CLI es un servidor MCP. Expone "herramientas" que tu editor de IA puede llamar directamente.

Configuración: 5 minutos para un Angular "agéntico"

La configuración es sorprendentemente trivial porque el equipo de Angular la integró directamente en el CLI.

1. Inicializar el servidor.

En tu terminal del espacio de trabajo de Angular 21:

ng mcp

Este comando no inicia un demonio; genera los fragmentos de configuración que necesitas para tu IDE específico.

2. Conectar tu editor (por ejemplo, Cursor).

Si estás usando Cursor (que probablemente deberías estar usando si te interesa MCP), crea o edita .cursor/mcp.json o, si usas Antigravity, crea o edita .gemini/antigravity/mcp.json en la raíz de tu proyecto:

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

Para verificar la configuración de CURSOR, haz clic en los tres puntos en la esquina superior derecha y selecciona "Agent Settings".

Luego haz clic en "Tools & MCP". Si todo está configurado correctamente, deberías ver angular listado como servidor MCP instalado con el nombre de la herramienta como "ai_tutor".

Para verificar la configuración de Antigravity, haz clic en los tres puntos en la esquina superior derecha y selecciona "MCP Servers".

Luego verás listado 'angular-cli' y podrás gestionar las herramientas, teniendo la capacidad de habilitarlas o deshabilitarlas.

[NOTE]
La flag -y es crucial para evitar que el mensaje "Press y to install" bloquee el proceso en segundo plano.

Herramientas disponibles

El servidor MCP del CLI de Angular proporciona varias herramientas para ayudarte en tu flujo de trabajo de desarrollo. Por defecto, las siguientes herramientas están habilitadas:

Herramienta	Solo lectura	Solo local
`ai_tutor`	✅	❌
`find_examples`	✅	❌
`get_best_practices`	✅	❌
`list_projects`	✅	✅
`angular.json`	✅	✅
`onpush_zoneless_migration`	✅	✅
`search_documentation`	✅	❌

Herramientas experimentales

Algunas herramientas se proporcionan en estado experimental / vista previa. Puedes habilitarlas explícitamente:

Herramienta	Solo lectura	Solo local
`modernize`	✅	❌

La "killer app": Migraciones conscientes del contexto

¿Por qué pasar por este problema? Porque las migraciones conscientes del contexto superan con creces a los esquemáticos estándar.

Los scripts tradicionales de ng update son rígidos. Siguen una lógica estricta de "Si A, entonces B". Si tu arquitectura es rara (y seamos honestos, cada arquitectura empresarial es rara), el script se rompe o produce código que tienes que reescribir.

El servidor MCP expone herramientas que cambian esta dinámica:

Herramienta 1: `get_best_practices`

La IA puede obtener las recomendaciones actuales del equipo de Angular. No alucinará que deberías usar SharedModule en 2025 porque "lo leyó en un blog de 2021". Pregunta al CLI por la verdad fundamental.

Herramienta 2: `onpush_zoneless_migration`

Esta es la grande para la v21. En lugar de cambiar ciegamente ChangeDetectionStrategy.Default a OnPush, la IA utiliza esta herramienta para analizar tu gráfico de dependencias.

El flujo de trabajo:

Tú: "Oye, quiero migrar user-profile.ts a Zoneless. Comprueba si es seguro."

IA (Pensamiento Interno): Necesito comprobar el estilo del componente. Llamaré a list_projects para encontrar la raíz, luego leeré el archivo.

IA (Pensamiento Interno): Veo una suscripción a Observable en ngOnInit. Comprobaré get_best_practices para manejar asincronía en Zoneless.

IA (Acción): "Detecté una suscripción no gestionada. En Zoneless, esto no activará un renderizado. Recomiendo convertir este observable user$ a una Signal usando toSignal() antes de cambiar la estrategia."

No solo aplica una solución; negocia la refactorización contigo basándose en la lógica interna del marco.

Herramienta 3: `search_documentation`

La IA no necesita adivinar las firmas de la API. Consulta el índice de documentación local fuera de línea proporcionado por el servidor MCP.

Escenario del mundo real: La limpieza "Legacy"

Digamos que tienes un componente al estilo Angular 17 usando HttpClientModule (enfoque obsoleto) y RxJS para estado simple.

Prompt a Cursor (con MCP activo):

"Refactoriza dashboard.component.ts para alinearlo con las mejores prácticas de Angular 21. Usa la herramienta get_best_practices para verificar tu plan primero."

Qué sucede:

La IA llama a get_best_practices y aprende que standalone: true, inject() y Signals son el estándar.
Llama a modernize (una herramienta experimental en v21) para ejecutar los esquemáticos estándar.
Limpia manualmente los restos: convirtiendo constructor(private http: HttpClient) a private http = inject(HttpClient).
Convierte tu estado BehaviorSubject a signal.

El resultado es código que parece escrito en v21, no solo parcheado para ejecutarse en v21.

El futuro: Mantenimiento continuo

Este lanzamiento señala un cambio en cómo Google ve el CLI. Ya no es solo una herramienta de construcción; es una interfaz para agentes.

En el futuro cercano, probablemente no "pararemos el desarrollo" para actualizar. Tendremos un agente en segundo plano ejecutándose vía MCP que abre PRs:

"Noté que usaste un ControlValueAccessor aquí. He creado un PR para refactorizar esto a la nueva API de entrada de Signal Forms."

"Angular v22 acaba de salir. He actualizado tu angular.json y verificado tus pruebas vía vitest."

Resumen: No actualices solo.

Si te estás moviendo a Angular 21, no ejecutes simplemente ng update y pelees con los errores de compilación manualmente.

Instala el servidor MCP.
Deja que la IA mapee tu proyecto.
Pídele que planifique la migración por ti.

El código sigue siendo tu responsabilidad, ¿pero el trabajo pesado? Eso pertenece a la máquina ahora.

Migrando Angular 20 a 21: Guía.

Antonio Cardenas — Sat, 13 Dec 2025 07:47:46 +0000

Una guía sin rodeos para actualizar de Angular 20 a 21. Cubre la eliminación de Karma, el nuevo modo Zoneless por defecto, HttpClient automático y cómo arreglar tus compilaciones rotas.

Si pensabas que Angular 20 fue un gran cambio, bienvenido a Angular 21.

Mientras la versión 20 trataba de estabilizar Signals, la versión 21 trata de mejorar la experiencia del desarrollador. Angular ha cambiado fundamentalmente: zone.js es opcional, Karma está muerto y RxJS parece ser reemplazado lentamente.

Esto no es solo una actualización; se siente como todo un ecosistema nuevo. Aquí está lo que se va a romper y cómo arreglarlo.

Lo crítico que detienen todo

Antes de ejecutar ng update, ten en cuenta que tu compilación probablemente fallará si dependes de estos patrones heredados.

1. El Evento de Extinción de Karma (Vitest es el predeterminado)

El choque más inmediato para muchos equipos será ng test. Angular 21 ha cambiado oficialmente Karma por Vitest como el ejecutor de pruebas predeterminado.

Qué se rompe: Si tienes un karma.conf.js personalizado o dependes de complementos/reportadores específicos de Karma, tu suite de pruebas es ahora código heredado.

La solución:

Nuevos proyectos: Obtienes Vitest desde el principio. Es más rápido, más limpio y usa Vite.
Proyectos existentes: No estás obligado a cambiar inmediatamente, pero el final está cerca. El CLI te insistirá.
Migración: Ejecuta el s ng generate @angular/core:karma-to-vitest para intentar una auto-migración. Es notablemente bueno convirtiendo configuraciones estándar, pero los trucos personalizados de Webpack en tu configuración de pruebas necesitarán reescritura manual para Vite.

2. HttpClient está "simplemente ahí".

¿Recuerdas añadir provideHttpClient() a tu app.config.ts o importar HttpClientModule?

El cambio: HttpClient ahora se inyecta por defecto en el inyector raíz.

Qué se rompe:

Si tienes pruebas que simulan HttpClient esperando que no esté allí, podrían fallar.
Si dependes de HttpClientModule para un orden complejo de interceptores en una aplicación mixta NgModule/Standalone, podrías ver cambios sutiles de comportamiento.

La solución: Elimina las llamadas explícitas a provideHttpClient() a menos que estés pasando opciones de configuración (como withInterceptors o withFetch). Limpia tu configuración, pero comprueba el orden de ejecución de tus interceptores.

3. zone.js se ha ido (para nuevas apps).

Las nuevas aplicaciones generadas con ng new excluirán zone.js por defecto.

Qué se rompe: Nada para las aplicaciones existentes (todavía). Tu polyfils.ts seguirá importando Zone.

La advertencia: Si copias y pegas código de un tutorial nuevo de v21 en tu aplicación v20 existente, podría asumir un comportamiento Zoneless (usando menos ChangeDetectorRef, confiando en Signals). Si mezclas los dos paradigmas sin entenderlos, obtendrás errores "changed after checked" o vistas que no se actualizan.

✨ Las nuevas características

Una vez que arregles la compilación, la v21 ofrece algunas mejoras increíbles en la experiencia de desarrollo (DX).

1. Signal Forms (Experimental pero estable)

Esta es la característica que hemos estado esperando. No más espagueti de valueChanges.pipe(...).

import { form, field } from '@angular/forms/signals';

// Definir un modelo de formulario reactivo
const loginForm = form({
  email: field('', [Validators.required, Validators.email]),
  password: field('', [Validators.required])
});

// ¡Accede a los valores directamente como signals!
console.log(loginForm.value().email);

Por qué usarlo: Es seguro en cuanto a tipos por defecto y no requiere maestría en RxJS.

Estado: Experimental. Úsalo para nuevas características, pero tal vez no reescribas tu flujo de pago todavía.

2. Angular Aria (Developer Preview)

Una nueva biblioteca de primitivas "headless" para accesibilidad.

En lugar de pelear con aria-expanded y role="button", usas directivas que manejan la lógica de accesibilidad mientras tú manejas el CSS.

<!-- Maneja navegación por teclado, foco y roles ARIA automáticamente -->
<div ariaMenu>
  <button ariaMenuItem>Opción 1</button>
  <button ariaMenuItem>Opción 2</button>
</div>

3. Regex en plantillas

Pequeño pero poderoso. Finalmente, puedes usar literales de expresiones regulares en plantillas, perfecto para la lógica @if sin crear una función auxiliar.

@if (email() | match: /@company\.com$/) {
  <span class="badge">Empleado</span>
}

🛠️ La lista de verificación de actualización

¿Listo para saltar? Sigue este orden para minimizar el dolor.

Copia de seguridad: Haz commit de todo. En serio.

Actualizar el CLI Global:
Actualizar Angular generalmente implica dos partes: el CLI global y las dependencias locales del proyecto. Asegúrate de que tu CLI global esté actualizado primero (podrías necesitar sudo o privilegios de administrador).

# Opcional: Desinstalar la versión global antigua primero para evitar conflictos
npm uninstall -g @angular/cli

# Verificar la caché de npm
npm cache verify

# Instalar la última versión global del CLI
npm install -g @angular/cli@latest

Actualizar proyecto local:
Ahora actualiza las dependencias locales de tu proyecto:
```
ng update @angular/cli@21 @angular/core@21
```
Ejecutar los diagnósticos:
Angular 21 incluye diagnósticos más inteligentes. Presta atención a las advertencias sobre ngClass (obsoleto a favor de [class.my-class]) y oportunidades de migración standalone.
Comprobar tus pruebas:
Ejecuta ng test. Si explota, decide:
- Ruta A: Mantener Karma (añadir @angular/build:karma manualmente si se eliminó).
- Ruta B: Migrar a Vitest (recomendado).
Opcional: Ir zoneless:
Si te sientes valiente, ejecuta la migración experimental:
```
ng generate @angular/core:zoneless-migration
```

Nota
Esto es territorio "Agéntico". Mira nuestra Guía MCP para saber cómo dejar que la IA maneje esta refactorización compleja.

Resumen

Angular 21 es el lanzamiento de "borrón y cuenta nueva". Se deshace del peso de la última década (Zone, Karma, Modules) para competir con marcos modernos como Svelte y Solid.

La actualización puede ser irregular debido a los cambios en las pruebas, pero el destino —un marco más rápido, más simple e impulsado por signals— vale absolutamente la pena.

El cambio declarativo de Angular

Antonio Cardenas — Sun, 19 Oct 2025 09:02:30 +0000

Cómo la Nueva Estructura de Carpetas lo Cambia Todo

Si no has actualizado a la versión 20, la primera y segunda parte de esta guía te pueden ayudar a comprender qué cambia y actualizar.

Parte 1: La actualización en sí misma 🛠️

Primero, resolvamos lo básico. Antes de ejecutar cualquier comando, asegúrate de que tu entorno esté listo.

Prerrequisitos

Node.js: v20.11.1 o posterior.
TypeScript: v5.8 o posterior.
**Copia de seguridad del proyecto: Asegúrate de confirmar todos tus cambios actuales en Git. En serio.

El Comando de Actualización

Una vez que hayas confirmado tu versión de Node.js, ejecuta el comando que se ajuste a tu proyecto.

Para un proyecto estándar de Angular:

ng update @angular/cli @angular/core

Si utilizas Angular Material:

ng update @angular/cli @angular/core @angular/material

El proceso de actualización se ejecutará, pero es probable que te encuentres con tu primer obstáculo de inmediato.

*Parte 2: Lo que se rompe inmediatamente *

A diferencia de las actualizaciones anteriores, Angular 20 introduce un cambio significativo que detendrá tu compilación.

1. La Historia Completa Detrás de la Eliminación de Karma

Lo primero que notarás es que ng test fallará. Esto no es solo un error; es un cambio fundamental en las herramientas de compilación de Angular. Con Angular 20, el paquete de compilación predeterminado cambia de @angular-devkit/build-angular al nuevo @angular/build. Este nuevo paquete no incluye Karma. El ecosistema web ha avanzado hacia ejecutores de pruebas más rápidos y modernos como Vitest y Jest, y Karma se había convertido en un cuello de botella.

La solución temporal:

Para que tus pruebas se ejecuten sin migrar todo hoy, debes reinstalar manualmente la antigua herramienta de compilación. Esto obliga a la CLI a usar el antiguo compilador que aún es compatible con Karma.

npm install @angular-devkit/build-angular --save-dev

Este es un puente de compatibilidad. El mensaje del equipo de Angular es claro: comienza a planificar tu migración a Jest o Vitest pronto.

2. browserslist y soporte de navegadores

Aquí hay un detalle menor que podría sorprenderte. Angular 20 oficialmente ya no es compatible con Opera. Si tienes "Opera" listado en tu archivo .browserslistrc, tu compilación puede fallar o arrojar advertencias. Quítalo para resolver el problema.

*Parte 3: La Nueva Arquitectura *

Más allá de los cambios importantes, Angular 20 impulsa una arquitectura más moderna, explícita y escalable.

1. Componentes standalone por defecto.

Los nuevos proyectos generados con ng new ahora son standalone (independientes) por defecto. Esto marca un cambio arquitectónico fundamental que se aleja de los NgModules. Al listar las dependencias directamente en el array imports de un componente, cada componente se vuelve autocontenido.

¿Qué implica este cambio?:

Arquitectura más clara y definida: Sabes exactamente lo que necesita cada componente.
Mejora el *tree-shaking*: Conduce a paquetes más pequeños y optimizados.

Para migrar tus proyectos existentes, puedes ejecutar el schematic de migración standalone:

ng generate @angular/core:standalone

2. Una estructura de carpetas que cuenta una historia

Una buena estructura de carpetas no solo contiene archivos, sino que te dice lo que hace la aplicación. Vale la pena hacer énfasis en la guía de estilo oficial de Angular, ya que sus recomendaciones se basan en años de experiencia comunitaria. Esta filosofía, detallada en su página de referencia de estructura de archivos, a menudo se resume con el acrónimo LIFT (por sus siglas en inglés: Localizar, Identificar, Plano, Tratar de ser DRY):

Locate (Localiza) tu código fácilmente.
Identify (Identifica) lo que hace un archivo de un vistazo.
Flat Flat (Plano): Mantén estructura plana tanto como puedas.
Try to be DRY: Don't Repeat Yourself (Trata de no repetirte).

La conclusión principal es organizar por característica, no por tipo. En lugar de una carpeta components y una carpeta services, crea carpetas para características como user-profile o product-list.

Usemos un ejemplo práctico para una aplicación de comercio electrónico:

src/app/
├── core/
│   ├── auth/          # Lógica de autenticación usada en todas partes
│   │   ├── auth-store.ts
│   │   └── auth-interceptor.ts
│   └── layout/        # El shell de la aplicación: barra de navegación, pie de página
│       ├── navbar.ts
│       └── footer.ts
│
├── features/
│   ├── products/      # Todo para navegar por los productos
│   │   ├── product-list.ts
│   │   ├── product-details.ts
│   │   └── product-search.ts
│   │
│   └── cart/          # La característica del carrito de compras
│       ├── cart-store.ts
│       ├── cart-view.ts
│       └── add-to-cart.ts
│
└── shared/            # Componentes "tontos" reutilizables y utilidades
    └── ui/
        ├── button.ts
        ├── spinner.ts
        └── price.pipe.ts

¿Por qué funciona esto?

core (Proporcionar una vez): Servicios y componentes que la aplicación necesita para ejecutarse, cargados solo una vez (AuthStore, Navbar).
Features (Lo que hace tu aplicación): El corazón de tu aplicación. Cada carpeta es una característica autocontenida.
shared (Bloques de construcción reutilizables): Componentes "tontos", pipes y directivas que no saben nada sobre las características en las que se utilizan (Button, Spinner). Son importados por los módulos de características.

3. La Nueva Convención de Nombres

Angular 20 introduce una nueva convención oficial de nombres que elimina los sufijos tradicionales como .component.ts o .service.ts.

Nomenclatura Antigua	Nueva Nomenclatura	Intención
user-profile.component.ts	user-profile.ts	Componente de Interfaz de Usuario
auth.service.ts	auth-store.ts	Gestión de estado
highlight.directive.ts	highlight.ts	Directiva
user-api.service.ts	user-api.ts	Cliente HTTP

El objetivo es centrarse en la intención del archivo en lugar de su tipo técnico. Una clase que maneja el estado es un "store" (almacén), y una que realiza peticiones HTTP es una "api". Esto hace que el propósito de tu código sea mucho más claro, especialmente en una estructura de carpetas basada en características.

*Parte 4: Las nuevas herramientas y sintaxis *

Finalmente, veamos las nuevas herramientas que mejorarán tu desarrollo diario.

1. El flujo de control es más que syntactic sugar (azúcar sintáctico).

El nuevo bloque @for reemplaza a *ngFor y es una mejora importante.

Sintaxis antigua:

<div *ngFor="let item of items; trackBy: trackItemById">
  {{ item.name }}
</div>

Nueva sintaxis:

@for (item of items; track item.id) {
  <div>{{ item.name }}</div>
} @empty {
  <div>No hay elementos para mostrar.</div>
}

Mejoras clave:

track es obligatorio, lo que impone una mejor práctica de rendimiento que a menudo se olvidaba.
El bloque @empty incorporado limpia las plantillas al eliminar la necesidad de un *ngIf separado.

Puedes usar la CLI para refactorizar automáticamente tus plantillas:

ng generate @angular/core:control-flow

2. Zoneless: Escapando de la "magia de la detección de cambios".

Aunque todavía es experimental, el camino hacia un Angular sin zonas (zoneless) se está volviendo más claro. En un mundo sin zonas, la interfaz de usuario solo se actualiza cuando se lo indicas explícitamente.

Los signals (señales) son la herramienta principal para esto.

mySignal.set(newValue);

Esta línea le indica directamente a Angular que actualice solo las partes específicas del DOM que dependen de esa señal. Es un enfoque quirúrgico, predecible y de alto rendimiento que elimina la sobrecarga y la imprevisibilidad de Zone.js.

Conclusión

Angular 20 es una versión significativa. La actualización requiere intervención manual para las pruebas, pero impulsa el framework hacia un futuro más moderno, explícito y de alto rendimiento. Al adoptar componentes standalone, una arquitectura basada en características y el nuevo flujo de control, no solo estás actualizando, sino que estás preparando tu aplicación para la próxima era del desarrollo web.

Angular 20: De la programación imperativa a la creación declarativa de componentes dinámicos

Antonio Cardenas — Thu, 09 Oct 2025 15:20:49 +0000

Angular 20 llega con nuevas y geniales características y mejoras. Una de las adiciones más significativas es la simplificación de la creación de componentes dinámicos, que la hace mucho más limpia, consistente y predecible. Esta mejora alinea la sintaxis para componentes dinámicos con la forma en que funcionan los "enlaces" (bindings) en las plantillas de componentes.

Anteriormente, la creación de componentes dinámicos se sentía como el complejo proceso de ensamblar una PC personalizada a partir de piezas dispares y manuales: funcional, sí, pero requería que el desarrollador lidiara manualmente con cada cable, cada conexión y cada compatibilidad. Ahora, Angular 20 te da un panel de control unificado.

El laberinto de la construcción manual (Pre-Angular 20)

Antes de Angular 20, trabajar con componentes creados dinámicamente era engorroso. El "enlace de datos bidireccional" (two-way data binding) era muy incómodo, y no existía un estilo unificado para trabajar con "entradas" (inputs) y "salidas" (outputs).

Para configurar un componente dinámico, era como si tuviéramos que conectar cada componente (input) y cable de salida (output) de forma individual y a mano. Para un hipotético NotificationComponent, los pasos manuales e imperativos eran:

Conexión manual de componentes: Se tenía que usar setInput() para conectar cada componente (propiedad) por separado.
Preparación manual de los datos: Si los datos venían de una "señal" (signal), debían ser desenvueltos (acceder a su valor) para obtener el valor real y no la función.
Gestión de las conexiones de salida: Se requería suscribirse manualmente a las salidas (outputs), guardando cada suscripción. Era crucial recordar desconectar estos cables (unsubscribe) para prevenir fugas de memoria.
Sincronización manual de datos: Para que el componente dinámico reaccionara a los cambios en una signal del padre, era necesario un "efecto" (effect) para rastrear el cambio y luego volver a conectar manualmente el cable (setInput) con el nuevo valor.

El código era como un diagrama de cableado muy imperativo y no reactivo:

// Enfoque anterior (Imperativo)

// Paso 1: Conexión básica de la placa madre
const componentRef = this.container().createComponent(NotificationComponent);

// Paso 2: Conexión manual de los componentes y datos
componentRef.setInput('message', 'Alerta de estado');
componentRef.setInput('priority', this.prioritySignal()); // ¡Desenvolver el valor de la signal!

// Paso 3 & 4: Conexión manual de los cables de salida y de sincronización
this.subscriptions.push(
  componentRef.instance.dismissed.subscribe(() => {
    componentRef.destroy(); // Lógica de destrucción manual (desconectar del todo)
  })
);

// Paso 5: Reactividad manual usando efecto
this.subscriptions.push(
  effect(() => {
    // Necesario para que el componente se actualice reactivamente
    componentRef.setInput('priority', this.prioritySignal());
  })
);
// ... Se necesita más código para la sincronización bidireccional y la limpieza de cables.

La forma de acceder a la salida (output) requería acceder directamente a la propiedad de la clase, lo que no respetaba el "alias" de la salida y era diferente de cómo funciona en las plantillas.

El panel de control unificado (Angular 20)

A partir de Angular 20, la configuración de componentes dinámicos se gestiona a través de la nueva propiedad bindings. Este nuevo enfoque es declarativo y reactivo, y su corazón es la "referencia del contenedor de vista" (ViewContainerRef), que actúa como el "socket" principal donde se insertará el nuevo componente.

El poder de `ViewContainerRef`

Una "referencia del contenedor de vista" (ViewContainerRef) es el "socket" en el chasis de tu PC donde se puede instalar una tarjeta de video o de sonido. Permite crear, eliminar o incluso mover "tarjetas" (views) dentro de ese contenedor. Para acceder a él, se puede inyectar con inject() o, para una ubicación específica, usar una referencia de plantilla.

Para controlar la ubicación exacta de tu componente dinámico, puedes añadir un <ng-container> en tu plantilla para definir un lugar de inserción:

<button (click)="createDynamic()">Create Dynamic Component</button>
<ng-container #container></ng-container>

Luego, en el código TypeScript, se accede a esa ubicación específica usando viewChild:

container = viewChild.required("container", { read: ViewContainerRef });

Ahora, la creación del componente dinámico con createComponent se realiza directamente en ese contenedor, asegurando que se renderice en el lugar deseado.

Configuración con `bindings`

La propiedad bindings permite definir "enlaces de entrada" (input), "enlaces de salida" (output) y "enlaces bidireccionales" (two-way bindings) en un estilo unificado. Esto elimina la necesidad de setInput() manuales y de suscripciones.

Aquí está el código completo para un ejemplo práctico, como un DialogComponent, que ahora se conecta con un solo "conector modular":

// Enfoque Angular 20 (Declarativo)

import { Component, inputBinding, outputBinding, viewChild, ViewContainerRef } from '@angular/core';
import { DialogComponent } from './dialog/dialog.component';

@Component({
  selector: 'app-root',
  template: `
    <button (click)="createDynamic()">Create Dynamic Component</button>
    <ng-container #container></ng-container>
  `
})
export class AppComponent {

  container = viewChild.required("container", { read: ViewContainerRef });

  createDynamic() {
    this.container().createComponent(
      DialogComponent,
      {
        bindings: [
          // Conexión del cable de entrada 'isOpen'
          inputBinding("isOpen", () => true),

          // Conexión del cable de entrada 'title'
          inputBinding("title", () => "Hello"),

          // Conexión del cable de salida 'onClose' para que se autodesconecte
          outputBinding("onClose", () => this.container().clear())
        ]
      }
    );
  }
}

La nueva API gestiona automáticamente la limpieza de suscripciones cuando el componente es destruido, eliminando las pesadillas de gestión de memoria y los cables sueltos.

Las tres funciones de enlace en detalle

La API de "enlaces" (bindings) se compone de tres funciones esenciales que deben importarse desde @angular/core.

1. `inputBinding()`

Esta función se utiliza para conectar las "entradas" (inputs) del componente:

Argumento	Propósito	Detalles
Primer Argumento	El nombre de la entrada.	Es el nombre del conector en la tarjeta.
Segundo Argumento	El valor.	Es el valor que se transmite. Puede ser un valor estático (un cable con un valor fijo) o una `signal` (un cable inteligente que transmite actualizaciones).

Cuando se proporciona un signal directamente, inputBinding accede automáticamente al valor de la signal y rastrea reactivamente los cambios, actualizando la entrada del componente sin necesidad de un effect manual.

Ejemplos de inputBinding:

// Entrada estática: el valor no cambia después de la creación
inputBinding('message', () => 'Datos cargados'),

// Entrada dinámica: automáticamente reactiva a los cambios en la signal
inputBinding('priority', this.prioritySignal),

// Entrada calculada: utiliza una función computada (también reactiva)
inputBinding('statusText', () => `Usuario: ${this.currentUser()} - Estado: ${this.systemStatus()}`),

2. `outputBinding()`

Esta función maneja los "eventos de salida" (outputs) emitidos por el componente dinámico.

Argumento	Propósito	Detalles
Primer Argumento	El nombre de la salida.	Es el nombre del cable de salida que emite un evento.
Segundo Argumento	Una función de "devolución de llamada" (`callback`).	Es la lógica que se ejecuta cuando el cable emite un evento.

Se puede especificar el tipo de valor emitido usando un "tipo genérico" (generic type) para mejorar la seguridad de tipos en TypeScript:

// Salida básica: Maneja el evento de cierre
outputBinding('dismissed', () => {
  console.log('Notificación cerrada!');
}),

// Salida con datos y tipado (UserEvent es un tipo genérico)
outputBinding<UserEvent>('userAction', (eventData) => {
  this.handleAction(eventData);
}),

3. `twoWayBinding()`

Esta es la solución simplificada para el "enlace de datos bidireccional" (two-way data binding), reemplazando el cableado manual complejo.

Simplemente se define el nombre de la "entrada modelo" (input model) y se proporciona la signal del componente padre que se desea mantener sincronizada.

// Sincroniza la propiedad 'isUrgent' del componente con 'this.urgentModeSignal' del padre
twoWayBinding('isUrgent', this.urgentModeSignal),

Angular maneja automáticamente la convención de sufijo Change (por ejemplo, isUrgent se empareja con la salida isUrgentChange).

Directivas aplicadas en tiempo de ejecución

Angular 20 también permite añadir componentes o características adicionales (directives) al componente creado dinámicamente. Esto se logra mediante la propiedad directives en la configuración de createComponent.

Para directivas sencillas, se proporciona el nombre del constructor de la directiva. Para directivas más complejas que requieren configuración, se proporciona un objeto que incluye la clave type (el constructor de la directiva) y la propiedad bindings para configurar sus propias entradas.

Ejemplo de directivas de runtime:

Configuraremos un NotificationComponent con una directiva simple (FocusHighlightDirective) y una directiva compleja de la librería Material (SnackbarDirective) para mostrar mensajes de estado al pasar el ratón:

const componentRef = this.container().createComponent(NotificationComponent, {
  bindings: [
    inputBinding('message', () => 'Mueva el ratón para ver más detalles')
  ],
  directives: [
    // Directiva simple sin configuración
    FocusHighlightDirective,

    // Directiva compleja con configuración de entradas
    {
      type: SnackbarDirective, // La clase de la directiva
      bindings: [
        // Configura las entradas de la directiva
        inputBinding('snackbarMessage', () => 'Información extra al hacer hover'),
        inputBinding('snackbarPosition', () => 'right')
      ]
    }
  ]
});

Esta capacidad permite un diseño más modular y una configuración dinámica de la experiencia del usuario.

En resumen, el nuevo enfoque de Angular 20 hace que la creación de componentes dinámicos sea más consistente, limpia y legible, ya que la sintaxis de "enlace" (binding) ahora es idéntica a la de las plantillas de Angular, además de ofrecer reactividad incorporada y gestión simplificada de la memoria. Ahora, en lugar de ensamblar una PC a mano, utilizas un "panel de control" unificado para la configuración y conexión de tus componentes.

Bonus :

stackblitz

Github Repo

Actualizando a Angular 20

Antonio Cardenas — Sat, 28 Jun 2025 10:29:55 +0000

Esta es una guía práctica enfocada en lo que realmente importa al actualizar una aplicación del mundo real: qué se rompe, qué facilita tu trabajo y cómo deberías adaptar tu estilo de desarrollo.

1. La Historia Completa Detrás de la Eliminación de Karma: Más Allá de una Compilación Rota

El problema inmediato al actualizar es que ng test fallará. La razón es un cambio fundamental en las herramientas de compilación de Angular.

Ya que un framework moderno requiere test runners modernos.

¿Por qué Angular eliminó Karma?

Con Angular 20, el paquete de compilación predeterminado cambia de @angular-devkit/build-angular al nuevo @angular/build. Este nuevo paquete ya no incluye el plugin de Karma utilizado por las configuraciones de prueba heredadas. El ecosistema web ha avanzado hacia test runners más rápidos como Vitest y Jest, que utilizan herramientas modernas como Vite y esbuild. Karma se había convertido en un cuello de botella.

Cómo es el nuevo panorama (Vitest/Jest)

El test runner experimental de Angular, ahora impulsado por Vitest, es el futuro. Migrar significa que tus pruebas unitarias se ejecutarán en un entorno rápido y moderno basado en Node.js.

La "solución temporal" explicada

Este comando obliga a la CLI a volver al compilador antiguo que todavía soporta Karma. Es un puente de compatibilidad, pero el mensaje es claro: deberías empezar a planificar tu migración a Jest or Vitest pronto.

npm install @angular-devkit/build-angular --save-dev

2. Prerrequisitos

Antes de comenzar el proceso de actualización, asegúrate de cumplir con los siguientes requisitos:

Node.js: Versión 20.11.1 o posterior.
TypeScript: Versión 5.8 o posterior.
Copia de seguridad del proyecto: Confirma todos los cambios actuales en Git.

3. Cómo Actualizar: Comando CLI y Comparación

Comando de Actualización

Primero, asegúrate de que estás ejecutando Node.js v20.11.1 o posterior.

ng update @angular/cli @angular/core

Si usas Angular Material, inclúyelo en el comando de actualización:

ng update @angular/cli @angular/core @angular/material

Intervención Manual Requerida

Esto no era necesario en versiones anteriores, pero ahora es obligatorio if you want to keep using Karma. El comando reinstala el compilador antiguo con soporte para Karma.

npm install @angular-devkit/build-angular --save-dev

Comparación con Actualizaciones Anteriores

En v19: ng update simplemente funcionaba.
En v20: Debes reinstalar manualmente el compilador antiguo para Karma.

4. Flujo de Control(Control Flow): Más que Syntaxis Decorativo

La nueva sintaxis @for reemplaza a *ngFor y es una mejora importante.

Sintaxis Antigua:

<div *ngFor="let item of items; trackBy: trackItemById">
  {{ item.name }}
</div>

Sintaxis Nueva:

@for (item of items; track item.id) {
  <div>{{ item.name }}</div>
} @empty {
  <div>No hay elementos para mostrar.</div>
}

Mejoras clave:

track ahora es obligatorio, lo que fomenta las mejores prácticas de rendimiento.
@empty mejora la experiencia del desarrollador (DX) al eliminar la necesidad de un bloque @if separado para manejar listas vacías.

Migración Automatizada y Rendimiento

Usa la CLI para refactorizar automáticamente las plantillas a la nueva sintaxis de flujo de control, que ofrece mejoras de rendimiento y un código más mantenible.

ng generate @angular/core:control-flow

Mejores Prácticas Generales y Migraciones Adicionales

Considera migrar a otras características modernas de Angular junto con la actualización del flujo de control para una aplicación completamente optimizada. Esto puede incluir componentes standalone, signals como inputs y carga diferida (lazy loading) para rutas.

ng generate @angular/core:standalone
ng generate @angular/core:inject
ng generate @angular/core:route-lazy-loading
ng generate @angular/core:signal-input-migration
ng generate @angular/core:signal-queries-migration
ng generate @angular/core:output-migration

5. Standalone por Defecto: Un Cambio Arquitectónico Fundamental

Al listar explícitamente las dependencias usando el array imports a nivel de componente, cada componente se vuelve autocontenido. Esto clarifica tu arquitectura y mejora significativamente el tree-shaking, resultando en paquetes de aplicación más pequeños.

6. Adiós Zone.js (Zoneless): Escapando de la "Magia" de la Detección de Cambios

En un mundo sin zone.js, la interfaz de usuario solo se actualiza cuando se lo indicas explícitamente. Los Signals son la herramienta principal para esto. Cuando llamas a mySignal.set(), le estás diciendo directamente a Angular que actualice solo las partes del DOM que usan ese signal. Es un enfoque quirúrgico, predecible y de alto rendimiento.

7. Nueva Convención de Nombres: Por Qué Parece Complicado

Angular 20 introduce una nueva convención de nombres oficial que elimina los sufijos de tipo tradicionales.

Nomenclatura Antigua:

user-profile.component.ts
auth.service.ts
highlight.directive.ts

Nomenclatura Nueva:

user-profile.ts
auth-store.ts
highlight.ts

El nuevo enfoque está en la intención del archivo en lugar de su tipo:

user-api.ts → Maneja peticiones HTTP
auth-store.ts → Gestiona el estado reactivo
movie-card.ts, movie-details.ts → Componentes de UI

Reglas Clave de Nomenclatura:

Usa guiones para nombres de archivo de varias palabras (ej. user-profile.ts).
Haz que el nombre de la clase coincida con el nombre del archivo.
Mantén el sufijo .spec.ts para los archivos de prueba.
Evita nombres genéricos como utils.ts.
Ubica los archivos relacionados en la misma carpeta (co-locate) dentro de una estructura de carpetas basada en funcionalidades.

Ejemplo de Estructura de Carpetas Basada en Funcionalidades:

src/
├── core/
│   └── auth/
│       ├── auth-store.ts
│       ├── login.ts
│       └── register.ts
└── features/
    └── users/
        ├── user-profile.ts
        ├── user-api.ts
        └── user-settings.ts

Beneficios:

Diffs en Git más limpias al refactorizar.
Promueve un código orientado a la intención.
Facilita la incorporación de nuevos desarrolladores.

8. Detalle Importante: `browserslist` y Soporte de Navegadores

Angular 20 ya no soporta oficialmente Opera. Si tienes Opera en tu archivo .browserslistrc, puede que necesites eliminarlo. Otros navegadores no convencionales también pueden perder soporte, lo que podría provocar advertencias o problemas de compilación.

Novedades en Angular 20

Antonio Cardenas — Sun, 01 Jun 2025 05:08:21 +0000

Angular 20: ¿Qué hay de nuevo?

Ha pasado mucho tiempo y muchas versiones, pero la calidad se mantiene y mejora.

Nuevos requisitos: TypeScript v5.8 y Node v20

Angular v20 nos deja claro cuáles son los nuevos requisitos. Ahora tienes que estar en TypeScript v5.8 (que, por cierto, ya era compatible desde v19.2), así que es hora de decir adiós a las versiones más antiguas de TypeScript).

Y para Node, dale la bienvenida a Node v20 como el nuevo mínimo. Angular v19 fue la gira de despedida para Node 18. ¡Es hora de actualizar esos entornos o agregarles, si usas NVM, colegas!

Guía de estilo 2025: ¡Una bocanada de aire fresco!

¡La Guía de Estilo de Angular ha recibido una renovación significativa! Muchas recomendaciones se han reducido para centrarse en lo que realmente importa.

Nombres de archivo recortados: Olvídate de UserComponent en user.component.ts. Ahora es simplemente User en user.ts. Lo mismo para directivas, pipes, etc. La CLI ya está aplicando esto para cosas nuevas. ¿Cuánto tardará tu memoria muscular en adaptarse?
Estructura de carpetas más ligera: La carpeta app de nivel superior podría desaparecer pronto (aunque la CLI aún no ha llegado a ese punto).
Visibilidad de propiedades: protected es ahora la forma para las propiedades que solo se usan en tu plantilla, y readonly para todas esas propiedades inicializadas por Angular (input(), output(), etc.). ¡Tiene sentido!
Bindings de Clases y Estilos: ¡Es oficial! [class.something] y [style.something] son los campeones recomendados sobre ngClass y ngStyle.

Esto es un cambio grande. Los nuevos proyectos lo adoptarán por defecto. ¿Los existentes? Bueno, o migras o te quedas con las viejas costumbres (la CLI ayuda con una configuración para eso, ¡uf!).

APIs de Signals: ¡Mayormente Luz Verde y Estables!

¡Las Signals son el futuro, y las APIs se están consolidando! La mayoría ahora son estables:

effect()
toSignal()
toObservable()
afterRenderEffect()
afterNextRender()
linkedSignal()
PendingTasks

¡Ojo con esto! afterRender() ha sido renombrado a afterEveryRender() y es estable. Crucialmente, el nombre antiguo desapareció sin migración automática. ¡Uf, eso podría doler!

Además, TestBed.flushEffects() (esa API en developer preview un poco escurridiza) está obsoleta. Usa TestBed.tick() ahora, que ejecuta todo el proceso de sincronización, mucho más cercano al comportamiento real de la aplicación. effect() perdió su opción forceRoot (¿alguien la usaba mucho?), y toSignal() eliminó rejectErrors (¡bien pensado, mejores prácticas al poder!). pendingUntilEvent() Todavía está en developer preview, por lo cual puede que tarde un poco en implementarse.

Zoneless: ¡Fuera de Experimental, entra en Developer Preview!

Si las signals son el futuro de la reactividad, ¡Zoneless es el futuro de la detección de cambios! Ya no es "experimental"; ahora está oficialmente en developer preview.

provideExperimentalZonelessChangeDetection ahora es simplemente provideZonelessChangeDetection.
El flag de la CLI --experimental-zoneless ahora es simplemente --zoneless.

La CLI incluso te preguntará si quieres habilitarlo para nuevos proyectos. ¿Listos para el #NoZone?

Que se va, que se queda y que puede romper nuestro código:

Como en toda versión mayor, algunas cosas se desaparecen para bien:

Las directivas ngIf, ngFor, ngSwitch están oficialmente obsoletas. El control de flujo incorporado (@if, @for, @switch) es el rey ahora. Empieza a migrar; ¡probablemente desaparecerán en v22! ng update Te echará una mano.
fixture.autoDetectChanges(boolean): El parámetro booleano ha desaparecido. Simplemente usa fixture.autoDetectChanges(). ¿Usar fixture.autoDetectChanges(false) en un test zoneless? Eso ahora lanzará un error.
TestBed.get(): ¡Finalmente, finalmente DESAPARECIÓ! Estuvo obsoleto desde Angular v9. TestBed.inject() Es tu amigo (desde hace mucho). Una migración automática se encargará de esto.
Enum InjectFlags: Eliminado. Los objetos de opciones para las APIs de DI (como inject()) han sido la norma desde v14.1.
Token DOCUMENT: Se movió de @angular/common a @angular/core. Una migración actualizará tus imports.
@angular/platform-browser-dynamic: Obsoleto en favor de @angular/platform-browser. Tendrás que actualizar manualmente los imports para este por ahora.
@angular/platform-server/testing: También obsoleto, sin reemplazo. Las pruebas E2E son ahora la forma recomendada para verificar aplicaciones SSR.
Integración con HammerJS: Obsoleta. HammerJS no ha visto una actualización en 8 años. Es hora de decir adiós a esas entidades en el framework.
Atributos ng-reflect-*: Desaparecen por defecto en modo desarrollo. Eran para antiguas DevTools. Si dependías de ellos (¡probablemente no deberías!), puedes rehabilitarlos con provideNgReflectAttributes(). Pero quizás... ¿Mejor no?

Plantillas: ¡Nuevos trucos bajo la manga!

Tus plantillas se han vuelto un poco más expresivas:

Exponenciación: {{ 2 ** 3 }} ahora es posible. ¡Por lo que podemos hacer cálculos de manera más fácil!
Tagged Template Literals: Sí, {{ translate\app.title}} está aquí (técnicamente desde v19.2, pero ahora está asentado).
Operador void: Úsalo como <button (click)="void selectUser()"> para ignorar explícitamente el retorno de una función, especialmente útil para listeners de eventos donde return false podría prevenir el comportamiento por defecto.
Operador in: Verifica propiedades como @if ('invoicing' in permissions). ¡Súper útil!

Diagnósticos extendidos: ¡El compilador te mantiene informado!

Más verificaciones incorporadas para atrapar errores comunes:

missingStructuralDirective: ¿Usando algo como *ngTemplateOutlet pero olvidaste importar NgTemplateOutlet? El compilador ahora te lo hará saber (con strictTemplates).
uninvokedTrackFunction: ¿Escribiste @for (user of users; track getUserId) en lugar de track getUserId(user)? Recibirás un codazo amistoso.
unparenthesizedNullishCoalescing: Mezclar ?? con && o || (ej. a ?? b && c) ahora requiere paréntesis para mayor claridad, como {{ a ?? (b && c) }}. TypeScript hace esto, ¡así que es genial verlo también en las plantillas!

Puedes suprimirlos en tsconfig.json si de verdad quieres, pero... ¿Por qué querrías?

Chequeo de tipos en host: ¡Ya no más misterios!

Hay una nueva opción de compilador typeCheckHostBindings (ya en nuevos proyectos CLI). Si usas metadatos de host en decoradores (o @HostBinding/@HostListener), el compilador ahora verifica:

Si el objetivo del binding/listener (ej. value en [value]="value()") es realmente válido para el elemento host.
Si la propiedad en tu clase de componente/directiva (ej. value()) realmente existe.

¡Esto es brutal para pillar typos y asegurar que tus bindings de host sean legítimos!

Manejo de errores: ¡Menos errores que se escapan!

provideBrowserGlobalErrorListeners: Un nuevo provider (agregado por defecto en nuevos proyectos CLI) para registrar listeners de errores globales en el navegador. Atrapa errores que Angular podría pasar por alto.
Los errores en los listeners de eventos ahora se reportan al manejador de errores interno de Angular. Esto significa que podrías ver errores en tests que antes eran silenciosos. Es hora de arreglarlos (o usar rethrowApplicationErrors: false en configureTestingModule como último recurso).

Componentes creados dinámicamente: ¡Sube de nivel!

¡createComponent() (y ViewContainerRef.createComponent) se volvieron mucho más geniales en v20! Ahora puedes pasar opciones para:

Especificar directives a aplicar al componente dinámico.
Proveer valores de input usando la nueva función inputBinding().
Declarar two-way bindings con twoWayBinding().
Escuchar outputs con outputBinding().

Esto es un gran avance respecto a llamar setInput después de la primera detección de cambios. ¡Más poder y control! ¿Llegará esto también a TestBed.createComponent()?

Formularios: Aún esperando las señales, pero...

No hay formularios basados en signals todavía (¡todos estamos al borde del asiento esperando eso!). Pero v20 trae un par de ajustes pequeños pero bienvenidos:

userForm.resetForm(undefined, { emitEvent: false }): Resetea formularios sin disparar eventos.
markAllAsDirty(): Finalmente, un método en AbstractControl para marcar un control y todos sus descendientes como dirty. ¡A markAllAsTouched() le faltaba un hermano!

Router: ¡Navegación más fluida a la vista!

Algunas mejoras interesantes para el router:

Opciones de Scroll: Pasa opciones nativas de scroll a ViewportScroller.scrollToAnchor()/scrollToPosition(). Por ejemplo, behavior: 'smooth' para ese efecto de scroll elegante.
Resolvers con más contexto: ¡Los resolvers de rutas hijas ahora pueden acceder a datos resueltos de su ruta padre! route.data.user del padre estará disponible. ¡Menos gimnasia para obtener datos!
Redirecciones asíncronas: La opción redirectTo en las configuraciones de ruta ahora puede aceptar una función que devuelva una Promesa o un Observable para redirecciones asíncronas. (Técnicamente un breaking change debido a la evolución del tipo de retorno).
Soporte para Custom Elements: ¿Escribiendo Web Components? Ahora puedes usar un custom element como host de un RouterLink.

Http: APIs de `resource` Evolucionando y `keepalive`!

Cambios en API de resource: El parámetro query de resource() ahora es params. Para rxResource(), loader ahora es stream. El método reload se movió a WritableResource (solo los recursos mutables pueden recargarse).
Actualizaciones en httpResource: La opción map ahora es parse. Puedes especificar el contexto HTTP en las opciones. Y, la petición debe ser ahora reactiva (ej. httpResource<User[]>(() => '/users') en lugar de solo la URL como string).
Soporte keepalive: HttpClient ahora soporta la opción keepalive cuando se usa la API Fetch (habilitada con withFetch()). Las peticiones no se abortarán si la página se descarga. Útil para cosas como analíticas.

Perfilación: ¡Mira dónde es afectado el rendimiento de tu app!

Hay una nueva función enableProfiling() en @angular/core. Llama a esto, y Angular usará la API de Performance del navegador para etiquetar operaciones del framework (detección de cambios, plantillas, outputs, defer, etc.). Luego, abre las Devtools de Chrome, graba un perfil de rendimiento y mira la pista personalizada "Angular". ¡Por fin, una vista clara del rendimiento interno!

Devtools: ¡Mejores perspectivas!

Las Devtools de Angular se están volviendo más inteligentes:

Los componentes OnPush ahora se marcan como tales en el árbol de componentes.
Los bloques diferidos (defer) también se muestran.
El soporte para Signals está mejorando – ¡pronto deberíamos ver el árbol de signals! Echar un vistazo bajo el capó ahora es más fácil.

SSR: ¡APIs estables y configuración optimizada!

Buenas noticias para el Server-Side Rendering:

¡Las APIs withI18nSupport() y withIncrementalHydration() ahora son estables!
provideServerRendering() (ahora en @angular/ssr en lugar de @angular/platform-server) se combina con provideServerRoutesConfig() en una única función provideServerRendering(withRoutes(serverRoutes)). Una migración se encargará de esto.
Las nuevas apps CLI con --ssr obtienen Express v5 y soporte de enrutamiento en servidor por defecto (la opción --server-routing ha desaparecido).

Angular CLI: ¡Esto es ENORME!

La CLI vio un montón de cambios. Prepárense:

Nomenclatura actualizada para Guía de estilo 2025: Como se mencionó, user.ts (con clase User) en lugar de user.component.ts (clase UserComponent). Igual para directivas, servicios. Pipes, resolvers, etc. usan guiones en los nombres de archivo (from-now-pipe.ts). Una migración de angular.json configura tus proyectos existentes para usar la convención antigua si quieres una transición suave.
Configuración de TypeScript: La opción module ahora es preserve (refleja mejor los bundlers modernos). tsconfig.json Usa un estilo de "solución", referenciando tsconfig.app.json y tsconfig.spec.json.
angular.json simplificado: Los nuevos proyectos usan @angular/build directamente, deshaciéndose de @angular-devkit/build-angular y sus dependencias transitivas de Webpack. ¡Eso es casi 200 Mb menos en node_modules! Algunas opciones como outputPath también se eliminan ya que tienen valores por defecto sensatos. ¡Más ligero y potente!
Configuración de Browserslist: Ahora apunta a la base "ampliamente disponible" (navegadores lanzados hace < 30 meses del conjunto principal de Baseline). Soporte de navegadores más consistente y realista.
Importadores de paquetes Sass: Ahora puedes usar importadores pkg:, como @use 'pkg:@angular/material' as mat;.
Testing Ahead of Time (AoT) y Cobertura de Código para Plantillas: Añade "aot": true a tus opciones de test en angular.json. ¡Ejecuta tests en el mismo modo que producción! Además, obtienes cobertura de código para las plantillas.
Testing con Vitest (¡experimental!): ¡Notición! La CLI ahora soporta ejecutar tests con Vitest. Hay un nuevo builder @angular/build:unit-test. Karma y Jasmine podrían tener un nuevo retador.
- Configúralo con "runner": "vitest". Necesitarás un "buildTarget".
- Por defecto, usa Node con jsdom (instálalo).
- Actualiza los types de tsconfig.spec.json a ["vitest/globals"].
- Modo Navegador: ¡Sí! "browsers": ["chromium"] (o firefox, webkit). Usa Playwright o WebdriverIO (instala uno).
- El modo watch es más rápido (solo ejecuta tests afectados). Las ejecuciones completas podrían ser un poco más lentas que Karma.
- --no-watch A menudo es implícito en CI.
- Nuevo flag --debug (Vitest + jsdom/Playwright).
- Limitaciones: Aún no hay archivo de configuración de Vitest personalizado. Pero la opción providersFile te permite configurar cosas como testing zoneless. Reportes y exclusiones de cobertura están en angular.json.
Carpetas de Workspace automáticas en Chrome: ¡El servidor de desarrollo Vite ahora ayuda a las Devtools de Chrome a mapear los archivos de tu proyecto, permitiendo edición directa desde Devtools que se guarda en tu disco! Habilítalo en los flags de Chrome.
Sourcemaps sin fuentes: Genera sourcemaps sin incrustar el código fuente original ("sourcesContent": false). Genial para reportar errores en producción sin exponer todo tu código.

¡Angular y su futuro junto a la IA!

Angular se posiciona para facilitar el desarrollo de aplicaciones con capacidades de IA generativa:

Archivo: llms.txt Se mantiene un archivo llms.txten el repositorio de Angular. Este archivo ayuda a los grandes modelos de lenguaje (LLMs) a descubrir la documentación y los ejemplos de código más recientes y correctos de Angular, para que generen código más moderno y preciso, evitando problemas con APIs o sintaxis obsoletas.

Guías y recursos: Se están proporcionando guías y recursos, angular.dev/ai incluyendo ejemplos y live streams que muestran cómo integrar Angular con herramientas como Genkit y Vertex AI de Google Cloud.

Qué podríamos llegar a ver en Angular v21

Componentes sin selector: Imagina esto:
```
import { User } from './user/user'; // El import de TS aún es necesario

@Component({
  template: '<User [name]="name()" (selected)="selectUser()" />',
  // ¡NO se necesita el array 'imports' de Angular para User!
})
export class App { /* ... */ }
```
¡Componentes usados por su nombre de clase directamente en las plantillas! Las directivas podrían usar un prefijo @ (ej. <User @CdkDrag />). Los pipes también por nombre de clase ({{ date | FromNowPipe }}). La sintaxis está LEJOS de ser final, pero el trabajo en el compilador ha comenzado. ¿Alucinante, no? ¡Esto podría ser revolucionario! Debería llegar un RFC.

Formularios con Signals (¿La Tercera Vía?): ¡Prepárense para una posible nueva forma de hacer formularios, separada de template-driven y reactive!

// PROTOTIPO MUY TEMPRANO - ¡NO USAR AÚN!
@Component({
  selector: "user-form",
  imports: [FieldDirective], // Nueva directiva
  template: `
    <form>
      <label>Username: <input [field]="userForm.username" /></label>
      <label>Name: <input [field]="userForm.name" /></label>
    </form>
  `,
})
class UserFormComponent {
  userModel = signal<UserModel>({ /* ... */ });
  protected readonly userForm: Field<User> = form<User>( // nueva función form()
    userModel, // datos a editar
    (userPath: FieldPath<User>) => { // esquema para comportamiento dinámico y validación
      disabled(userPath.username, () => true, "No se puede cambiar el nombre de usuario");
      required(userPath.name);
      error(userPath.age, ({ value }) => value() < 18, "Debe ser mayor de 18");
    }
  );
}

Una nueva función form() y clase Field para manejar el estado del formulario con signals. ¡Echa un vistazo al design doc si tienes curiosidad, o espera al RFC!

El futuro del FrontEnd se escribe… con prompts.

Antonio Cardenas — Wed, 26 Mar 2025 09:13:38 +0000

Como sabrán, después de varias iteraciones, v0 ya no solo centra divs.
Ahora plantea una pregunta que incomoda a más de uno:

¿Hasta qué punto la inteligencia artificial puede - o debe - reemplazar el trabajo de un desarrollador frontend?

¿Qué es v0?

v0.dev es una plataforma desarrollada por Vercel que permite generar componentes completos de frontend a partir de descripciones en lenguaje natural. Es una especie de copiloto visual que, combinando diseño e implementación, devuelve código limpio usando React, Tailwind y otros stacks modernos.

Lo que diferencia a v0 de otros generadores es su precisión semántica. Entiende el contexto del pedido, ofrece estructuras coherentes y propone soluciones visualmente bien diseñadas.

No genera "código al azar"; genera componentes útiles, ajustados a lo que el prompt sugiere y a cómo está escrita la petición.

Hace algún tiempo se filtró el prompt que utiliza v0 de Vercel para construir interfaces a partir de texto plano. Puedes dar un vistazo aquí.

Aunque la noticia generó ruido, también dejó al descubierto lo que realmente hace potente a esta herramienta: el contexto.

¿Qué es un prompt?

Un prompt es la instrucción que se le da a un modelo de lenguaje para ejecutar una tarea.

"Un formulario de registro con validación, modo oscuro y diseño mobile first."

El poder del prompt no solo está en lo que se pide, sino en cómo se pide. Lenguaje claro, intenciones explícitas y contexto bien delimitado son claves para obtener resultados útiles.

¿Qué es el contexto?

En términos técnicos, el contexto es la información adicional que acompaña al prompt y que permite al modelo "entender" de forma más precisa lo que se espera.

Puede incluir:

El stack deseado (React, Next.js, Tailwind)
Consideraciones de accesibilidad
Comportamiento esperado del componente
Restricciones técnicas o de diseño

v0 utiliza un sistema avanzado de prompt engineering con contexto enriquecido, lo que le permite generar código funcional y relevante para el entorno del proyecto.

¿Vibe Coding?

El concepto de vibe coding se refiere a una nueva forma de programar guiada más por intención y energía creativa que por la escritura manual de cada línea de código.

Con herramientas como v0, la experiencia de desarrollo empieza a parecerse más a componer música que a escribir código.

El flujo cambia: se convierte en una colaboración entre humano e IA, donde la intuición y el criterio técnico siguen siendo esenciales.

Y v0 no está solo.

Cursor transforma Visual Studio Code en un entorno conversacional, permitiéndote editar, navegar y escribir código directamente con inteligencia artificial.
Claude permite razonar sobre estructuras complejas y refactorizaciones de alto nivel, muy útil para tareas más abstractas del frontend como diseño de arquitectura.
GitHub Copilot se mantiene como asistente de línea, recomendando snippets y completando código mientras escribes.

Todas estas herramientas forman parte del nuevo entorno de desarrollo: uno donde el ingenio humano y la eficiencia algorítmica se encuentran en el centro del workflow.

¿El fin del FrontEnd Dev?

Personalmente, el enfoque que más me gusta acerca de la inteligencia artificial es el de aumentar capacidades.

Automatizar sin entender lo que se está haciendo puede ser una trampa peligrosa, generando más deuda técnica que valor real.

v0 no reemplaza al frontend developer, pero sí le exige evolucionar. El rol se mueve de implementador a curador, arquitecto y estratega de interfaz.

Saber escribir un buen prompt, entender el contexto del proyecto así como su lógica, probar su seguridad, validar accesibilidad, resolver errores generados por implementaciones de la IA, optimizar rendimiento… Todo eso sigue siendo parte del trabajo.

La inteligencia artificial no elimina el desarrollo frontend. Lo transforma.
Y quienes entiendan esa transformación podrán liderarla en lugar de resistirla.

Angular 19 httpResource

Antonio Cardenas — Tue, 18 Mar 2025 10:52:24 +0000

Llamadas a API basadas en signals

A partir de Angular v19.2, podemos comenzar a olvidarnos de manejar llamadas a API de manera manual gracias a la nueva primitiva de Angular. httpResource la que nos permite de manera reactiva obtener datos, haciendo un llamado a nuestra API de preferencia cada vez que el valor cambie.

Características principales:

Reactividad automática:

El recurso generado por httpResource observa señales y automáticamente vuelve a realizar solicitudes HTTP cada vez que las dependencias reactivas cambian.

Estado por defecto:

Permite establecer valores predeterminados mediante la propiedad defaultValue, asegurando una respuesta coherente en situaciones iniciales, estados de carga o errores en las solicitudes.

Validación y transformación de datos:

La opción parse facilita la validación y transformación automática de las respuestas HTTP, mejorando la seguridad de tipos y garantizando la integridad de los datos recibidos.

Ventajas frente al enfoque tradicional:

Reducción significativa de código: Elimina la necesidad de gestionar manualmente suscripciones, reduciendo errores como memory leaks.
Actualización automática del estado: Al depender directamente de Signals, los datos se actualizan automáticamente según los cambios en el estado reactivo de la aplicación, eliminando tareas manuales.
Mayor seguridad: Promueve un desarrollo robusto mediante validación automática y estricta gestión del estado en todas las fases del ciclo de vida del dato.

Actualmente, esta API se encuentra en fase experimental, por lo que se recomienda seguir su evolución antes de implementarla en entornos de producción críticos.

Ejemplo de uso e implementación:

Anteriormente debíamos recurrir a RxJS para suscribirnos y desuscribirnos cada que hacíamos una llamada de API, lo cual en ciertas ocasiones contribuía a los famosos memory leaks porque si olvidábamos desuscribirnos.

Para implementarlo, deberemos comenzar creando una interfaz (interface) definiendo la estructura de nuestro personaje con datos como ser el id, el nombre, la imagen, etc., etc.

Ahora implementamos httpResource en nuestro componente.

characterResource es un httpResourceRef que devuelve los datos del personaje desde el API; defaultValue se encarga de que characterResource tenga una estructura definida, incluso antes de que los datos sean cargados.

characterId es un signal que representa el número del personaje que se está mostrando. Cambiar este valor acciona httpResource para obtener la data del personaje seleccionado.

Pero, ¿qué pasa si queremos usar POST, PUT, DELETE?

Solo debemos cambiar el método (method) y su correspondiente body junto a los params.

  usersResource = httpResource<RickCharacter>({
    url: '',
    method: 'POST',
    body: { page: 1 },
    params: { per_page: 6 },
  });

En el siguiente artículo cubriré aspectos más avanzados como headers params,etc. pero por ahora puedes ver todo el código funcional en el siguiente:

Ejemplo:

Proyecto Fugu: Revolucionando las aplicaciones web progresivas (PWA)

Antonio Cardenas — Mon, 25 Nov 2024 14:00:00 +0000

El Proyecto Fugu busca cerrar la brecha entre las aplicaciones web progresivas (PWA) y las aplicaciones nativas, haciendo que las PWA sean más útiles, atractivas y accesibles para todos. Este esfuerzo es un conjunto de esfuerzos tanto de la comunidad de Chromium como de empresas como Google, Microsoft y otras colaboradoras de la comunidad web en general.

¿Qué son las PWA?

Las PWA son aplicaciones web diseñadas para ser rápidas, confiables y capaces de instalarse en dispositivos como si fueran aplicaciones nativas. Utilizan API modernas para:

Mejorar la capacidad: acceso al hardware y funcionalidades avanzadas.
Garantizar la confiabilidad: carga rápida y sin interrupciones, incluso sin conexión.
Facilitar la instalación: se comportan como apps tradicionales.

Con estas mejoras, las PWA combinan lo mejor de la web y las aplicaciones nativas.

¿Por qué "Proyecto Fugu"?

El nombre "Fugu" hace referencia al pez globo japonés, famoso por ser delicioso, pero peligroso si no se prepara correctamente. Este simbolismo captura la esencia del proyecto: las nuevas API pueden ser muy poderosas, pero si no se implementan con cuidado, pueden generar problemas.

Ejemplo de capacidades avanzadas y riesgos:

Capacidades avanzadas: Acceso al sistema de archivos, herramientas de edición de video, integración con dispositivos Bluetooth y USB.
Riesgos potenciales: Estas herramientas deben garantizar la seguridad y privacidad de los usuarios.

El proyecto Fugu se enfoca en habilitar estas capacidades mientras se mantiene un equilibrio entre utilidad y seguridad.

Principales API del proyecto Fugu

File System Access API: Permite a las aplicaciones leer y escribir archivos directamente en el sistema del usuario.
Web Share API y Web Share Target API: Facilita compartir contenido entre aplicaciones web y nativas.
Contact Picker API: Acceso a contactos del dispositivo con permiso explícito.
Web Bluetooth y Web USB: Conexión con dispositivos físicos para ampliar la funcionalidad.
Badging API: Muestra notificaciones y conteos en el ícono de la app instalada.

Beneficios del proyecto Fugu

Compatibilidad universal: Las PWA funcionan en cualquier dispositivo con navegador.
Actualizaciones sin complicaciones: Siempre al día, sin necesidad de descargas desde una tienda de aplicaciones.
Mejor experiencia de usuario: Acceso a funcionalidades que antes eran exclusivas de aplicaciones nativas.

La seguridad y el futuro de las PWA

El proyecto Fugu no solo busca expandir las capacidades de las PWA, sino hacerlo de forma segura. Se trabaja para evitar riesgos mediante permisos explícitos y el desarrollo de prácticas responsables para los desarrolladores.

Con Fugu, las PWA están evolucionando para ser más que una simple versión web. Son una herramienta poderosa que está transformando cómo interactuamos con la tecnología.

Bonus:

La página web del proyecto Momentum https://momentum-fw.dev/ utiliza la API Web USB para instalar un firmware alternativo al por defecto de FlipperZero.

Más ejemplos e inspiración en:
https://developer.chrome.com/docs/capabilities/fugu-showcase

Novedades en Angular 19, ¿Qué hay de nuevo?

Antonio Cardenas — Tue, 19 Nov 2024 15:27:56 +0000

Angular sigue evolucionando y la versión 19 no es la excepción. Con un enfoque en la experiencia del desarrollador (Developer Experience), rendimiento mejorado y nuevas herramientas, Angular 19 ofrece características que simplificarán tus proyectos y los harán más eficientes. En este artículo, exploraremos las mejoras en reactividad con Signals, optimización del renderizado y mucho más. Además, este artículo es la onceava iteración desde la versión 8, uno de los primeros artículos en este blog…

1.Standalone components como estándar.

Los Standalone Components han sido una adición revolucionaria desde su introducción en Angular 14, y ahora en Angular 19 se convierten en el comportamiento predeterminado. Esto significa que ya no necesitas declarar standalone: true en cada componente.

Antes de Angular19:

@Component({
  standalone: true,
  imports: [CommonModule],
  selector: 'standalone-component',
  templateUrl: './standalone-component.html',
})
export class StandaloneComponent { }

Ahora:

@Component({
  imports: [CommonModule],
  selector: 'standalone-component',
  templateUrl: './standalone-component.html',
})
export class StandaloneComponent { }

Esto elimina la necesidad de módulos (NGModules) en la mayoría de los casos, simplificando la estructura de las aplicaciones y fomentando un desarrollo modular. Si aún necesitas trabajar con NgModules, puedes declararlo explícitamente standalone: false.

2. Hidratación parcial e incremental para un renderizado más rápido

Angular 19 introduce hidratación parcial e incremental, lo que transforma el rendimiento de las aplicaciones renderizadas en el servidor (SSR):

Hidratación parcial:

Prioriza la carga de componentes críticos, reduciendo el tiempo de interacción inicial.
Hidratación incremental:

Difiere la carga de funcionalidades según interacciones del usuario (clics o hovers), optimizando el uso de recursos.

Estas técnicas permiten aplicaciones más rápidas e interactivas desde el primer momento, mejorando la experiencia del usuario.

3. Signals mejorados: Simplificando la reactividad

La integración de Signals en Angular continúa mejorando, ahora con soporte más profundo y nuevas herramientas como LinkedSignal:

¿Qué son los Signals?

Son una API diseñada para manejar estados de forma reactiva y predecible, reduciendo la dependencia de Zone.js. Esto no solo simplifica la depuración, sino que también mejora el rendimiento y reduce el tamaño de los paquetes.

Ejemplo de uso con Signals:Introducción de linkedSignal:

linkedSignal Es una nueva herramienta que permite crear señales dependientes que se actualizan automáticamente según una señal fuente.

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

const fuente = signal(10);
const doble = linkedSignal(fuente, valor => valor * 2);

console.log(doble()); // 20
fuente.set(15);
console.log(doble()); // 30

4. Mejoras en el API de componentes

Angular 19 introduce ngAfterSignalUpdate un nuevo hook para reaccionar tras la actualización de un Signal, facilitando la interacción con estados complejos.

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

@Component({
  selector: 'app-lifecycle',
  template: 
    <h3>Signal Lifecycle</h3>
    <button (click)="updateSignal()">Update</button>
  ,
})
export class SignalLifecycleComponent implements AfterSignalUpdate {
  mySignal = signal(0);
  updateSignal() {
    this.mySignal.set(this.mySignal() + 1);
  }
  ngAfterSignalUpdate() {
    console.log('Signal updated to:', this.mySignal());
  }
}

El nuevo hook ngAfterSignalUpdate permite a los desarrolladores reaccionar después de que se haya actualizado el signal, lo que puede ser esencial para gestionar cambios en la interfaz de usuario e interacciones de estado complejas.

5. Tiempos de construcción más rápidos

Gracias a optimizaciones en Angular CLI, las construcciones son más rápidas tanto en entornos de desarrollo como de producción. La incorporación de caché acelera los procesos iterativos.

Ejemplo: Construcción con caché

ng build - optimization=true - build-cache

6.Inyección de dependencias

Ahora Angular infiere automáticamente los tipos en la Inyección de Dependencias (DI), reduciendo el código repetitivo y aumentando la seguridad de tipos.

Ejemplo: Inferencia de tipos en DI

// Antes
constructor(private http: HttpClient) {}

// Ahora en Angular 19
constructor(private readonly httpClient) {}

7. APIs resource y rxResource: Datos asíncronos simplificados

Manejar datos asíncronos ahora es más fácil con las nuevas APIs experimentales resource y rxResource, diseñadas para Promises y Observables respectivamente.

Propiedades de⁣ `resource`: ⁣

Status:
Estado del recurso (cargando, éxito o error).
Value:
Datos recuperados tras la carga.
Error:
Gestión de errores.

Ejemplo con `rxResource`

Estas herramientas unifican la gestión de datos asíncronos, haciendo que los flujos sean más intuitivos.

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

const datos = rxResource(async () => {
  const respuesta = await fetch('/api/datos');
  return respuesta.json();
});

datos.value.subscribe(data => console.log(data));

8. Mejoras al routing

Angular 19 introduce una integración más profunda de Signals con el Router, permitiendo flujos de navegación más reactivos y simplificados. Esto facilita el manejo de parámetros de ruta y de consulta de forma reactiva.

Ejemplo: Uso de Signals con el Router

import { Component, inject, OnInit, Signal } from '@angular/core';
import { ActivatedRoute } from '@angular/router';

@Component({
  selector: 'app-route-signal',
  template: `
    <h2>Demostración de Rutas</h2>
    <p>ID de la ruta: {{ signalId() }}</p>
  `,
})
export class RouteDemoComponent implements OnInit {
  private route = inject(ActivatedRoute);
  signalId: Signal<string> = signal('');

  ngOnInit() {
    this.route.paramMap.subscribe(params => {
      this.signalId.set(params.get('id') ?? '');
    });
  }
}

Bonus
Angular Material incluye nuevas mejoras en los estilos, características de accesibilidad y la interacción de los componentes. Por ejemplo, componentes como mat-menu y mat-select ahora son más intuitivos y fáciles de usar.
Ejemplo: Uso mejorado de mat-menu


<button mat-button [matMenuTriggerFor]="menu">Menu</button>
<mat-menu #menu="matMenu">
  <button mat-menu-item>Item 1</button>
  <button mat-menu-item>Item 2</button>
  <button mat-menu-item>Item 3</button>
</mat-menu>

Conclusión.

Angular 19 es un paso significativo en la evolución del framework. Desde el uso predeterminado de Standalone Components, pasando por las mejoras en reactividad con Signals, hasta la optimización en SSR, esta versión ofrece herramientas para construir aplicaciones más rápidas, reactivas y mantenibles.

¿Te animas para actualizar?

Guía para actualizar en :https://angular.dev/update-guide/?v=18.0-19.0&l=1

ng update @angular/core @angular/cli

Comparte tu experiencia con estas nuevas funcionalidades y sigue explorando el futuro del desarrollo con Angular. 🚀

¡Gracias a @damiansire por dar el visto bueno a este post!

El futuro de Angular es

Antonio Cardenas — Thu, 12 Sep 2024 05:28:24 +0000

Componentes independientes

Angular v19 hará que standalone: true sea el valor predeterminado para componentes, directivas y pipes.

En la V14 se introdujo una vista previa para desarrolladores de la función "standalone", que hizo posible por primera vez construir una aplicación que no dependiera de NgModules. Desde entonces, Standalone se ha estabilizado y se ha convertido en la forma recomendada por el equipo de Angular para escribir código Angular. El CLI genera componentes standalone: true de manera predeterminada, y la documentación de Angular enseña primero standalone a todos los nuevos desarrolladores de Angular. La adopción es fuerte y sigue creciendo en todo el ecosistema Angular, tanto en las aplicaciones más grandes escritas en Angular dentro de Google como en aplicaciones en toda la Internet.

Standalone no solo facilita la curva de aprendizaje y el uso del framework de Angular, sino que también ha habilitado algunas características nuevas emocionantes. En @angular/router, loadComponent simplifica significativamente la carga diferida de rutas a nivel de componente y se basa en la funcionalidad standalone. La API de Composición de Directivas permite un mejor modelo de composición para el comportamiento de los componentes, permitiendo que las directivas standalone se apliquen en la declaración de un componente o directiva anfitrión. Y, por supuesto, Deferrable Views carga de forma diferida y transparente los componentes y directivas standalone a nivel de plantilla, facilitando más que nunca la optimización de tus aplicaciones Angular.

En v19 daremos el siguiente paso, y cambiaremos el valor predeterminado de la opción standalone en componentes, directivas y pipes, para que nunca más tengas que escribir "standalone: true". Con este cambio, los componentes como:

@Component({
  standalone: true,
  imports: [UserAvatarComponent, AccountListComponent, FormsModule],
  selector: 'user-profile',
  template: './user-profile-component.html',
})
export class UserProfileComponent {…}

Ejemplo que muestra la opción standalone en Angular hoy.

Ahora se escribirán de esta manera:

@Component({
  imports: [UserAvatarComponent, AccountListComponent, FormsModule],
  selector: 'user-profile',
  template: './user-profile-component.html',
})
export class UserProfileComponent {…}

Ejemplo que muestra la opción standalone eliminada en v19

¿Qué pasa si sigo usando NgModules?

Eso está bien: no se está descontinuando la opción standalone ni los propios NgModules. Todavía podrás escribir componentes NgModule, especificando standalone: false en el decorador del componente.

¿Qué va a pasar con mi código existente, ya sea con Standalone o NgModules?

Como parte del ng update para v19, se aplicará una migración automatizada que:

Se eliminará la etiqueta standalone: true a los componentes standalone existentes, ya que será el nuevo valor predeterminado.
Se agregará standalone: false a los componentes ngModule existentes para que sigan funcionando.

Opcionalmente, podrás configurar la opción de compilador strictStandalone para exigir que solo se escriban componentes standalone en tu aplicación.

¿Qué pasa con FormsModule y otras bibliotecas npm con NgModules?

Aquí no cambiará nada. Los componentes standalone pueden seguir importando dependencias de NgModule según sea necesario, incluso con la opción de compilador strictStandalone habilitada.

Si estás creando una biblioteca publicada en NPM, tampoco necesitas hacer nada: tus componentes se comportarán correctamente cuando los usuarios los importen, independientemente de si están usando la V19 con el nuevo valor predeterminado o no.

Bonus:

En la versión 19 se introduce la capacidad de detectar si un componente o directiva importada en un componente está realmente siendo utilizado, información que será mostrada en nuestro CLI como una advertencia acerca de los imports que no estamos usando, pero que están siendo llamados.

Si no deseas ver estos warnings, puedes añadir este código a: tsconfig.json

{
  "angularCompilerOptions": {
    "extendedDiagnostics": {
      "checks": {
        "unusedStandaloneImports": "suppress"
      }
    }
  }
}

Quizás en esta versión o en las siguientes podamos ver la implementación de AI, como ser Gemini UI generativa como V0 o alguna otra herramienta útil de parte del equipo de Angular, el cual arduamente trabaja para mejorar nuestra experiencia como desarrolladores.

Articulo original aquí

Forem: Angular Firebase

MCP Skills vs MCP Tools: La forma correcta de configurar MCP Server

El modelo mental

¿Qué es una herramienta MCP?

¿Qué es un skill?

Los desventajas reales

MCP: El Impuesto de Tokens

Skills: El Problema de la Desactualización

Ambos: El problema de selección

Cómo combinarlos

Guía de Decisión Práctica

Mejorando el Flujo de Trabajo

La conclusión

Actualizando a Angular 21 usando ng mcp

¿Qué es MCP? (El "puerto USB" para la IA)

Configuración: 5 minutos para un Angular "agéntico"

1. Inicializar el servidor.

2. Conectar tu editor (por ejemplo, Cursor).

Herramientas disponibles

Herramientas experimentales

La "killer app": Migraciones conscientes del contexto

Herramienta 1: get_best_practices

Herramienta 2: onpush_zoneless_migration

Herramienta 3: search_documentation

Escenario del mundo real: La limpieza "Legacy"

El futuro: Mantenimiento continuo

Resumen: No actualices solo.

Migrando Angular 20 a 21: Guía.

Lo crítico que detienen todo

1. El Evento de Extinción de Karma (Vitest es el predeterminado)

2. HttpClient está "simplemente ahí".

3. zone.js se ha ido (para nuevas apps).

✨ Las nuevas características

1. Signal Forms (Experimental pero estable)

2. Angular Aria (Developer Preview)

3. Regex en plantillas

🛠️ La lista de verificación de actualización

Resumen

El cambio declarativo de Angular

Cómo la Nueva Estructura de Carpetas lo Cambia Todo

Angular 20: De la programación imperativa a la creación declarativa de componentes dinámicos

El laberinto de la construcción manual (Pre-Angular 20)

El panel de control unificado (Angular 20)

El poder de ViewContainerRef

Configuración con bindings

Las tres funciones de enlace en detalle

1. inputBinding()

2. outputBinding()

3. twoWayBinding()

Directivas aplicadas en tiempo de ejecución

Actualizando a Angular 20

1. La Historia Completa Detrás de la Eliminación de Karma: Más Allá de una Compilación Rota

¿Por qué Angular eliminó Karma?

Cómo es el nuevo panorama (Vitest/Jest)

La "solución temporal" explicada

2. Prerrequisitos

3. Cómo Actualizar: Comando CLI y Comparación

Comando de Actualización

Intervención Manual Requerida

Comparación con Actualizaciones Anteriores

4. Flujo de Control(Control Flow): Más que Syntaxis Decorativo

Migración Automatizada y Rendimiento

Mejores Prácticas Generales y Migraciones Adicionales

5. Standalone por Defecto: Un Cambio Arquitectónico Fundamental

6. Adiós Zone.js (Zoneless): Escapando de la "Magia" de la Detección de Cambios

7. Nueva Convención de Nombres: Por Qué Parece Complicado

8. Detalle Importante: browserslist y Soporte de Navegadores

Novedades en Angular 20

Angular 20: ¿Qué hay de nuevo?

Nuevos requisitos: TypeScript v5.8 y Node v20

Guía de estilo 2025: ¡Una bocanada de aire fresco!

APIs de Signals: ¡Mayormente Luz Verde y Estables!

Zoneless: ¡Fuera de Experimental, entra en Developer Preview!

Que se va, que se queda y que puede romper nuestro código:

Plantillas: ¡Nuevos trucos bajo la manga!

Diagnósticos extendidos: ¡El compilador te mantiene informado!

Chequeo de tipos en host: ¡Ya no más misterios!

Manejo de errores: ¡Menos errores que se escapan!

Componentes creados dinámicamente: ¡Sube de nivel!

Formularios: Aún esperando las señales, pero...

Herramienta 1: `get_best_practices`

Herramienta 2: `onpush_zoneless_migration`

Herramienta 3: `search_documentation`

El poder de `ViewContainerRef`

Configuración con `bindings`

1. `inputBinding()`

2. `outputBinding()`

3. `twoWayBinding()`

8. Detalle Importante: `browserslist` y Soporte de Navegadores

Http: APIs de `resource` Evolucionando y `keepalive`!

Propiedades de⁣ `resource`: ⁣

Ejemplo con `rxResource`