DEV Community: Ricardo Chavarria

Harness Engineering: el modelo casi nunca es el problema

Ricardo Chavarria — Tue, 22 Sep 2026 16:52:18 +0000

Hace poco monté un experimento pequeño: el mismo modelo de IA, la misma tarea de código, tres configuraciones distintas de lo que tenía permitido hacer. El resultado más revelador no fue que el agente fallara: fue ver, con evidencia en pantalla, que la calidad de lo que produce depende mucho menos del modelo de lo que solemos asumir, y mucho más de la infraestructura que construimos alrededor de él. A eso, en la industria, se le empezó a llamar harness engineering.

Los números que motivaron todo esto

A finales de 2025 los mejores agentes de codificación rondaban 50-60% de éxito en SWE-bench Verified, un benchmark que usa tareas curadas con tests ya existentes: el escenario más favorable posible. Anthropic corrió un experimento más incómodo todavía: el mismo modelo exacto, el mismo prompt, dos configuraciones. Sin ningún andamiaje alrededor: 20 minutos, 9 dólares, el resultado no funcionaba. Con una arquitectura de tres agentes coordinados: 6 horas, 200 dólares, un producto completo y funcional.

El modelo no cambió entre esas dos corridas. Todo lo demás sí.

Qué es, en realidad, un harness

La definición más precisa que he encontrado es también la más simple: un harness es todo lo que existe en la infraestructura de ingeniería que rodea a un agente y que no son los pesos del modelo. Si algo no vive dentro de la red neuronal misma, vive en el harness. Dicho como ecuación, agente completo = modelo + harness.

Esto importa porque cambia dónde uno busca soluciones. El modelo no lo entrenas tú: lo entrena Anthropic, OpenAI, Google. No puedes abrirlo y ajustar un parámetro. El harness sí lo controla por completo el equipo que lo usa, y es ingeniería de software normal: se diseña, se versiona, se prueba, se mejora con datos.

Una forma de verlo: el modelo es el piloto. El harness es el auto, la pista señalizada, y el equipo en boxes. Un piloto excelente en un auto mal calibrado, sin indicaciones de la pista y sin nadie que le avise el estado de las llantas, va a cometer errores que no tienen nada que ver con su talento al volante. Un piloto correcto (ni excepcional ni torpe) con un auto bien puesto a punto, una pista bien marcada, y un equipo que le confirma en cada vuelta qué está funcionando, corre carreras consistentes. La habilidad del piloto importa, pero deja de ser la variable que decide la carrera.

Concretamente, esa infraestructura cubre cinco frentes que se sostienen entre sí: qué instrucciones lee el agente al arrancar, qué herramientas tiene permitido usar, qué tan reproducible es el entorno donde trabaja, qué recuerda del estado entre una sesión y la siguiente, y (la que más rendimiento aporta y menos atención recibe) cómo recibe retroalimentación sobre si lo que hizo está bien o mal.

graph TD
    A[Agente completo] --> I[Instrucciones<br/>qué lee al arrancar]
    A --> H[Herramientas<br/>qué puede ejecutar]
    A --> E[Entorno<br/>qué tan reproducible es]
    A --> S[Estado<br/>qué recuerda entre sesiones]
    A --> R[Retroalimentación<br/>cómo sabe si acertó]

    style A fill:#20344b,color:#ffffff
    style R fill:#5cdb6d,color:#20344b

Ninguna de las cinco compensa la ausencia de las otras cuatro; un archivo de instrucciones perfecto no sirve de mucho si el agente no tiene forma de verificar que las siguió.

Un equipo real que documentó su propio proceso lo vivió en carne propia: con solo un README genérico, un agente con GPT-4o resolvía tareas correctamente 1 de cada 5 veces. Agregar un archivo de instrucciones subió eso a 60%. Agregar comandos de verificación explícitos, a 80%. Agregar una plantilla de progreso entre sesiones, terminó estabilizando el resultado entre 80 y 100%. El modelo fue el mismo en las cuatro mediciones: cada punto porcentual de mejora vino de una pieza distinta del harness, no de la red neuronal.

El repositorio es la única memoria que cuenta

Hay una idea incómoda detrás de esto: si una convención de tu equipo vive solo en la cabeza de alguien, o en un hilo de Slack de hace tres meses, el agente no tiene forma de saber que existe. No es que la ignore, no puede verla. Por eso la recomendación más repetida en este espacio es tan simple de decir y tan difícil de sostener en la práctica: todo lo que importa tiene que estar escrito, dentro del repo.

flowchart LR
    S[Reglas en Slack] --> R[Escríbelas en<br/>archivos del repo]
    C[Reglas en Confluence] --> R
    H[En la cabeza<br/>de alguien] --> R
    J[Tickets de Jira] --> R
    R --> N[Sesión nueva lee<br/>el repo directamente]

    style R fill:#5cdb6d,color:#20344b
    style N fill:#20344b,color:#ffffff

Una forma práctica de comprobar si ya lo lograste: abre una sesión de agente completamente nueva, sin contexto verbal, y pídele que responda cinco preguntas básicas solo leyendo el repo (qué es el sistema, cómo está organizado, cómo se ejecuta, cómo se verifica, y dónde va el trabajo). Si se traba en alguna, esa es exactamente la zona en blanco donde el agente termina adivinando.

El problema es que "escribir todo" tiene un límite real. Un equipo dejó crecer su archivo de instrucciones de 50 a 600 líneas, sumando una regla cada vez que el agente se equivocaba en algo. El rendimiento, en vez de mejorar, empezó a caer. La causa no era solo el volumen: era dónde vivía cada regla. Reorganizaron el archivo en un índice corto de 80 líneas que apunta a documentos temáticos separados, y una regla de seguridad crítica que antes estaba enterrada en la línea 300 pasó a estar cerca del principio. Sin cambiar una palabra de esa regla, su cumplimiento subió de 60% a 95%. Hay investigación de 2023 que explica por qué: "Lost in the Middle" (Liu et al.) muestra que los modelos usan mucho peor la información que está en medio de un documento largo que la que está al principio o al final.

Así se ve ese patrón en la práctica, en el archivo de instrucciones que usé para mi propio experimento:

# AGENTS.md: Contrato de Ejecución del Repositorio

Es un mapa, no una enciclopedia. Si necesitas el porqué de una
decisión, no está aquí: está en `DECISIONS.md`.

## Reglas arquitectónicas inviolables
1. Standalone obligatorio. Ningún NgModule nuevo.
2. Signals nativos para estado. Prohibido RxJS para estado local.
3. WIP = 1. Solo una funcionalidad en estado "active" a la vez.

Ocho líneas que le dicen al agente exactamente qué no negociar, y ningún párrafo explicando por qué: ese contexto vive aparte, y solo se carga si hace falta.

Por qué "una cosa a la vez" no es solo buena práctica, es matemática de contexto

Cuando un agente puede tocar cualquier archivo sin límite, tiende a abrir varios frentes al mismo tiempo y no cerrar ninguno bien. Un caso documentado con una API de 8 funcionalidades lo muestra con números: dándole rienda suelta, el agente activó 5 tareas en paralelo, produjo cerca de 800 líneas, y solo 20% de esas líneas pasaban una verificación end-to-end real. Restringido a una funcionalidad a la vez, verificada antes de pasar a la siguiente, produjo una cuarta parte del código, y esa fracción sí funcionaba, terminando más funcionalidades reales al cierre del proyecto que el enfoque abierto.

Yo lo viví de forma más directa en mi propio experimento. Con un archivo de reglas que restringía explícitamente qué dependencias se podían agregar, el agente evitó importar un módulo de Angular que hubiera sido la solución más obvia para un formulario: sin que yo se lo pidiera en el prompt, lo resolvió de otra forma porque el archivo de reglas no lo permitía. Y cuando terminó su tarea, se detuvo ahí: había otra pendiente en la misma lista, y en vez de empezarla por su cuenta, me avisó que existía y esperó instrucción. Ninguna de esas dos decisiones vino de lo que yo le escribí en el chat.

Las listas de tareas como estructura de datos, no como nota

El formato que terminé adoptando viene directo de cómo Anthropic describe su propio proceso interno: cada función pendiente es un objeto con una descripción, los pasos que la verifican, y un campo booleano que dice si pasa o no: nunca decidido por el agente mismo, siempre por el resultado real de un comando. Así se ve una entrada real de mi propio feature_list.json:

{
  "id": "CART-042",
  "description": "El descuento por cupón nunca deja el total en negativo",
  "verification_command": "ng test",
  "verification_artifact": "test-run-2026-09-21.log",
  "allowed_files": ["src/app/cart.store.ts", "src/app/cart.store.spec.ts"],
  "max_autonomous_fix_iterations": 5,
  "state": "active",
  "passes": false
}

Nada en ese objeto es ambiguo: qué archivos se pueden tocar, qué comando decide si terminó, y un booleano que solo cambia cuando ese comando corre de verdad. Es una diferencia sutil pero importante frente a la forma en que la mayoría de equipos hace seguimiento hoy: una nota de texto tipo "auth hecho, carrito casi listo" es interpretable, y lo interpretable es exactamente lo que un agente nuevo, sin memoria de la sesión anterior, no puede resolver de forma confiable.

Fíjate en max_autonomous_fix_iterations. Todo ingeniero que ha usado agentes conoce el escenario contrario: el agente intenta arreglar un test fallido, rompe otra cosa en el intento, lo vuelve a intentar, rompe algo más, y quince minutos después el diff tiene más ruido que la versión con la que empezó. Ese campo es un circuit breaker: después de cinco intentos autónomos sin éxito, el protocolo obliga a detenerse y dejarlo escrito en el handoff para que una persona lo revise, en vez de seguir iterando sin límite. La autonomía de un agente no debería ser indefinida por defecto; debería tener un techo declarado desde el principio.

Y fíjate también en verification_artifact. Hay un matiz que vale la pena admitir: el booleano passes por sí solo no prueba cómo se llegó a él. Si el comando de verificación corre contra mocks, o en un workspace con residuos de una corrida anterior, puede quedar en verde mientras algo real (el contrato de una API que cambió, por ejemplo) sigue roto. La práctica más robusta no es solo guardar si pasó, es guardar el comando exacto, el estado del entorno, y el artefacto de esa ejecución, para poder auditar después si la verificación fue real o solo parecía serlo.

El punto más difícil: declarar éxito sin haberlo verificado

Esta es, para mí, la parte más importante de todo el tema, y la que mi propio experimento terminó ilustrando mejor de lo que esperaba. Hay evidencia de hace casi una década (Guo et al., 2017) de que los modelos de lenguaje son sistemáticamente demasiado confiados en sus propias respuestas. Más reciente todavía, Anthropic encontró, en el artículo "Harness design for long-running application development" (marzo de 2026), que cuando se le pide a un agente que evalúe su propio trabajo, tiende a calificarse mejor de lo que lo haría un observador independiente.

Quise ver qué tan lejos llegaba eso. Le bloqueé a un agente el acceso a terminal por completo, sin ningún archivo de reglas de por medio, y le pedí que resolviera una función de código con un caso borde específico. Sin forma de ejecutar nada, no inventó un resultado a la ligera. Hizo algo más riguroso: trazó a mano, línea por línea, cada una de las cinco pruebas que definían si su implementación estaba correcta, incluyendo un caso de redondeo con arrastre de punto flotante que resolvió bien. Su conclusión, tal cual la escribió:

"Los 5 tests deberían pasar [...] No es lo mismo que verlos correr."

Lo sabía. Lo dijo con esas palabras. Y aun así, la afirmación que puso primero fue de alta confianza, no una declaración de incertidumbre. Corrí las pruebas después, por mi cuenta: tenía razón en los cinco casos. Pero no lo sabía cuando lo escribió, y la seguridad de esa frase hubiera sonado idéntica si se hubiera equivocado en un solo detalle.

Esto fue, literalmente, lo que trazó a mano sin poder ejecutarlo:

readonly discountAmount = computed(() =>
  Math.round(Math.min(this.subtotal(), this.subtotal() * (this.couponPercent() / 100)) * 100) / 100
);

readonly total = computed(() =>
  Math.max(0, Math.round((this.subtotal() - this.discountAmount()) * 100) / 100)
);

El Math.min evita que el descuento supere el subtotal, el Math.max(0, ...) evita el total negativo, y el doble redondeo evita el arrastre de punto flotante. Tres líneas, tres decisiones correctas, verificadas con una calculadora mental y no con un intérprete de JavaScript.

Ahí está, creo, el núcleo real del problema. No es que los agentes adivinen con descuido. Es que un razonamiento cuidadoso y una verificación real producen el mismo tono de certeza hacia afuera, y solo una de las dos tiene evidencia detrás. La solución que se sugiere para esto no es pedirle al agente que sea "más honesto", no funciona, porque el sesgo de autoevaluación es estructural, no una falla de carácter. La solución es exigir, como regla dura del sistema, que ninguna capa de verificación sea opcional: primero que el código compile, después que pase pruebas en tiempo de ejecución, y solo al final, confirmación de extremo a extremo.

Por qué "pasan los tests unitarios" no es lo mismo que "funciona"

Ese último nivel importa más de lo que parece. Los tests unitarios, por diseño, aíslan cada pieza y simulan todo lo demás: eso es justo lo que los vuelve ciegos a los problemas que solo aparecen cuando dos componentes se conectan de verdad. Hay un caso documentado de una aplicación de escritorio donde cada capa (interfaz, script intermedio, lógica de negocio) pasaba sus pruebas por separado, y aun así el flujo completo tenía cinco defectos reales: una incompatibilidad de formato entre dos módulos, datos que nunca llegaban a la pantalla, recursos que no se liberaban, comportamiento distinto según el entorno, errores que no se propagaban hasta donde alguien pudiera verlos. Ninguno de los cinco apareció en un test unitario. Todos aparecieron al correr el sistema completo.

El código que queda no es lo mismo que el porqué que se pierde

Cuando un agente trabaja varias sesiones sobre el mismo proyecto, lo que queda al final de cada una es el código: el "qué". La razón por la que se eligió una opción y no otra, el "por qué", casi nunca sobrevive al cierre. Una sesión nueva, sin ese contexto, puede terminar "optimizando" una decisión que en realidad fue deliberada.

flowchart TD
    subgraph SIN["Sin artefactos de continuidad"]
        direction LR
        A1[Sesión nueva] --> A2[Sin memoria] --> A3[Re-explora<br/>~15 min] --> A4[Puede duplicar<br/>trabajo]
    end
    subgraph CON["Con artefactos de continuidad"]
        direction LR
        B1[Sesión nueva] --> B2[Lee PROGRESS.md +<br/>DECISIONS.md + git log] --> B3[Retoma en<br/>~3 min]
    end

    style A4 fill:#ea4335,color:#ffffff
    style B3 fill:#5cdb6d,color:#20344b

Un caso real lo muestra con números: un sistema de blog con autenticación, 12 puntos de función, 5 sesiones estimadas. Sin ningún archivo de estado, para la sesión 5 solo se habían completado 7 de las 12 funciones, y 3 de esas tenían errores ocultos por la deriva acumulada. Con un diario de progreso y un registro de decisiones, las 12 quedaron completadas y verificadas en las mismas 5 sesiones, con el tiempo de "reconstrucción" al abrir cada sesión bajando cerca de 78%.

Hay un fenómeno documentado por Anthropic que explica parte de esto: cuando un agente nota que el contexto de la sesión se está agotando, tiende a apresurarse y saltar verificaciones que normalmente haría. Un buen registro de estado no es solo comodidad para retomar más rápido: reduce las ventanas donde el agente siente esa presión y empieza a cortar esquinas.

Un dato menos citado: por qué el sistema necesita poder explicarse

Hay una dimensión de esto que se discute menos, y que a mí me pareció de las más aplicables: no basta con que el sistema sepa si algo falló, tiene que poder decir por qué. Un flujo de trabajo con tres roles (uno que planea, uno que genera, uno que evalúa) probó una misma tarea con y sin ese nivel de detalle en la retroalimentación. Sin él, el ciclo se volvía una serie de reintentos a ciegas: 3-4 rondas, cerca de 45 minutos, resultado apenas aceptable. Con un contrato explícito de qué se esperaba y una rúbrica de evaluación concreta, la misma tarea se resolvió en una sola iteración, en unos 15 minutos, con mejor resultado: tres veces más eficiente. El problema, cuando existía, siempre había sido el mismo tipo de tarea: lo que cambió fue si el sistema podía explicarse a sí mismo qué estaba mal.

Cerrar bien también es parte del trabajo

Una sesión de agente no debería considerarse terminada solo porque el código "funciona". Debería dejar un estado del que cualquiera (humano o el mismo agente en la siguiente sesión) pueda partir sin adivinar: que el build compile, que las pruebas pasen, que quede un registro legible de qué se hizo, que no queden artefactos de depuración regados por el código, y que el siguiente arranque no dependa de reconstruir contexto perdido. Un proyecto real medido a lo largo de 12 semanas sin esa disciplina terminó con poco más de dos tercios de sus builds compilando correctamente, y arranques de sesión que tomaban una hora. Con la disciplina puesta, esos mismos números se mantuvieron cerca del 97% y bajaron a menos de diez minutos.

El modelo y la herramienta no son lo mismo que el harness

Vale la pena separar una cosa más: la herramienta que usas para hablar con el agente ya trae consigo parte de esta infraestructura: un sistema de permisos, gestión de la ventana de contexto, acceso a herramientas. Eso no es algo que uno construye. Lo que sí hay que construir es todo lo específico del propio proyecto: qué arquitectura respetar, qué se puede tocar y qué no, qué comando decide si algo está realmente terminado. En mis tres corridas, la herramienta y el modelo fueron exactamente los mismos de principio a fin. La variable que cambió, y la única que explica la diferencia de resultado, fue esa segunda capa.

La conclusión práctica

Cuando un agente de código produce algo mal hecho, el reflejo casi universal es pensar en cambiar de modelo. Es, casi siempre, la opción más cara y la menos efectiva. Antes de eso, vale la pena preguntarse si existe un archivo que diga qué reglas seguir, si hay una forma de que el sistema verifique su propio trabajo sin depender de que el agente decida hacerlo, y si esa verificación es realmente obligatoria o solo una posibilidad entre varias. Ese conjunto de decisiones, no los parámetros del modelo, es lo que terminó marcando la diferencia en cada una de mis pruebas.

Fuentes

Los conceptos, casos de estudio y datos de este artículo se apoyan en:

Anthropic, Effective harnesses for long-running agents: el experimento del editor de juegos y el formato de feature_list.json.
Anthropic, Harness design for long-running application development (marzo 2026): el sesgo de autoevaluación y la ansiedad de contexto.
Guo, Pleiss, Sun y Weinberger, On Calibration of Modern Neural Networks (2017).
Liu et al., Lost in the Middle: How Language Models Use Long Contexts (2023).
Learn Harness Engineering.

Adiós Karma, Hola Vitest: El Futuro del Testing en Angular

Ricardo Chavarria — Fri, 27 Jun 2025 21:45:52 +0000

A lo largo de los años, quienes hemos trabajado estrechamente con Angular hemos presenciado una evolución constante, tanto en el framework como en su ecosistema. Con Angular v20, se introduce uno de los avances más relevantes en el ámbito del testing: la adopción experimental de Vitest como nuevo motor de pruebas. Este cambio no solo responde a la necesidad de modernizar la experiencia de desarrollo, sino que también señala el comienzo de una transición gradual lejos de Karma, el sistema de testing que ha acompañado a Angular desde sus inicios.

El Adiós a un Clásico: ¿Qué Pasó con Karma?

Durante más de una década, Karma fue el test runner por defecto en Angular, desempeñando un papel fundamental en el ecosistema. Diseñado para ejecutar pruebas en navegadores reales y adaptarse a múltiples entornos, fue una solución efectiva durante el período en que Webpack era la herramienta predominante en Angular.

Sin embargo, a mediados de 2024, el equipo de Karma marcó oficialmente el proyecto como obsoleto, publicaron un aviso en su repositorio de GitHub indicando que el desarrollo activo se detiene y se recomienda buscar alternativas modernas. Ante esto, el equipo de Angular ha comenzado a ofrecer soporte experimental para Vitest a partir de Angular v20.

Vitest: Testing Moderno para el Ecosistema Web

Vitest es un test runner moderno y ultrarrápido diseñado para integrarse de forma nativa con Vite, el nuevo estándar en herramientas de desarrollo frontend. Inspirado en la experiencia de desarrollo de Jest, pero construido sobre tecnologías modernas como ES Modules, esbuild y Vite, Vitest introduce una nueva forma de escribir y ejecutar pruebas unitarias.

A diferencia de herramientas tradicionales como Karma, que dependen de navegadores reales y procesos más pesados, Vitest está optimizado para el rendimiento, la simplicidad y la experiencia de desarrollador. Su ejecución en memoria, su capacidad para aprovechar el sistema de hot module replacement (HMR) de Vite y su compatibilidad con TypeScript de forma nativa, lo hacen ideal para entornos modernos como Angular, React, Vue y otros.

Beneficios clave de Vitest

Rápido desde el inicio: Ejecuta pruebas casi al instante gracias a su arquitectura basada en ESM y Vite.
Integración nativa con Vite: Aprovecha el sistema de build moderno de Vite sin configuración adicional.
Mejor experiencia de desarrollo: Soporta watch mode, pruebas en caliente y mensajes de error claros.
Compatible con Jest: Usa una API similar, facilitando la adopción o migración.
Versátil: Funciona en Node y con entornos simulados de navegador (como jsdom).

Configurando Vitest en un proyecto Angular (v20+)

Instala las dependencias necesarias:

npm install vitest jsdom --save-dev

Configura angular.json

"test": {
  "builder": "@angular/build:unit-test",
  "options": {
    "tsConfig": "tsconfig.spec.json",
    "buildTarget": "::development",
    "runner": "vitest"
  }
}

Esto indica al Angular CLI que utilice Vitest como runner en lugar de Karma.

Ajusta los imports en tus archivos de prueba:

Ahora debes actualizar tus archivos de prueba para incluir las importaciones correctas.

import { describe, beforeEach, it, expect } from 'vitest';

Ejecuta las pruebas con el comando habitual:

ng test

Este comando ejecutará Vitest en modo de observación (watch), permitiendo resultados inmediatos ante cada cambio.

Consideraciones y Limitaciones Actuales

Aunque la integración de Vitest en Angular es un avance prometedor, es importante tener en cuenta que el soporte aún se encuentra en fase experimental. Esto implica algunas limitaciones que los desarrolladores deben considerar antes de migrar completamente:

Cobertura de código: Aunque Vitest soporta generación de reportes de cobertura (coverage), es necesario configurarlo explícitamente y puede requerir ajustes adicionales en proyectos Angular complejos.
Depuración en navegadores reales: A diferencia de Karma, que ejecuta pruebas directamente en navegadores, Vitest simula el entorno mediante jsdom. Esto es suficiente para la mayoría de pruebas unitarias, pero podría no reflejar con exactitud ciertos comportamientos específicos del navegador.
Pruebas E2E: Vitest no reemplaza a herramientas de pruebas de extremo a extremo como Cypress o Playwright, por lo que sigue siendo necesario usarlas para flujos de usuario completos.

Conclusión

La integración de Vitest en Angular marca un cambio importante en la forma en que abordamos el testing en Angular. El fin de una era con Karma y la transición hacia herramientas más modernas y rápidas no solo mejora la experiencia del desarrollador, sino que alinea Angular con las prácticas y tecnologías que ya predominan en el ecosistema frontend actual.

A medida que la comunidad lo adopte y el equipo de Angular avance en su estabilización, podemos esperar más mejoras, compatibilidad avanzada con entornos reales de navegador y mayor integración con las herramientas del ecosistema.

Angular 20 y el futuro sin Zone.js: La revolución "Zoneless" ha llegado (a Developer Preview)

Ricardo Chavarria — Tue, 10 Jun 2025 05:45:52 +0000

Si has estado siguiendo la evolución de Angular, sabrás que cada nueva versión trae consigo mejoras y optimizaciones. Pero de vez en cuando, llega una versión que no es solo una actualización, sino un verdadero punto de inflexión. Angular 20 es una de esas versiones, y trae consigo la promoción oficial a Developer Preview de una de las características más esperadas y transformadoras: la ejecución de aplicaciones sin Zone.js.

¿Por qué tanto revuelo? Porque aunque no está listo para producción, nos invita a probar un cambio fundamental en cómo Angular gestiona la detección de cambios, abriendo la puerta a un rendimiento sin precedentes y a un código más explícito y predecible.

En este artículo, vamos a desglosar qué significa "zoneless", por qué es una revolución y cómo puedes empezar a experimentar con la próxima generación de aplicaciones Angular. ¡Vamos allá!

El "Problema" Silencioso: ¿Qué es Zone.js y por qué queremos dejarlo atrás?

Para entender la importancia de un Angular "zoneless", primero debemos entender qué es y qué hace Zone.js.

Desde sus inicios, Angular ha dependido de Zone.js para saber cuándo debe ejecutar la detección de cambios. Zone.js es una librería que utiliza una técnica llamada "monkey-patching" para interceptar casi todas las operaciones asíncronas del navegador: setTimeout, Promise, eventos del DOM (como clics), peticiones fetch, etc.

Cuando una de estas operaciones se completa, Zone.js notifica a Angular, que por precaución, inicia un ciclo de detección de cambios que recorre todo el árbol de componentes.

Las desventajas de este enfoque son claras:

Sobrecarga de Rendimiento (Overhead): La detección de cambios se ejecuta con más frecuencia de la necesaria.
Tamaño del Bundle: Zone.js añade un peso extra al bundle final de tu aplicación.
La "Magia" es Impredecible: El "monkey-patching" puede causar conflictos con librerías de terceros o nuevas APIs del navegador.
Complejidad Oculta: Oculta el mecanismo de reactividad. El desarrollador no tiene control explícito sobre cuándo se actualiza la UI.

La Solución Elegante: ¡Hola, Detección de Cambios "Zoneless"!

La era "zoneless" elimina por completo la dependencia de Zone.js. En su lugar, Angular adopta un modelo de reactividad mucho más fino, explícito y eficiente.

El protagonista de esta historia son las Señales (Signals).

Introducidas en Angular 16, las Signals son el pilar fundamental del futuro "zoneless". Una señal es un contenedor reactivo para un valor que puede notificar a sus consumidores cuando ese valor cambia.

El nuevo modelo funciona así:

Cuando el valor de un Signal cambia, Angular sabe exactamente qué componentes y qué partes de la vista dependen de esa signal y actualiza únicamente esas partes. No hay un barrido completo del árbol de componentes. La actualización es local, granular y quirúrgica.

Esto es un cambio de paradigma. Pasamos de un modelo de "revisar todo por si acaso" a un modelo de "actualizar solo esto porque sé que ha cambiado".

Aclaración Crucial: ¿Necesito "Zoneless" para usar Signals?

Esta es una de las preguntas más importantes: ¿debo esperar a "zoneless" para empezar a usar Signals?

La respuesta es un rotundo NO.

Puedes y debes empezar a usar Signals hoy mismo en tus aplicaciones Angular (v16+), incluso si siguen utilizando Zone.js. De hecho, son dos conceptos relacionados pero independientes:

Signals NO necesitan Zoneless para funcionar. Ya ofrecen grandes beneficios en un entorno con Zone.js, proporcionando actualizaciones de vista más rápidas y un código más reactivo.
Pero Zoneless SÍ necesita Signals. Sin la "magia" de Zone.js para detectar cambios, las Signals se convierten en el mecanismo principal y explícito para que Angular sepa qué partes de la UI necesitan ser actualizadas.

Al usar Signals en una aplicación con Zone.js, tu código ya se vuelve más eficiente. Cuando finalmente migres a "zoneless", la transición será mucho más sencilla porque tus componentes ya estarán preparados.

Manos a la Obra: ¿Cómo Funciona en la Práctica?

Antes: Con Zone.js y Propiedades de Clase

// contador.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-contador',
  template: `
    <h2>Contador (con Zone.js)</h2>
    <p>Valor actual: {{ count }}</p>
    <button (click)="incrementar()">Incrementar</button>
  `
})
export class ContadorComponent {
  count = 0;

  incrementar() {
    this.count++;
  }
}

Aquí, cuando incrementar() se ejecuta, Zone.js intercepta el evento click, notifica a Angular y se inicia la detección de cambios que actualizará la vista.

Ahora: El Futuro "Zoneless" con Signals

¡Nota importante! La siguiente funcionalidad está en Developer Preview. Esto significa que la API es funcional, pero podría cambiar y no se recomienda para aplicaciones en producción. Es el momento perfecto para probarla en proyectos personales y para dar feedback valioso al equipo de Angular.

Para habilitar el modo "zoneless", primero debemos configurar el arranque de nuestra aplicación.

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    // ¡Aquí está la magia! Activamos el modo zoneless.
    provideZonelessChangeDetection()
  ]
}).catch(err => console.error(err));

Ahora, podemos refactorizar nuestro componente para usar Signals.

// contador-zoneless.component.ts
import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-contador-zoneless',
  standalone: true, // ¡Los componentes Standalone son el camino!
  template: `
    <h2>Contador (Zoneless con Signals)</h2>
    <!-- Para leer el valor de una señal, la invocamos como una función -->
    <p>Valor actual: {{ count() }}</p> 
    <button (click)="incrementar()">Incrementar</button>
  `
})
export class ContadorZonelessComponent {
  // Creamos la señal con un valor inicial de 0
  readonly count = signal(0);

  incrementar() {
    // Usamos .update() para modificar el valor basado en el valor anterior
    this.count.update(currentValue => currentValue + 1);
  }
}

En este nuevo componente, no hay Zone.js. Cuando llamamos a this.count.update(), la signal notifica directamente al template, y Angular actualiza solo el párrafo <p>. Eficiencia en estado puro.

Beneficios Clave (y Potenciales) de la Arquitectura Zoneless

Adoptar este nuevo enfoque traerá ventajas monumentales una vez sea estable:

🚀 Rendimiento Superior: Actualizaciones increíblemente rápidas y localizadas.
📦 Bundle Más Pequeño: Al eliminar Zone.js, reducimos el tamaño final de la aplicación.
🧠 Código Más Predecible y Explícito: Se acaba la "magia". Tienes el control total sobre las actualizaciones.
🤝 Mejor Interoperabilidad: Se eliminan los conflictos con librerías de terceros.

Resource API en Angular: La revolución declarativa de los datos asincrónicos

Ricardo Chavarria — Sun, 01 Jun 2025 03:54:13 +0000

Reactividad Declarativa con `resource()`, `rxResource()` y `httpResource()` en Angular

Introducción: Un nuevo paradigma en la reactividad de Angular

Angular está viviendo una de sus transformaciones más importantes desde la introducción de Ivy. Con Angular v17 y especialmente v18/v19, el framework ha empezado a adoptar un enfoque mucho más declarativo y reactivo, alejándose del tradicional modelo basado en RxJS y async pipe como eje central de la reactividad.

Las nuevas APIs resource(), rxResource() y httpResource() son un ejemplo claro de este cambio. Diseñadas para manejar flujos asincrónicos de datos de forma declarativa, estas APIs permiten simplificar la lógica de datos en componentes, reducir boilerplate y aprovechar el nuevo sistema de signals de Angular.

Este artículo explora a fondo estas APIs, con ejemplos prácticos y comparaciones, para ayudarte a comprender cuándo, por qué y cómo usarlas de forma efectiva.

`resource()`: Reactividad declarativa con Promesas

La función resource() es la forma más sencilla de integrar flujos asincrónicos (basados en Promesas) dentro del sistema de signals de Angular.

Uso básico de `resource()`

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

const userId = signal(42);

const userResource = resource({
  params: () => ({ id: userId() }),
  loader: async ({ params }) => {
    const res = await fetch(`/api/users/${params.id}`);
    return res.json();
  },
});

Acceso a estados reactivos

const user = computed(() => userResource.value());
const loading = computed(() => userResource.status() === 'loading');
const error = computed(() => userResource.error());

Esta declaración permite que Angular se encargue de manejar estados de carga, cancelación, errores y la reactividad sin necesidad de suscripciones o async pipe.

`rxResource()`: Flujos RxJS reactivos en el mundo de Signals

rxResource() permite envolver un Observable y convertirlo en una resource reactiva, combinando lo mejor de RxJS con el sistema de signals.

Ejemplo práctico con `HttpClient`

import { inject } from '@angular/core';
import { rxResource } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';

const http = inject(HttpClient);
const searchTerm = signal('');

const searchResults = rxResource({
  params: () => searchTerm(),
  loader: (term) => http.get(`/api/search?q=${term}`),
});

Ventajas de `rxResource()`

Compatible con servicios existentes que retornan observables
Cancelación automática cuando cambian los parámetros
Integración directa con operadores de RxJS

`httpResource()`: Declaración más simple para operaciones HTTP

Si estás usando HttpClient y necesitas una resource, httpResource() simplifica la sintaxis eliminando la necesidad de definir el loader manualmente.

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

const userId = signal(1);

const userResource = httpResource({
  params: () => ({ id: userId() }),
  url: ({ params }) => `/api/users/${params.id}`,
});

Características clave

Usa internamente HttpClient
Incluye cancelación, manejo de errores y estados reactivos
Requiere menos configuración

Comparación de las tres APIs

Característica	`resource()`	`rxResource()`	`httpResource()`
Fuente de datos	Promesa	Observable RxJS	HttpClient
Estados (loading/error)	✓	✓	✓
Cancelación automática	✓	✓	✓
Integración RxJS	Parcial	Total	Parcial
Sintaxis simplificada	Media	Media	Alta
Ideal para	Carga remota	Streams continuos	APIs REST simples

Casos de uso reales

Búsquedas reactivas

const query = signal('');

const results = resource({
  params: () => ({ q: query() }),
  loader: async ({ params }) => {
    return fetch(`/api/search?q=${params.q}`).then(res => res.json());
  }
});

Paginación

const page = signal(1);
const pageSize = signal(10);

const paginatedData = rxResource({
  params: () => ({ page: page(), size: pageSize() }),
  loader: ({ page, size }) => http.get(`/api/data?page=${page}&size=${size}`),
});

Formularios y edición

Puedes usar resource().refresh() tras guardar los cambios para volver a cargar la data desde el servidor.

const userResource = resource(...);

async function saveChanges(user: User) {
  await http.put(`/api/users/${user.id}`, user);
  userResource.refresh();
}

Ventajas frente a enfoques tradicionales

Eliminan la necesidad de async pipe
No requieren subscribe() manual ni destrucción de observables
Simplifican la composición de lógica reactiva
Mejoran la legibilidad y mantenibilidad

Conclusión

Las APIs resource(), rxResource() y httpResource() representan un cambio fundamental hacia una arquitectura declarativa y basada en signals en Angular. Aunque aún están en fase experimental, su adopción ofrece una experiencia de desarrollo moderna, con menos boilerplate, mejor manejo de estado y cancelación automática de solicitudes.

Estas herramientas permiten a los desarrolladores escribir aplicaciones más limpias, predecibles y fácilmente testeables. A medida que Angular sigue evolucionando, adoptar este paradigma puede ofrecer ventajas competitivas y mayor escalabilidad en proyectos de mediano y largo plazo.

Angular se reinventa: Bienvenido a la era de Angular v18

Ricardo Chavarria — Thu, 23 May 2024 22:04:13 +0000

La espera ha terminado. Angular v18, la última versión del popular framework de Google para desarrollo web, ha llegado para revolucionar la forma en que creamos aplicaciones web. Con un enfoque claro en la optimización del rendimiento y la introducción de nuevas características que simplifican el desarrollo.

Change detection - Zoneless (Experimental)

Tradicionalmente, una librería llamada ZoneJS se ha encargado de activar la detección de cambios en Angular. Sin embargo, esta librería ha presentado ciertas desventajas en términos de rendimiento y experiencia de desarrollo.

Angular v18 introduce una nueva forma de activar la detección de cambios. En lugar de depender de ZoneJS para saber cuándo es posible que algo haya cambiado, Angular ahora puede programar una detección de cambios por sí mismo. Toma en cuenta que esto está en una etapa experiemental.

Para hacerlo, se agregó un nuevo programador al framework (llamado ChangeDetectionScheduler) y este programador se usa internamente para activar la detección de cambios. Este nuevo programador está habilitado de forma predeterminada en v18, incluso si usa ZoneJS. Sin embargo, el objetivo es alejarse progresivamente de ZoneJS y confiar únicamente en este nuevo planificador.

Con este nuevo programador, Angular ya no depende únicamente de ZoneJS para activar la detección de cambios. De hecho, el nuevo programador activa una detección de cambios cuando se activa un host o un escucha de plantilla, cuando se adjunta o elimina una vista, cuando una tubería asíncrona detecta una nueva emisión, cuando se llama al método markForCheck(), cuando se establece un valor de señal , etc. Lo hace llamando a ApplicationRef.tick()internamente.

Experimentando con zoneless

Puedes probar el soporte para zoneless en Angular despues de actualizar a la versión 18, solo necesitas hacer un pequeño cambio en el boostrap de tu aplicación.

bootstrapApplication(App, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

Al hacerlo, Angular ya no dependerá de ZoneJS para activar la detección de cambios. Así que puedes eliminar ZoneJS de tu aplicación si lo deseas (y si no tienes dependencias que dependan de él, por supuesto). En ese caso, puedes eliminar ZoneJS de los polyfills en tu archivo angular.json.

Si tus componentes son compatibles con la estrategia de detección de cambios ChangeDetectionStrategy.OnPush de Angular, también deberían ser en su mayoría compatibles con zoneless, lo que hará que su transición sea perfecta.

De cara al futuro, un Angular sin ZoneJS abre un abanico de
posibilidades para los desarrolladores:

Mayor compatibilidad: Facilita la creación de micro-frontends y la interoperabilidad con otros frameworks.
Rendimiento mejorado: Tiempos de renderizado iniciales más rápidos y mejor rendimiento en tiempo de ejecución.
Aplicaciones más ligeras: Tamaños de paquete más pequeños y tiempos de carga de página más rápidos.
**Depuración simplificada: **Rastros de pila más legibles que facilitan la identificación y resolución de errores.
Procesos de depuración más sencillos: Elimina la complejidad asociada a ZoneJS, haciendo que la depuración sea más intuitiva.

La mejor forma de utilizar zoneless es con componentes que utilicen signals. Por ejemplo:

@Component({
  ...
  template: `
    <h1>Hello from {{ name() }}!</h1>
    <button (click)="handleClick()">Go Zoneless</button>
  `,
})
export class App {
  protected name = signal('Angular');

  handleClick() {
    this.name.set('Zoneless Angular');
  }
}

En el ejemplo anterior, al hacer clic en el botón se invoca el método handleClick, que actualiza el valor del signal y actualiza la interfaz de usuario. Esto funciona de manera similar a una aplicación que usa ZoneJS, con pocas diferencias. Con ZoneJS, Angular ejecutaba la detección de cambios cada vez que el estado de la aplicación podía haber cambiado. Sin zonas, Angular limita esta verificación a menos activadores, como actualizaciones de signals. Este cambio también incluye un nuevo programador con fusión para evitar verificar cambios varias veces consecutivas.

Async/await nativo en aplicaciones zoneless

ZoneJS tiene una particularidad: no puede funcionar con async/await. Quizás no lo sepas, pero cada vez que usas async/await en tu aplicación, la CLI transforma tu código para usar promesas "normales". Esto se llama reducción de nivel, ya que transforma el código ES2017 (async/await) en código ES2015 (promesas regulares).

Hoy en día, si creas una aplicación que utiliza la detección de cambios sin ZoneJS (experimenta), Angular CLI utilizará el async/await nativo sin bajarlo a promesas. Esto mejorará la depuración y hará que tus paquetes sean más pequeños.

Signals - Propuesta de Estandarización

Esto no es exactamente nuevo en Angular v18, ya que en la version v17 se anuncio los nuevos signals inputs, signal queries y la nueva sintaxis de input y ouput.

Ahora con la llegada de la de Angular v18 tenemos las Siganal APIs en developer preview.

Cada vez los signals se están volviendo mucho más populares, de hecho ya existe una propuesta para estandarizar los signals y que puedan ser agregados a JavaScript. Puedes profundizar en la propuesta o en este interesante blog post para conocer más al respecto.

new Signal.State() sería el equivalente de signal() en Angular. new Signal.Computed() sería el equivalente de computed(). No hay equivalentes para el efecto: como todos los frameworks tienen necesidades ligeramente diferentes, esto queda fuera del alcance de la propuesta, y los frameworks pueden implementarlo como mejor les parezca basándose en el nuevo Signal.subtle.Watcher().

Dato curioso: ¡El polyfill de Signal actual en la propuesta se basa en la implementación de Angular!

Built-in control flow - Ahora es estable

La sintaxis de Built-in control flow introducida en Angular v17 ya no es una función en developer preview para desarrolladores y se puede utilizar de forma segura. Como ahora es la forma recomendada de escribir plantillas, debería considerar usarla en tus aplicaciones. Puede migrar fácilmente tus aplicaciones utilizando los esquemas proporcionados. Por ejemplo:

ng generate @angular/core:control-flow

Más información: Guía oficial

Deferrable views - Ahora es estable

La sintaxis @defer también es estable. @defer te permite definir un bloque de plantilla que se cargará de forma diferida cuando se cumpla una condición (con todos los componentes, canalizaciones, directivas y bibliotecas utilizadas en este bloque también cargados de forma diferida).

Más información: Guía oficial

Material v3 - Ahora es estable

Hace unos meses atras Angular introdujo suporte experimental para Material 3, ahora con la llegada de Angular v18 tenemos soporte estable, ahora podemos utilizar los nuevos features de Material 3 en nuestros prouyectos de Angular con Angular Material.

Mejoreas en el server-side rendering

Con Angular v18 llegaron algunas nuevas características relacionas al Server Side Rendering (SSR).

Repetición de eventos

Hace unos meses el equipo de Angular anuncion un proyecto en curso a largo plazo que tenia como objetivo fusionar Angualar y el framework interno llamado Google Wiz. Angular y Wiz han estado sirviendo a dos segmentos diferentes de aplicaciones en el pasado: Wiz se usó principalmente para aplicaciones centradas en el consumidor, muy centrada en el rendimiento y Angular se centró en la productividad y la experiencia del desarrollador.

Como resultado de esta fusión Wiz integró profundamente Angular Signals en su modelo de renderizado. El equipo de Angular anunciuo que ahora Youtube usa Angular Signal, de la misma manera, Angular ahora ofrece cada vez más funciones centradas en el rendimiento, como la hidratación parcial, sobre las que compartiré más en un momento.

Ahora es posible registrar las interacciones del usuario durante la fase de hidratación y reproducirlas cuando la aplicación esté completamente cargada. Como sabrá, la fase de hidratación es la fase en la que el HTML renderizado por el servidor se transforma en una aplicación Angular completamente funcional, donde se agregan oyentes a los elementos existentes.

Pero durante esta fase, el usuario puede interactuar con la aplicación, y estas interacciones se pierden (si el proceso de hidratación no es lo suficientemente rápido).

Entonces, para algunas aplicaciones, puede resultar interesante registrar estas interacciones y reproducirlas cuando la aplicación esté completamente cargada.

Ejemplo:

Aunque la mayoría de los desarrolladores no trabajarán directamente con la reproducción de eventos, su utilidad es evidente. Imaginemos un sitio web de comercio electrónico con tiempos de carga lentos, como si tuviera una mala conexión. Un usuario intenta añadir varios productos al carrito mientras la página aún está cargando. Sin la reproducción de eventos, esas acciones se perderían.

Con Angular v18, la reproducción de eventos entra en juego: el sistema registra las acciones del usuario incluso antes de que la página sea interactiva. Una vez que la página carga completamente, los eventos se reproducen, y los productos se añaden al carrito como si no hubiera habido ningún problema de carga.

La función de repetición de eventos está disponible en la versión 18 en developer preview. Puedes habilitarlo usando withEventReplay(), por ejemplo:

bootstrapApplication(App, {
  providers: [
    provideClientHydration(withEventReplay())
  ]
});

Para que la reproducción de eventos funcione, Angular inyecta un pequeño script al principio de tu página HTML. Este script tiene la misión de "reproducir" las acciones del usuario que ocurrieron mientras la página aún se estaba cargando.

¿Cómo lo hace? Primero, coloca un "oyente" en la raíz del documento que captura eventos específicos, como clics o doble clics, utilizando una técnica llamada delegación de eventos. Angular sabe qué eventos escuchar porque los recopiló durante el renderizado en el servidor.

El resultado final es que cuando la página está completamente cargada, este script inteligente reproduce las acciones del usuario, activando las funciones correspondientes como si nada hubiera pasado. Aunque no todas las aplicaciones se beneficiarán de esta característica, sin duda es una herramienta poderosa para aquellos casos donde la interacción temprana del usuario es crucial.

Experiencia de depuración mejorada

Angular DevTools se ha actualizado para brindarte una mejor visión del proceso de hidratación. Ahora puedes ver el estado de hidratación de cada componente gracias a un nuevo ícono junto a su nombre. Y si quieres una vista general, activa el modo de superposición para ver al instante qué componentes ya están hidratados en la página. ¿Lo mejor? Si tu aplicación tiene errores de hidratación, Angular DevTools te los mostrará directamente en el explorador de componentes.

Soporte para Hidratación en CDK y Material

En la versión 17, algunos componentes de Angular Material y CDK optaron por no hidratarse, lo que provocó su repetición. A partir de la versión 18, todos los componentes y primitivas son totalmente compatibles con la hidratación.

Hidratación parcial

El equipo de Angular anuncio durante el Google I/O la hidratación parcial que es una técnica que te permite hidratar tu aplicación de forma incremental después del renderizado del lado del servidor. La hidratación incremental de tu aplicación permite cargar menos JavaScript por adelantado y mejora el rendimiento.

Imagina que puedes cargar tu aplicación web por partes, como si fuera un rompecabezas, empezando por las piezas más importantes. Eso es precisamente lo que permite la hidratación incremental: en lugar de cargar todo el código JavaScript de golpe, solo se carga lo esencial para mostrar la página rápidamente. El resto se va añadiendo sobre la marcha, mejorando significativamente el rendimiento.

La hidratación parcial lleva esta idea un paso más allá. Basándose en el concepto de "vistas diferibles", permite renderizar en el servidor el contenido principal de una sección específica de la página (marcada con @defer). Luego, en el navegador del usuario, Angular carga el código JavaScript asociado y "hidrata" esa sección solo cuando se cumplen ciertas condiciones, como por ejemplo, cuando el usuario interactúa con ella. De esta forma, se reduce la cantidad inicial de JavaScript y la página se vuelve más rápida e interactiva. Por ejemplo:

@defer (render on server; on viewport) {
  <app-calendar/>
}

El bloque de arriba representará el componente de calendario en el servidor. Una vez que llegue al cliente, Angular descargará el JavaScript correspondiente e hidratará el calendario haciéndolo interactivo solo después de que ingrese a la ventana gráfica.

Firebase App Hosting

Firebase presentó en Google I/O su nuevo servicio de App Hosting, diseñado para simplificar al máximo la creación y publicación de aplicaciones web dinámicas.

¿Qué lo hace tan especial? App Hosting se integra a la perfección con el ecosistema de Firebase, ofreciendo:

Soporte nativo para Angular: Configuración y despliegue sin complicaciones.
Integración con GitHub: Facilita el flujo de trabajo desde el desarrollo hasta la producción.
Conexión directa con otros servicios de Firebase: Aprovecha al máximo Authentication, Cloud Firestore, Vertex AI y más, sin configuraciones complejas.

Con App Hosting, Firebase se convierte en una solución aún más completa para construir y escalar aplicaciones Angular de forma rápida y segura. Dale un vistazo a la guía

Nuevo paquete de construcción

Angular está simplificando su sistema de construcción de proyectos. Para ello, han creado un nuevo paquete llamado @angular/build, que se centra en las herramientas modernas como esbuild y Vite.

Antes, todas las herramientas de construcción, incluyendo Webpack, estaban juntas en @angular-devkit/build-angular. Al separar esbuild y Vite en su propio paquete, @angular/build se vuelve más ligero y eficiente.

Si actualizas tu proyecto a Angular v18, tendrás la opción de migrar a este nuevo sistema. La migración actualizará tu archivo angular.json para que use @angular/build en lugar de @angular-devkit/build-angular y ajustará las dependencias en tu package.json.

Pero no te preocupes, esta migración solo se realizará si no utilizas Webpack en tu proyecto. Si tus pruebas se basan en Karma, que a su vez usa Webpack, no se hará ningún cambio. En resumen, Angular te ofrece un camino más limpio y moderno para construir tus aplicaciones, sin afectar proyectos que aún dependen de Webpack.

Redirecciones de ruta como funciones

Angular ahora te da más control sobre las redirecciones en tus aplicaciones. Antes, solo podías redirigir a una ruta fija, sin importar el contexto. ¡Pero eso ha cambiado!

Con Angular v18, la propiedad redirectTo de una ruta ahora acepta una función, llamada RedirectFunction, que te permite crear redirecciones dinámicas y mucho más inteligentes.

¿Cómo funciona? La RedirectFunction recibe información sobre la ruta actual, como parámetros o consultas, y en base a eso, decide a dónde redirigir al usuario. Además, puedes usar servicios dentro de esta función, lo que abre un abanico de posibilidades para crear reglas de redirección sofisticadas. Esta función también es similar a las guardias y se ejecuta en el inyector de entorno: esto significa que puede inyectar servicios si es necesario. La función puede devolver una cadena o un UrlTree. Por ejemplo:

const routes: Routes = [
  { path: "my-component", component: MyComponent },
  {
    path: "user-page",
    redirectTo: ({ queryParams }) => {
      const errorHandler = inject(ErrorHandler);
      const userIdParam = queryParams['userId'];
      if (userIdParam !== undefined) {
        return `/user/${userIdParam}`;
      } else {
        errorHandler.handleError(new Error('Se intentó navegar a la página del usuario sin ID de usuario.'));
        return `/not-found`;
      }
    },
  },
  { path: "user/:userId", component: OtherComponent },
];

HttpClientModule - Depreación

Angular sigue avanzando hacia un futuro donde los componentes independientes (Standolone components) son la norma, y esto significa que algunos módulos tradicionales están empezando a ser reemplazados.

En Angular v18, los módulos HttpClientModule (junto con HttpClientTestingModule, HttpClientXsrfModule, y HttpClientJsonpModule) han sido marcados como obsoletos. Esto no significa que ya no funcionen, pero sí que es hora de empezar a usar alternativas más modernas.

En su lugar, ahora puedes utilizar las funciones provideHttpClient() (con opciones para XSRF o JSONP) y provideHttpClientTesting(). Estas funciones ofrecen una forma más directa y eficiente de configurar el cliente HTTP en tus aplicaciones.

Y como siempre, el equipo de Angular ha pensado en todo. Al actualizar tu proyecto con ng update @angular/core, se te preguntará si quieres migrar automáticamente tus módulos HTTP a la nueva sintaxis.

Contenido alternativo para ng-content

<ng-content> es una característica poderosa en Angular, pero tiene una limitación: no puede tener contenido alternativo. ¡Este ya no es el caso en Angular v18!

Ahora podemos agregar algo de contenido dentro de la etiqueta <ng-content>, y este contenido se mostrará si no se proyecta ningún contenido en el componente.

Sólo necesitas poner el contenido alternativo dentro de la etiqueta ng-content:

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

@Component({
  standalone: true,
  selector: 'my-component',
  template: `
    <ng-content select="header"> Default header </ng-content>

    <ng-content> Default main content </ng-content>

    <ng-content select="footer"> Default footer </ng-content>
  `,
})
export class MyComponent {}

Como puedes ver, esta nueva característica te permite definir fácilmente un contenido alternativo dedicado para cada elemento ng-content en tu componente.

Entonces, considerando el siguiente ejemplo:

<my-component>
  <footer> New footer </footer>
</my-component>

El resultado será:

Default header

Default main content

<footer> New footer </footer>

Nota: antes de Angular v18, esto provocaría un error.

angular.dev - La nueva documentación oficial de Angular

El equipo de Angular ha anunciado que ahora angular.dev es el nuevo sitio web oficial de la documentación.

Angular v18 llega cargado de mejoras que hacen del desarrollo web una experiencia más fluida, eficiente y satisfactoria. Desde la optimización del rendimiento hasta la inclusión de nuevas funcionalidades, esta versión nos equipa con las herramientas necesarias para construir aplicaciones web de última generación. ¡No hay tiempo que perder, es hora de actualizar nuestros proyectos y sumergirnos en las posibilidades que nos ofrece Angular v18!

Muchas gracias por leerme, Espero que este recorrido por las novedades de Angular v18 te haya resultado útil.

Si te ha gustado el artículo, ¡compártelo en tus redes sociales!

Sígueme en Twitter/X ricardo_chl

Omitir un Interceptor de Angular usando Context para Http Interceptors

Ricardo Chavarria — Mon, 01 Nov 2021 16:21:18 +0000

Los interceptors en Angular llegaron desde la versión 4.3 y básicamente nos brindan un mecanismo para interceptar y/o mutar las solicitudes y respuestas http. Más detalles aquí.

Los interceptors en Angular interceptan todas las peticiones http por defecto, pero hay ocasiones en donde deseamos omitir un interceptor para algunas solicitudes.

Antes de la versión 12 de Angular era muy común hacer esto de alguna de las siguientes formas:

Agregar encabezados http en la solicitud http y luego evaluar ese encabezado en el interceptor.
Crear un nuevo httpClient para esa solicitud.
Administrar sus inyecciones de HttpClient con tokens.
Utilizar httpBackend y saltarse todos los interceptors.

HttpContext

Desde la versión 12 de Angular tenemos una mejor forma de hacer esto, la cual consiste en pasar metadatos a los interceptors http. Ya podemos olvidarnos de pasar encabezados personalizados a nuestros interceptors.

Un caso de uso común es indicarle al interpcetor que la solicitud http actual es anónima y no necesita un JWT (JSON WEB TOKEN).

Otro caso también podría ser indicarle al interceptor que una solicitud se puede almacenar en caché.

Nota: Recuerda que tenemos que tener la Angular v12 o superior en nuestro proyecto.

HttpContext: El contexto HTTP almacena valores arbitrarios definidos por el usuario y garantiza la seguridad de los tipos sin conocer realmente los tipos.

Context: Es mutable y se comparte entre solicitudes clonadas a menos que se especifique explícitamente.


//token.interpcetor.ts

//Declaramos un nuevo HttpContextToken

export const BYPASS_JW_TOKEN = new HttpContextToken(() => false);

export class TokenInterceptor implements HttpInterceptor {

  intercept(req: HttpRequest<any>, delegate: HttpHandler): Observable<HttpEvent<any>> {
//Aquí evaluamos el contexto y omitimos el interceptor.
    if (req.context.get(BYPASS_JW_TOKEN) === true) {
      return next.handle(request)
    }
    return this.addToken(request);
  }
}

// service

/*
Así se ve una solicitud en la cual se quiere omitir el JWT, 
debemos pasar un nuevo contexto con el HttpContextToken 
declarado anteriormente en el interceptor.
*/

this.httpClient.get('/api/fakeEndPoint', {
  context: new HttpContext().set(BYPASS_JW_TOKEN, true),
});

Más detalles:

El token pasado al contexto del http interceptor puede ser cualquier tipo de dato como ser booleano, número, cadena, objeto etc. -El token pasado al contexto no debe confundirse con el JWT el cual es requerido para algunas solicitudes http.
La declaración del HttpContextToken se puede realizar donde tenga más sentido, aunque lo común es declararlo en el interceptor que lo va a utilizar.

Muchas gracias por leer este post.

Sígueme en twitter ricardo_chl

Novedades de Angular v12

Ricardo Chavarria — Thu, 13 May 2021 18:53:22 +0000

El 12 de mayo del 2021, se lanzo el release de Angular v12.

En este post quiero compartir algunas de las novedades de esta versión.

Empecemos...

Migrando a Ivy por completo

La nueva evolución de Angular que llego con Ivy ahora se esta completando, el equipo se esta moviendo por completo a Ivy.

Al antiguo view engine de Angular ha quedado obsoleto y se eliminará en una versión futura.

Aunque view engine está obsoleto, existen algunas librerías que lo utilizan y que seguirán funcionando con Ivy. (No se requiere que los desarrolladores hagan algún cambio especifico para obtener este soporte), pero los autores de las librerías deben preocuparse por realizar la transición a Ivy.

ID de mensajes de i18n

Actualmente, hay varios formatos de identificación de mensajes que son legacy los cuales se utilizan en el sistema i18n. Con estos identificadores pueden surgir algunos problemas (con los espacios en blanco por ejemplo). Para resolver esos problemas el equipo de Angular esta migrando por completo a los nuevos ID de mensajes. El nuevo formato de identificación de mensajes es mucho más intuitivo.

Desde v11, los nuevos proyectos se configuran automáticamente para usar los nuevos ID de mensajes. aquí una guía para la migración de legacy ids al nuevo formato.

El futuro de Protactor

El equipo de Angular ha optado por no incluir Protactor en nuevos proyectos, y está brindando soluciones de terceros que son bastante populares como Cypress, esto para ayudar a que los desarrolladores tengan soluciones alternativas.

También el equipo ha estado en constante trabajo con la comunidad para escuchar sus comentarios sobre Protactor y en base a eso poder tomar una decisión en el futuro.

Más información aquí.

Operador null-coalescing (??)

El operador null-coalescing (??) ha permitido a los desarrolladores escribir un código mas limpio y práctico en TypeScript. Ahora con el release de Angular v12 tenemos soporte para utilizar este operador en las plantillas de los componentes.

Entonces, eso quiere decir que si tenemos una sintaxis como la siguiente:

{{impuesto !== null && impuesto !== undefined ? impuesto: calcularImpuesto()}}

Se convierte en lo siguiente:

{{impuesto ?? calcularImpuesto()}}

Mejoras en la documentación

Siempre hay mucha gente queriendo aprender Angular y no sabe por donde iniciar, el equipo de Angular ha identificado algunas oportunidades de mejora y ha realizado un gran esfuerzo por mejorar documentación oficial angular.io

Han escrito varias guías para los que vienen iniciando con el framework, esto está en un apartado llamado "Understanding Angular", si bien estas guías no son nuevas, el equipo ha estado en constante mejora de este contenido y agregando cada vez más, tal es el caso de la guía Content projection.

También se actualizo la guía para contribuciones.

Sass en línea

A partir de la v12, los componentes de Angular ahora admitirán Sass en línea en el campo styles del decorador @component.

Anteriormente, Sass solo estaba disponible en recursos externos debido al compilador Angular. Para activar esta función en las aplicaciones existentes tenemos que añadir "inlineStyleLanguage": "scss”a angular.json. De lo contrario, estará disponible para nuevos proyectos que utilicen SCSS.

Angular CDK y Angular Material

Angular CDK y Angular Material han adoptado internamente el nuevo sistema de módulos de Sass. Los desarrolladores deben asegurarse de cambiar el paquete "node-sass" al paquete "sass".

El node-sass ya no esta al día con la nuevas funciones de sass.

Ademas, ambos (Angular CDK y Angular Material) exponen una nueva API diseñada para se consumida con la nueva sintaxis @use.

Cuando se actualiza una aplicación a la v12, la app cambiara automáticamente a la nueva API de sass.

Visita la documentación oficial de Angular Material para obtener mas información.

Soporte de Webpack 5 en produción

En la v11 se agrego soporte experimental para Webpack 5, ahora con la v12 tenemos soporte de Webpack 5 para su uso en producción.

Modo producción y modo estricto por defecto, TypeScript 4.2

La ejecución ng build ahora tiene como valor predeterminado producción.

El modo estricto está habilitado de forma predeterminada en la CLI.

Angular v12 es compatible con TypeScript 4.2

Desactivación del soporte para IE11

El equipo esta enfocado en brindar soluciones modernas para el framework, eliminar el soporte de esta compatibilidad permite que se puedan enfocar en otras soluciones y brindar una mejor experiencias a los usuarios y desarrolladores.

Angular v12 incluye un nuevo mensaje de advertencia en navegadores IE11, este soporte de eliminará por completo en Angular v13.

Actualizar a la v12

Angular nos brinda un comando para actualizar nuestras aplicaciones de una manera sencilla el cual es ng update.

Si tenemos aplicaciones un poco mas complejas podemos seguir la guía para actualizar, la pueden encontrar aquí.

Conclusiones

Me alegra mucho que el equipo de Angular ahora este mas conectado con la comunidad, escuchando sus comentarios y trabajando en conjunto.

Angular v12 llego con muchas características importantes que sin duda nos ayudaran a mejorar nuestra experiencia como desarrolladores, y a su vez la de los usuarios.

Gracias por leer está publicación.

¿Cómo servir archivos estáticos en Express?

Ricardo Chavarria — Mon, 03 May 2021 04:02:51 +0000

En este pequeño articulo aprenderás como servir archivos estáticos en Express.

Express es framework de Node Js el cual nos permite crear API's y servicios web robustos de una manera más fácil.

Si tenemos nuestra API desarrollada con Express sera muy fácil agregarle la capacidad de que pueda manejar los archivos estáticos.

Llámese archivos estáticos a imágenes, videos, archivos de audio, documentos en distintos formatos, fuentes, archivos de JavaScript, html y css, etc.

Iniciemos

1. Configuración de Express

Primero vamos a crear un proyecto para de Node para este ejemplo, en este caso voy a inicializar todos los valores predeterminados utilizando la bandera "-y", esto configurará un archivo package.json para manejar las dependencias.

npm init -y

Ahora creamos un archivo de entrada con el nombre index.js, aquí es donde crearemos el servidor de Express.

Bien, ahora instalemos express como dependencia de nuestro proyecto

npm install express

En nuestro package.json agreguemos un comando que nos permitirá iniciar el servidor que crearemos en breve.

  "start": "node index.js"

El package.json deberá verse así

{
  "name": "express-static-files",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "node index.js"
  },
  "keywords": [],
  "author": "Ricardo Chavarria",
  "license": "ISC",
  "dependencies": {
    "express": "^4.17.1"
  }
}

2. Carpeta de archivos estáticos

Para almacenar los archivos estáticos, creemos una carpeta llamada "public" en la raíz de nuestro proyecto, y podemos agregar algunos archivos en mi caso colocare una imagen y un archivo html.

La estructura de archivos se vera así:

Creación del servidor con Express

En el index.js, vamos requerir express y hacemos una instancia del mismo, luego implementamos una solicitud get y finalmente levantamos nuestro servidor para que funcione en el puerto 3000.

const express = require('express');

const app = express();
const PORT = 3000;

app.get('/', (req, res) => {
    res.send('Hello World!');
});


app.listen(PORT, () =>
  console.log(`Server listening on port: ${PORT}`),
);

Ejecutamos "npm run start" en la terminal y veremos el siguiente mensaje.

Server listening on port: 3000

Y sí accedemos en nuestro navegador a http://localhost:3000/ debemos de ver el mensaje de 'Hello World!' que implementamos en la solicitud get.

Bien hecho, ya tenemos nuestro servidor de Express configurado correctamente, solo queda agregarle la capacidad a nuestro servidor de que pueda manejar archivos estáticos.

3. Sirviendo Archivos Estáticos

Utilizaremos el módulo path de Node Js, este modulo contiene todas las utilidades para trabajar con rutas de archivos. No necesitamos instalar nada, solo es necesario requerirlo en nuestro archivo index.js

const path = require('path');

Ahora sí, con la siguiente linea de código le decimos a express que pueda servir archivos estáticos.

app.use('/public', express.static(path.join(__dirname, 'public')))

Cuando usamos app.use(), le estamos diciendo a Express que use un Middleware, el Middleware básicamente es un bloque de código o función que se ejecuta entre la petición que hace el usuario hasta que la petición llega al servidor, funciona como una especie de proxy.

express.static() busca y devuelve los archivos estáticos solicitados por el usuario y recibe como parámetro la ruta del folder donde están esos archivos.

Utilizamos el modulo path para proporcionar una ruta absoluta de la carpeta, ya que se colocas la ruta directamente estarías proporcionando una ruta relativa y si ejecutas la aplicación desde otro directorio o similar puedes tener problemas, por ello se recomienda utilizar la ruta absoluta y módulo path nos ayuda con eso.

El index.js se veria así:

const express = require('express');
const path = require('path');

const app = express();
const PORT = 3000;

app.get('/', (req, res) => {
    res.send('Hello World!');
});


app.use('/public', express.static(path.join(__dirname, 'public')))

app.listen(PORT, () =>
  console.log(`Server listening on port: ${PORT}`),
);

4. Probando la aplicación

Creemos un archivo index.html en la carpeta public, agreguemos lo siguiente:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Archivos Estáticos</title>
</head>
<body>
    <h1>Sirviendo archivos estáticos en Express</h1>
</body>
</html>

Ahora ejecutemos

npm start

Vayamos a http://localhost:3000/public/

Deberíamos de ver lo siguiente:

También podemos servir imágenes

Con esto hemos finalizado.

El repositorio de este tutorial lo puedes encontrar aquí

Déjame saber en los comentarios que te pareció este tutorial.

Gracias por leer está publicación.

Login con Angular y Auth0

Ricardo Chavarria — Thu, 29 Apr 2021 19:45:27 +0000

Auth0 es una solución flexible e integrada para agregar servicios de autenticación y autorización a sus aplicaciones.

¿Por qué usar Auth0?

Como mencione anteriormente desarrollar un sistema de autenticación desde cero puede ser bastante complejo. Auth0 es una plataforma de identidad como servicio (IDaaS) que permite centralizar y autenticación y autorización aplicaciones y brindar un sistema de seguridad seguro para sus usuarios y de esta manera reduciendo la complejidad para la seguridad de sus aplicaciones.

Auth0 brinda funciones de seguridad listas para ser usada en sus apps, con Auth0 podrá integrar en sus app inicio de sesión con correo electrónico y contraseña e inicio de sesión social con terceros como (Google, Facebook, Github, etc)

Contenido

Crear Aplicación de Angular
Configurar Angular App en Auth0.com
Configuración del Auth0 Angular SDK
Autenticar usuario
Recuperar perfil del usuario
Proteger rutas
Conclusión

Iniciemos

1. Crear Aplicación de Angular

Lo primero que debemos hacer es crear la aplicación sobre la cual vamos a trabajar, ejecutamos el siguiente comando:

ng new angular-login-auth0 --routing --style=scss

Una vez creada la app accedemos al directorio

cd angular-login-auth0

2. Configurar Angular App en Auth0.com

Antes de iniciar a integrar el SDK de Auth0 para Angular, tenemos que crear una cuenta en auth0.com y registrar un aplicación de tipo SPA.

Vamos a ir a Auth0 puede ir a la opción de "Sign Up" y crear un cuenta , es super sencillo, también puede iniciar con acceso social con Google o Github.

Auth0 te solicitara la creación de un Auth0 Tenant que no es mas que un contenedor que utiliza Auth0 para para almacenar su configuración de servicio de identidad y sus usuarios de forma aislada.

Ningún otro usuario de Auth0 puede ver el tenant que haz creado ni tu puedes ver el de otros usuarios.

Una vez que ha configurado lo anterior, Auth0 lo lleva al panel de administración donde se podrán administrar y configurar todos los servicios de Auth0.

Crear Aplicación en Auth0

Tenemos que crear una aplicación en Auth0 la cual vamos a conectar con nuestra app de Angular que hemos creado previamente.

En el menu lateral izquierdo vamos, hacemos clic en la opción aplicaciones y luego en crear aplicación.

Para este ejemplo nombre la app como "Angular Login", se debe elegir la opción de Single Page Web Applications ya que estamos trabajando en una SPA con Angular.

Una vez crear la aplicación haga clic en la tab de settings aquí es donde esta toda la configuración de su aplicación especifica, incluyendo su ClientId y Client Secret.

Comunicación entre Angular y Auth0

Cuando se trabaja con Auth0, no es necesario que nosotros creemos un formulario de inicio de sesión, Auth0 ya ofrece una página de acceso universal. Este formulario reduce el riesgos a nivel de seguridad.

¿Cómo funciona el acceso universal?

Cuando un usuario intente iniciar sesión en la aplicación de Angular se redirigirá a Auth0 y les mostrar la página de inicio de sesión universal. Para que esa redirección se realice de forma segura, debe especificar en la configuración de la aplicación Auth0 las URL a las que Auth0 puede redirigir a los usuarios una vez que los autentica.

Primero configuremos a donde debe ser redirigido el usuario cuando haya iniciado sesión de manera correcta

En la opción "Allowed Callback URLs" colocamos lo siguiente:

http://localhost:4200

Luego hay que configurar también a dónde debe ser redirigido el usuario cuando haya cerrado la sesión de manera correcta.

En la opción "Allowed Logout URLs" colocamos lo siguiente:

http://localhost:4200

Auth0 solo podrá redirigir al usuario a las URL que haya colocado anteriormente como origenes permitidos.

Orígenes web permitidos

Cuando se utiliza el Auth0 Angular SDK, la aplicación de Angular realiza solicitudes bajo el capó a la API de Auth0, esto para manejar las solicitudes de autenticación, es por ello que debe agregar la URL de origen de su aplicación angular para evitar problemas de intercambio de recursos de origen cruzado (CORS).

http://localhost:4200

Para finalizar hacemos clic en "Guardar Cambios".

Variables de configuración

Para permitir que la Aplicación de Angular se comunique con Auth0 se necesitan los valores de ID de cliente y dominio Auth0. Estos valores están en la "pestaña" de settings

En su aplicación de Angular cree un archivo llamado auth_config.json (A nivel del proyecto)

Este archivo debe contener la siguiente información

{
  "domain": "YOUR_AUTH0_DOMAIN",
  "clientId": "YOUR_AUTH0_CLIENT_ID"
}

Estas variables permiten que su aplicación Angular se identifique como una parte autorizada para interactuar con el servidor de autenticación Auth0 para llevar a cabo el proceso de autenticación.

Ahora debemos usar estas variables en la aplicación Angular para eso vamos a utilizar el environment de Angular.

El environment debería verse así:

import { domain, clientId } from '../../auth_config.json';

export const environment = {
  production: false,
  auth: {
    domain,
    clientId,
    redirectUri: window.location.origin,
  },
};

Para poder importar archivos JSON dentro de Angular, tenemos que establecer "resolveJsonModule": true en nuestro tsconfig.json

Con estos pasos realizados se ha completado la configuración de un servicio de autenticación que esta listo para ser consumido por la aplicación de Angular

3. Configuración del Auth0 Angular SDK

Ejecute el siguiente comando:

ng add @auth0/auth0-angular

El nuevo Auth0 Angular SDK brinda varios métodos, variables y tipos que ayudan a integrar Auth0 con una aplicación de Angular de una manera más sencilla, este SDK incluye un módulo de autenticación y un servicio.

Implementar módulo de autenticación

Importar AuthModule y environment en el AppModule y luego inicializarlo en los imports.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';

import { AuthModule } from '@auth0/auth0-angular';
import { environment as env } from '../environments/environment';
import { HttpClientModule } from '@angular/common/http';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule,
    HttpClientModule,
    AuthModule.forRoot({
      ...env.auth,
    }),
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

4. Autenticar usuario

Auth0 Angular SDK proporciona métodos para activar eventos de autenticación dentro de los componentes Angular: inicio de sesión, cierre de sesión y registro etc.

Creando componentes

Vamos a necesitar algunos componentes de Angular para permitirle a usuario iniciar y cerrar la sesión

Pagina de inicio
Botón para iniciar sesión
Botón para cerrar la sesión
Component para manejar que Botón mostrar si el de inicio o cierre de sesión.

Con los siguientes comando los podemos crear

ng g c pages/home
ng g c components/login-button
ng g c components/logout-button
ng g c components/authentication-button

El component home únicamente lo utilizaremos para mostrar los botones según sea el caso

Nuestro archivo de rutas debería verse así:

import { HomeComponent } from './pages/home/home.component';
import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';

const routes: Routes = [
  {
    path:'',
    component: HomeComponent
  }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Ahora el login-button.component.ts

import { Component, OnInit } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-login-button',
  templateUrl: './login-button.component.html',
  styleUrls: ['./login-button.component.scss']
})
export class LoginButtonComponent implements OnInit {

  constructor(public auth: AuthService) {}


  ngOnInit(): void {
  }

  loginWithRedirect(): void {
    this.auth.loginWithRedirect();
  }

}

Y el html

<button (click)="loginWithRedirect()">
  Log in
</button>

Ahora seguimos con el botón para cerrar la sesión

logout-button.component.ts

import { DOCUMENT } from '@angular/common';
import { Component, Inject, OnInit } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-logout-button',
  templateUrl: './logout-button.component.html',
  styleUrls: ['./logout-button.component.scss']
})
export class LogoutButtonComponent implements OnInit {

  constructor(
    public auth: AuthService,
    @Inject(DOCUMENT) private doc: Document
  ) { }

  ngOnInit(): void {
  }

  logout(): void {
    this.auth.logout({ returnTo: this.doc.location.origin });
  }

}

Y el html

<button (click)="logout()">
  Log out
</button>

Se agrega la propiedad returnTo al objeto de configuración para especificar la URL a la que Auth0 debe redirigir a sus usuarios después de cerrar la sesión. En este momento, está trabajando localmente y las "URL de cierre de sesión permitidas" de su aplicación Auth0 apuntan a http://localhost:4200, estas url las configuramos previamente.

Sin embargo, si tuviera que implementar su aplicación Angular en producción , debe agregar la URL de cierre de sesión de producción a la lista "URL de cierre de sesión permitidas.

Otro punto importante es que los componentes de Angular no tiene acceso al objeto document, pero se puede inyectar con el @Inject(DOCUMENT)

Luego tenemos que envolver LoginButtonComponent y LogoutButtonComponent en un solo componente que tiene lógica para decidir qué botón renderizar dependiendo del estado de autenticación del usuario.

authentication-button.component.ts

import { Component, OnInit } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-authentication-button',
  templateUrl: './authentication-button.component.html',
  styleUrls: ['./authentication-button.component.scss']
})
export class AuthenticationButtonComponent implements OnInit {

  constructor(public auth: AuthService) {}

  ngOnInit(): void {
  }

}

Y su html

<app-login-button *ngIf="(auth.isAuthenticated$ | async) === false">
</app-login-button>

<app-logout-button *ngIf="auth.isAuthenticated$ | async">
</app-logout-button>

Auth0 expone un observable "isAuthenticated$" que emite un valor booleano. Cuando el usuario se ha autenticado el valor es true y cuando no es false.

Y por último debemos agregar el app-authentication-button a nuestro home-component

<app-authentication-button></app-authentication-button>

Si haz llegado hasta aquí tu implementación básica esta lista y ya puedes correr la aplicación de Angular y probarla.

ng serve

Cuando hagas clic en el botón "Log In" serás redirigido a la página de acceso universal de Auth0

La primera vez que inicies te solicitara que autorices la aplicación.

Si iniciaste sesión correctamente deberías de ver el botón de cierre de sesión.

Cuando termina de iniciar sesión y Auth0 lo redirige a su aplicación Angular, la interfaz de usuario tiene una pantalla en blanco parpadeando.

La interfaz de usuario parpadea porque su aplicación Angular está cargando sus servicios. Mientras se carga, Angular no sabe si Auth0 ya ha autenticado al usuario. Su aplicación conocerá el estado de autenticación del usuario después de que se cargue Auth0 Angular SDK.

Para arreglar eso vamos a validar la sesión en el AppComponent utilizando el observable "isLoading$" que provee el AuthService.

El app.component.ts quedaría así:

import { Component } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  title = 'angular-login-auth0';

  constructor(public auth: AuthService) {}
}

Y el html

<div *ngIf="auth.isLoading$ | async; else loaded">
  <p>Cargando...</p>
</div>


<ng-template #loaded>
  <router-outlet></router-outlet>
</ng-template>

Aquí seria adecuado implementar un componente de "carga" mientras se cargan los servicios.

5. Recuperar el perfil del usuario

Después de que el usuario inicia sesión correctamente, Auth0 envía un token de identificación a su aplicación Angular.

Auth0 utiliza tokens de identificación en la autenticación basada en token para almacenar en caché la información del perfil de usuario y proporcionarla a una aplicación cliente.

Puede utilizar los datos del token de ID para personalizar la interfaz de usuario de su aplicación de Angular. El Auth0 Angular SDK decodifica el token de ID y emite sus datos a través del Observable. Parte de la información del token de ID incluye el nombre, el nickname, la imagen y el correo electrónico del usuario que inició sesión.

Creemos un componente para el perfil

ng g c pages/profile

El profile.component.ts quedaría de la siguiente manera

 import { Component, OnInit } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-profile',
  templateUrl: './profile.component.html',
  styleUrls: ['./profile.component.scss']
})
export class ProfileComponent implements OnInit {

  public profileJson: string = "";
  constructor(public auth: AuthService) {

  }

  ngOnInit(): void {
    this.auth.user$
    .subscribe((profile) => {
      this.profileJson = JSON.stringify(profile, null, 2)
    });
  }

}

Y en el html

<pre>{{profileJson}}</pre>

Y ahora agregamos una nueva ruta en el app-routing.module.ts

import { ProfileComponent } from './pages/profile/profile.component';
import { HomeComponent } from './pages/home/home.component';
import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';

const routes: Routes = [
  {
    path:'',
    component: HomeComponent
  },
  {
    path:'profile',
    component: ProfileComponent
  }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Cuando naveguemos a la ruta http://localhost:4200/profile
podremos ver la información del usuario.

6. Protección de rutas

Auth0 Angular SDK expone un AuthGuard que puede usar para proteger rutas.

Para requerir que el usuario inicie sesión es tan fácil como agregar la propiedad canActivate a la ruta que queremos proteger y agregar el AuthGuard

Importemos el AuthGuard en el app-routing.module.ts

import { ProfileComponent } from './pages/profile/profile.component';
import { HomeComponent } from './pages/home/home.component';
import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { AuthGuard } from '@auth0/auth0-angular';

const routes: Routes = [
  {
    path:'',
    component: HomeComponent
  },
  {
    path:'profile',
    component: ProfileComponent,
    canActivate: [AuthGuard],
  }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Extra

Si fue curioso pudo notar que cuando ha iniciado sesión con acceso social (Google) y refresca la página la sesión se pierde esto se debe a que las claves de desarrollador Auth0 se están utilizando en lugar de sus propias credenciales para una conexión social.

En la sección de conexiones sociales del panel de Auth0 podrá configurar sus propias credenciales para resolver este problema. Las claves de desarrollo de Auth0 están diseñadas para pruebas y no se recomiendan para entornos de producción.

Otra solución es usar Refresh Token Rotation y establecer cacheLocation"localstorage" al inicializar el Auth0 Angular SDK.

    AuthModule.forRoot({
      ...env.auth,
      cacheLocation:'localstorage'
    })

El repositorio con el código de este tutorial lo podrá encontrar aquí

7. Conclusión

Hemos implementado la autenticación de usuario en Angular, obtener la información del usuario que inicio sesión y también controlar a que rutas pueden acceder los usuarios.

Auth0 es una poderosa solución que nos permite agregar los servicios de Autenticación a nuestras aplicaciones de una manera sencilla haciendo la mayor parte del trabajo por nosotros.

Déjame saber en los comentarios que te pareció este tutorial.

Gracias por leer está publicación.

Como usar HttpInterceptors en Angular

Ricardo Chavarria — Wed, 28 Apr 2021 23:02:11 +0000

Los interceptors en Angular nos brindan un mecanismo para interceptar y/o mutar las solicitudes y respuestas http. No debe confundirse con los Guards. Los interceptors modifican las peticiones del http module.

Aunque los interceptors son capaces de mutar solicitudes y respuestas, las propiedades HttpRequest y las HttpResponse son read-only, lo que las hace inmutables.

Disponible desde la versión 4.3 de Angular.

Los interceptors son capaces de intervenir las solicitudes de entrada y de salida, es decir lo que sale de tu app al servidor y lo que llega del servidor a tu app.

Múltiples Interceptores

Angular aplica los interceptors en el orden en que los proporcionas. Si proporciona los interceptors A, luego B y luego C, las solicitudes fluirán en A-> B-> C y las respuestas fluirán hacia fuera C-> B-> A.

Implementación

Para implementar un interceptor se necesita una clase inyectable que implemente “HttpInterceptor”. La clase debe definir un método “intercep”, el cual toma dos argumentos, req y next, y devuelve un observable de tipo HttpEvent.

import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpHandler, HttpRequest, HttpEvent }
  from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable()
export class MyInterceptor implements HttpInterceptor {
    intercept(req : HttpRequest<any>, next : HttpHandler) : Observable<HttpEvent<any>> {
      const httpReq = req.clone({
        url: req.url.replace("http://", "https://")
      });
      return next.handle(httpReq);
    }
}

Los interceptors se ejecutan en cada petición que se realiza al servidor, para eso deben estar registrados. Para registrar un interceptor se tiene que proveer en el array de providers: [] en nuestro módulo raíz, por lo general AppModule.

Debemos importar HTTP_INTERCEPTORS y HttpClientModule, quedaría así:

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { HTTP_INTERCEPTORS, HttpClientModule } from '@angular/common/http';
import { AppComponent } from './app.component';
import { MyInterceptor } from './interceptors/my.interceptor';

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule,
    HttpClientModule,
  ],
  providers: [
    { provide: HTTP_INTERCEPTORS, useClass: MyInterceptor, multi: true },
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

La mayoría de los interceptors transforman la solicitud saliente antes de pasarla al siguiente interceptor de la cadena, llamando next.handle(transformedReq). Un interceptor también puede transformar el flujo de eventos de respuesta, aplicando operadores RxJS adicionales en el flujo devuelto por next.handle().

El método "intercept" intercepta y maneja un HttpRequest ó HttpResponse.

HttpRequest: Una solicitud HTTP saliente con un cuerpo con tipo opcional.

HttpResponse: Es un HttpEvent disponible en la secuencia de eventos de respuesta.

HttpHandler

Transforma una HttpRequest en una secuencia de HttpEvents, una de las cuales probablemente sea HttpResponse.

La instancia del controlador envía las solicitudes al primer interceptor de la cadena, que envía a la segunda, etc., y finalmente llega al HttpBackend.

HttpBackend: Es un HttpHandler final que enviará la solicitud a través de las API HTTP del navegador a un backend.

HttpEvent: Es un tipo de unión para todos los eventos posibles en el flujo de respuesta.

HTTP_INTERCEPTORS: Representa la matriz de HttpInterceptors que están registrados.

Ejemplos de uso

Autenticación
Añadir cabeceras extras a las peticiones.
Almacenar un log de las peticiones realizadas por la aplicación.
Loading Centralizado.
Manejador de Errores.
Notificaciones
Debug de las respuestas recibidas. etc...

Puedes encontrar mas ejemplos en este repositorio

DEV Community: Ricardo Chavarria

Harness Engineering: el modelo casi nunca es el problema

Los números que motivaron todo esto

Qué es, en realidad, un harness

El repositorio es la única memoria que cuenta

Por qué "una cosa a la vez" no es solo buena práctica, es matemática de contexto

Las listas de tareas como estructura de datos, no como nota

El punto más difícil: declarar éxito sin haberlo verificado

Por qué "pasan los tests unitarios" no es lo mismo que "funciona"

El código que queda no es lo mismo que el porqué que se pierde

Un dato menos citado: por qué el sistema necesita poder explicarse

Cerrar bien también es parte del trabajo

El modelo y la herramienta no son lo mismo que el harness

La conclusión práctica

Fuentes

Adiós Karma, Hola Vitest: El Futuro del Testing en Angular

El Adiós a un Clásico: ¿Qué Pasó con Karma?

Vitest: Testing Moderno para el Ecosistema Web

Beneficios clave de Vitest

Configurando Vitest en un proyecto Angular (v20+)

Consideraciones y Limitaciones Actuales

Conclusión

Angular 20 y el futuro sin Zone.js: La revolución "Zoneless" ha llegado (a Developer Preview)

El "Problema" Silencioso: ¿Qué es Zone.js y por qué queremos dejarlo atrás?

La Solución Elegante: ¡Hola, Detección de Cambios "Zoneless"!

Aclaración Crucial: ¿Necesito "Zoneless" para usar Signals?

Manos a la Obra: ¿Cómo Funciona en la Práctica?

Antes: Con Zone.js y Propiedades de Clase

Ahora: El Futuro "Zoneless" con Signals

Beneficios Clave (y Potenciales) de la Arquitectura Zoneless

Resource API en Angular: La revolución declarativa de los datos asincrónicos

Reactividad Declarativa con resource(), rxResource() y httpResource() en Angular

Introducción: Un nuevo paradigma en la reactividad de Angular

resource(): Reactividad declarativa con Promesas

Uso básico de resource()

Acceso a estados reactivos

rxResource(): Flujos RxJS reactivos en el mundo de Signals

Ejemplo práctico con HttpClient

Ventajas de rxResource()

httpResource(): Declaración más simple para operaciones HTTP

Características clave

Comparación de las tres APIs

Casos de uso reales

Búsquedas reactivas

Paginación

Formularios y edición

Ventajas frente a enfoques tradicionales

Conclusión

Angular se reinventa: Bienvenido a la era de Angular v18

Change detection - Zoneless (Experimental)

Experimentando con zoneless

Async/await nativo en aplicaciones zoneless

Signals - Propuesta de Estandarización

Built-in control flow - Ahora es estable

Deferrable views - Ahora es estable

Material v3 - Ahora es estable

Mejoreas en el server-side rendering

Repetición de eventos

Ejemplo:

Experiencia de depuración mejorada

Soporte para Hidratación en CDK y Material

Hidratación parcial

Firebase App Hosting

Nuevo paquete de construcción

Redirecciones de ruta como funciones

HttpClientModule - Depreación

Contenido alternativo para ng-content

angular.dev - La nueva documentación oficial de Angular

Omitir un Interceptor de Angular usando Context para Http Interceptors

HttpContext

Novedades de Angular v12

Migrando a Ivy por completo

ID de mensajes de i18n

El futuro de Protactor

Operador null-coalescing (??)

Mejoras en la documentación

Sass en línea

Angular CDK y Angular Material

Soporte de Webpack 5 en produción

Modo producción y modo estricto por defecto, TypeScript 4.2

Reactividad Declarativa con `resource()`, `rxResource()` y `httpResource()` en Angular

`resource()`: Reactividad declarativa con Promesas

Uso básico de `resource()`

`rxResource()`: Flujos RxJS reactivos en el mundo de Signals

Ejemplo práctico con `HttpClient`

Ventajas de `rxResource()`

`httpResource()`: Declaración más simple para operaciones HTTP