{"id":1324,"date":"2026-03-29T09:57:59","date_gmt":"2026-03-29T12:57:59","guid":{"rendered":"https:\/\/maurobernal.com.ar\/blog\/?p=1324"},"modified":"2026-03-29T09:57:59","modified_gmt":"2026-03-29T12:57:59","slug":"angular-signals-en-el-mundo-real-inputs-reactivos-y-routing-inteligente","status":"publish","type":"post","link":"https:\/\/maurobernal.com.ar\/blog\/angular-signals-en-el-mundo-real-inputs-reactivos-y-routing-inteligente\/","title":{"rendered":"Angular Signals en el Mundo Real: Inputs Reactivos y Routing Inteligente"},"content":{"rendered":"\n

Angular Signals lleg\u00f3 para transformar la forma en que construimos aplicaciones reactivas. En este art\u00edculo exploramos escenarios del mundo real donde los Signals cambian radicalmente el dise\u00f1o de tus componentes Angular: desde inputs reactivos hasta routing con par\u00e1metros de ruta y llamadas a APIs declarativas con httpResource()<\/code>.<\/p>\n\n\n\n

El problema con ngOnChanges: el viejo paradigma imperativo<\/h2>\n\n\n\n

Durante a\u00f1os, reaccionar a cambios en los inputs de un componente implicaba escribir c\u00f3digo verboso y fr\u00e1gil usando ngOnChanges<\/code>. Por cada nuevo @Input()<\/code>, la complejidad crec\u00eda de forma no lineal, con l\u00f3gica condicional duplicada y errores dif\u00edciles de detectar.<\/p>\n\n\n\n

\/\/ Enfoque tradicional con ngOnChanges\n@Component({ selector: 'legacy-config-panel', template: '...' })\nexport class LegacyConfigPanel implements OnChanges {\n  @Input() userRole!: string;\n  @Input() theme!: 'light' | 'dark';\n\n  isAdminView = false;\n  isDarkMode = false;\n\n  ngOnChanges(changes: SimpleChanges): void {\n    if (changes['userRole']) this.isAdminView = this.userRole === 'admin';\n    if (changes['theme']) this.isDarkMode = this.theme === 'dark';\n  }\n}<\/code><\/pre>\n\n\n\n
Angular Signals: dise\u00f1o declarativo con input() y computed()<\/h2>\n\n\n\n
Con Angular Signals, cada pieza de estado derivado se expresa como una funci\u00f3n de sus inputs. No m\u00e1s ngOnChanges<\/code>, no m\u00e1s boilerplate. Angular garantiza que cuando un input signal cambia, los valores computed()<\/code> se actualizan autom\u00e1ticamente.<\/p>\n\n\n\n
@Component({ selector: 'config-panel', template: '...' })\nexport class ConfigPanel {\n  userRole = input<string>();\n  theme = input<'light' | 'dark'>();\n  region = input<string>();\n  featureFlags = input<string[]>();\n\n  readonly isAdminView = computed(() => this.userRole() === 'admin');\n  readonly isDarkMode = computed(() => this.theme() === 'dark');\n  readonly showLegalBanner = computed(() =>\n    this.region() === 'EU' &&\n    this.userRole() !== 'admin' &&\n    !this.featureFlags()?.includes('suppress-legal')\n  );\n}<\/code><\/pre>\n\n\n\n
Este enfoque establece un nuevo contrato entre componentes: los inputs son valores vivos, el estado derivado es expl\u00edcito y las actualizaciones son autom\u00e1ticas.<\/p>\n\n\n\n
Queries Reactivas: viewChild() y contentChild()<\/h2>\n\n\n\n
Los decoradores @ViewChild<\/code> y @ContentChild<\/code> tradicionales eran lookups est\u00e1ticos atados al ciclo de vida del componente. Con Signal-based queries, obtenemos una Signal<T | undefined><\/code> verdaderamente reactiva.<\/p>\n\n\n\n
\/\/ Antes: dependiente del ciclo de vida\n@ViewChild(CustomCardHeader) header!: CustomCardHeader;\nngAfterViewInit() {\n  if (this.header) this.header.setFocus();\n}\n\n\/\/ Ahora: completamente reactivo\nheader = viewChild(CustomCardHeader);\nreadonly hasHeader = computed(() => !!this.header());\n\neffect(() => {\n  if (this.header()) this.header()!.setFocus();\n});<\/code><\/pre>\n\n\n\n
El c\u00f3digo dentro de effect()<\/code> se re-ejecuta autom\u00e1ticamente cuando el componente entra o sale del DOM, sin necesidad de gestionar ngAfterViewInit<\/code> ni ExpressionChangedAfterItHasBeenChecked<\/code>.<\/p>\n\n\n\n
Two-Way Binding Moderno: la API model()<\/h2>\n\n\n\n
La nueva API model()<\/code> simplifica radicalmente el two-way binding. En lugar de coordinar manualmente un @Input()<\/code> con su correspondiente @Output()<\/code>, basta con declarar un WritableSignal<\/code> con model()<\/code>.<\/p>\n\n\n\n
\/\/ Antes\n@Input() value = 0;\n@Output() valueChange = new EventEmitter<number>();\nincrement() { this.valueChange.emit(this.value + 10); }\n\n\/\/ Ahora con model()\nexport class CustomSlider {\n  value = model(0);\n  increment() { this.value.update(old => old + 10); }\n}\n\n\/\/ En el componente padre\n<custom-slider [(value)]=\"volume\" \/><\/code><\/pre>\n\n\n\n
Nota importante:<\/strong> model()<\/code> no reemplaza ControlValueAccessor<\/code> todav\u00eda. CVA sigue siendo necesario para integraci\u00f3n con FormControl<\/code> y formControlName<\/code>. Sin embargo, muchos casos de uso que antes requer\u00edan CVA ahora pueden resolverse con model()<\/code>.<\/p>\n\n\n\n
Par\u00e1metros de Ruta como Signals con withComponentInputBinding()<\/h2>\n\n\n\n
Con withComponentInputBinding()<\/code>, los par\u00e1metros de ruta se mapean directamente a inputs del componente como signals. Adi\u00f3s a ActivatedRoute<\/code>, adi\u00f3s a subscripciones manuales.<\/p>\n\n\n\n
\/\/ app.config.ts\nexport const appConfig: ApplicationConfig = {\n  providers: [\n    provideRouter(routes, withComponentInputBinding()),\n  ],\n};\n\n\/\/ project-details.component.ts\nexport class ProjectDetailsComponent {\n  \/\/ Angular mapea ':projectId' autom\u00e1ticamente como Signal\n  projectId = input<string>();\n}<\/code><\/pre>\n\n\n\n
Carga de Datos Reactiva con httpResource()<\/h2>\n\n\n\n
La API experimental httpResource()<\/code> es quiz\u00e1s el caso de uso m\u00e1s poderoso: conectar directamente un Signal de par\u00e1metro de ruta con una llamada HTTP, obteniendo tres signals listos para usar: data<\/code>, loading<\/code> y error<\/code>.<\/p>\n\n\n\n
@Component({\n  standalone: true,\n  template: \n    @if (loading()) { <p>Cargando\u2026<\/p> }\n    @if (error()) { <p>Error: {{ error() }}<\/p> }\n    @if (data(); as project) {\n      <h1>{{ project.name }}<\/h1>\n      <p>{{ project.description }}<\/p>\n    }\n  \n})\nexport class ProjectDetailsComponent {\n  projectId = input.required<string>();\n\n  resource = httpResource(() => \/api\/projects\/);\n\n  data = this.resource.data;\n  loading = this.resource.loading;\n  error = this.resource.error;\n}<\/code><\/pre>\n\n\n\n
Cuando projectId()<\/code> cambia (por ejemplo, al navegar entre proyectos), httpResource()<\/code> lanza autom\u00e1ticamente una nueva petici\u00f3n HTTP. Todo el flujo \u2014 desde el par\u00e1metro de ruta hasta la respuesta del servidor \u2014 es reactivo y declarativo.<\/p>\n\n\n\n
Conclusi\u00f3n: El futuro de Angular es reactivo y declarativo<\/h2>\n\n\n\n
Angular Signals no es solo una nueva sintaxis \u2014 es una nueva forma de pensar el dise\u00f1o de componentes:<\/p>\n\n\n\n