Aprende sobre el nuevo Authoring Format en Angular y Signals

Introducción

El término Nuevo Authoring Format (Signal Components) aparece cada vez más en las discusiones oficiales de Angular. En las primeras líneas: el Nuevo Authoring Format (Signal Components) propone cambiar cómo se escriben los componentes, pasando de clases y decoradores a formatos más funcionales—ya sea funciones con Signals o Single File Components tipo Vue/Svelte. Esto no es un capricho sintáctico: tiene consecuencias profundas en compilador, tooling y arquitectura de aplicaciones.

Resumen rápido (lectores con prisa)

Qué es: Un nuevo formato de autoría para componentes de Angular que prioriza la reactividad nativa (Signals) y alternativas sintácticas funcionales o SFC.

Cuándo usarlo: Es una dirección en discusión; hoy, adopta Standalone Components y Signals para prepararte.

Por qué importa: Afecta inferencia de tipos, tooling, rendimiento y compatibilidad con Web Components.

Cómo funciona (alto nivel): Componentes como funciones crean Signals y devuelven representación; SFC agrupa lógica y template en un archivo.

Nuevo Authoring Format (Signal Components): qué está en juego

Angular lleva años evolucionando: Signals, Zoneless y Standalone Components han sido el preludio. El siguiente paso es replantear la autoría de componentes para que la reactividad sea nativa en la sintaxis, no un patrón insertado dentro de clases. El equipo mantiene discusiones públicas (ver RFCs y hilos) y la dirección es clara aunque no definitiva.

¿Por qué importa? Porque cambiar la forma de autoría impacta en:

• Inferencia de tipos y Language Service.
• Minificación, tree-shaking y rendimiento del bundle.
• Ergonomía del desarrollador (DX) y curva de aprendizaje.
• Compatibilidad con Web Components y herramientas del ecosistema.

Referencias útiles:

• Signals
• Standalone Components
• Angular discussions (RFCs)
• Angular Elements / Web Components
• Web Components (MDN)

Dos enfoques en discusión

El equipo de Angular evalúa principalmente dos caminos. Ninguno está finalizado; pueden mezclarse o descartar ambos.

Funciones con Signals

• El componente es una función que crea Signals y devuelve la representación (o templates vinculados).
• Elimina el contexto this, favorece closures y composición.
• Ejemplo conceptual:

export const UserCard = component(() => {
  const name = signal('Ada');
  const greeting = computed(() => `Hola, ${name()}`);
  return html`<p>${greeting()}</p>`;
});

Beneficios: compresión mejor por bundlers, composición natural, menos errores por binding de contexto.

Single File Components (SFC)

• Un archivo con bloques <script> y <template> (estilo .vue/.svelte).
• Separación visual lógica/template sin el decorador @Component.
• Mejora la legibilidad y facilita la adopción por desarrolladores nuevos.
• Ejemplo conceptual:

<script>
  const count = signal(0);
  const double = computed(() => count() * 2);
</script>

<template>
  <button (click)="count.set(count() + 1)">{{ double() }}</button>
</template>

Beneficios: DX clara, flujo secuencial, herramientas de análisis más directas.

Impactos técnicos que debes considerar

Language Service y tooling

• Sin decoradores opacos, el Language Service puede ofrecer autocompletado y detección de errores más precisos en templates.
• Requiere cambios en el análisis estático y en la forma en que el compilador Ivy mapea lógica y vista.

Ciclos de vida y hooks

• ngOnInit y ngOnDestroy podrían migrar a hooks funcionales reutilizables (p. ej. onMount, onDestroy), que facilitan testing y composición.

Compatibilidad con Web Components

• Web Components exigen kebab-case en nombres (p. ej. my-element). Un formato sin selector obliga a definir reglas para exportación como custom elements o mecanismos automáticos de derivación de selectores.

Retrocompatibilidad

• Angular tenderá a mantener convivencia entre modelos: las clases seguirán funcionando durante varias versiones, y la migración se hará mediante schematics y herramientas.

Qué hacer hoy (criterio práctico para Tech Leads)

No bloquees desarrollo ni intentes replicar experimentalmente la sintaxis en producción. Haz esto en su lugar:

1. Migra a Standalone Components. Es el requisito técnico más claro para cualquier nuevo formato.
2. Adopta Signals en tus componentes actuales: signal, computed, effect. Esto reduce la brecha conceptual entre hoy y el nuevo formato.
3. Extrae lógica de negocio a funciones puras o servicios. Mantén la presentación lo más delgada posible. Así la migración será principalmente sintáctica.
4. Mejora la cobertura de tests (unit + E2E) en formularios y flujos críticos; los cambios en autoría pueden exponer fricciones en bindings y hooks.
5. Establece convenciones de naming y scripts de codemods para renombrados masivos: facilita que un futuro schematic haga el trabajo fino.

Conclusión

El Nuevo Authoring Format (Signal Components) no es solo una reforma estética: es la pieza que permite a Angular consolidar Signals como primer ciudadano del framework. La opción final (funciones vs SFC) aún no está cerrada, pero la dirección estratégica es evidente: menos decoradores, mejor inferencia, DX más directa y componentes concebidos para la reactividad desde el primer token.

Prepara tu base de código: adopta Standalone Components, usa Signals y desacopla la lógica. Cuando Angular estabilice la sintaxis, no querrás estar rehaciendo arquitectura; querrás ejecutar schematics y seguir adelante.