Preguntas de entrevista Angular 19: Signals, SSR y conceptos imprescindibles

Las entrevistas de Angular en 2026 van mucho más allá de los componentes y servicios. Angular 19, lanzado en noviembre de 2024, introdujo cambios arquitectónicos fundamentales: Signals estables, SSR con hidratación incremental y detección de cambios sin Zone.js. Dominar estos conceptos separa a los candidatos de nivel medio de los seniors.

Angular 19 Signals: el nuevo modelo de reactividad

Los Signals representan el cambio más profundo en Angular desde la introducción de la detección de cambios. Un Signal es un valor reactivo síncrono que notifica automáticamente a sus consumidores cuando cambia.

Pregunta típica: "¿Cuál es la diferencia entre un Signal y un Observable de RxJS?"

La respuesta esperada distingue claramente ambos modelos:

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

// Signal: synchronous, value always available
const count = signal(0);
const doubled = computed(() => count() * 2); // Recomputed only when count changes

// Effect: reacts to signal changes
effect(() => {
  console.log(`Count: ${count()}, Doubled: ${doubled()}`);
});

count.set(5); // Immediate, synchronous notification

Los Signals usan un grafo de dependencias granular. A diferencia de RxJS, que gestiona flujos asíncronos complejos (retry, debounce, merge), los Signals optimizan la reactividad síncrona de la UI. Angular 19 recomienda Signals para el estado de los componentes y RxJS para los flujos asíncronos (peticiones HTTP, WebSockets).

Signal Inputs y Queries: migrar desde @Input()

Angular 19 estabiliza las APIs basadas en signals para inputs, outputs y queries. Esta pregunta aparece de forma constante en las entrevistas.

Pregunta típica: "¿Cómo migrar un @Input() clásico a un Signal Input?"

import { Component, input, computed } from '@angular/core';

@Component({
  selector: 'app-user-card',
  template: `
    <div class="card">
      <h3>{{ fullName() }}</h3>
      <span>{{ role() }}</span>
    </div>
  `
})
export class UserCardComponent {
  // Signal inputs: strict typing, optional default value
  firstName = input.required<string>();
  lastName = input.required<string>();
  role = input<string>('developer'); // Default value

  // Computed derived from inputs: automatically recomputed
  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
}

La ventaja clave: los Signal Inputs permiten crear valores computed() directamente, sin hooks de ciclo de vida. Ya no se necesita ngOnChanges para reaccionar a cambios en los inputs. Angular ofrece el schematic signal-input-migration para automatizar la migración.

linkedSignal: sincronizar estado dependiente

linkedSignal es una API experimental de Angular 19 que crea un signal escribible vinculado a una fuente. Este concepto aparece con frecuencia en entrevistas de nivel senior.

Pregunta típica: "¿Cómo manejar un estado derivado mutable con linkedSignal?"

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

// Category list that can change
const categories = signal(['frontend', 'backend', 'devops']);

// Linked selection: resets when categories change
const selectedCategory = linkedSignal({
  source: categories,
  computation: (cats) => cats[0] // Reset to first element
});

// Manual modification still possible
selectedCategory.set('backend');

// When categories changes, selectedCategory resets automatically
categories.set(['mobile', 'data', 'cloud']);
// selectedCategory() === 'mobile'

Caso de uso concreto: un dropdown de filtro cuya selección se reinicia cuando cambia la lista fuente. Sin linkedSignal, este patrón requería un effect() con set(), un antipatrón que genera bucles de actualización.

Resource API: cargar datos asíncronos con Signals

Angular 19 introduce la API experimental resource para la carga de datos asíncronos. Esta API reemplaza el patrón clásico de servicio + subscribe en los componentes.

import { resource, signal } from '@angular/core';
import { inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

const userId = signal(42);
const http = inject(HttpClient);

// Resource: links a source signal to an async loader
const userResource = resource({
  request: () => ({ id: userId() }),  // Recomputed when userId changes
  loader: async ({ request }) => {
    const response = await fetch(`/api/users/${request.id}`);
    return response.json();
  }
});

// Access in template
// userResource.value()   -> data (or undefined)
// userResource.isLoading() -> boolean
// userResource.error()    -> error if any

Demostrar conocimiento de resource frente a rxResource (versión RxJS) en una entrevista evidencia una vigilancia tecnológica activa. rxResource usa Observables como loaders, útil para equipos con un código RxJS existente.

SSR e hidratación incremental en Angular 19

Angular 19 lleva el SSR al siguiente nivel con la hidratación incremental en developer preview. Esta funcionalidad, probada a escala Google Search, es un tema cada vez más frecuente en entrevistas.

Pregunta típica: "¿Cómo funciona la hidratación incremental de Angular 19?"

La hidratación clásica recrea todo el árbol de componentes en el cliente tras el renderizado en el servidor. La hidratación incremental hidrata solo los componentes necesarios, en el momento en que se vuelven visibles o interactivos.

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

@Component({
  template: `
    <app-header />
    <app-product-details [id]="productId" />

    <!-- Hydrated only when visible in viewport -->
    @defer (on viewport) {
      <app-reviews [productId]="productId" />
    }

    <!-- Hydrated only on user interaction -->
    @defer (on interaction) {
      <app-comment-form />
    }
  `
})
export class ProductPageComponent {
  productId = 'angular-19-guide';
}

La directiva @defer controla con precisión el momento de la hidratación. Triggers disponibles: on viewport (visible), on interaction (clic, focus), on idle (navegador inactivo), on timer(5s) (retraso). El contenido permanece visible como HTML estático antes de la hidratación, sin parpadeo.

Render mode por ruta: SSR granular por ruta

Angular 19 introduce el render mode a nivel de ruta, que permite la coexistencia de SSR, SSG y CSR dentro de la misma aplicación.

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  // Marketing pages: pre-rendered at build time (SSG)
  { path: '', renderMode: RenderMode.Prerender },
  { path: 'pricing', renderMode: RenderMode.Prerender },

  // Dashboard: server-rendered on each request (SSR)
  { path: 'dashboard/**', renderMode: RenderMode.Server },

  // Interactive editor: client-side only (CSR)
  { path: 'editor/**', renderMode: RenderMode.Client },
];

En entrevistas, la capacidad de justificar la elección del render mode por ruta demuestra comprensión de los trade-offs entre rendimiento, SEO e interactividad. Las páginas estáticas (landing, blog) se benefician del prerender. Las páginas dinámicas con datos de usuario usan SSR. Las aplicaciones muy interactivas se mantienen en CSR.

Detección de cambios sin Zone: arquitectura sin Zone.js

La detección de cambios sin Zone.js es la evolución arquitectónica más significativa de Angular 19. Esta pregunta se ha vuelto obligatoria en entrevistas senior.

Pregunta típica: "¿Cómo funciona la detección de cambios sin Zone.js?"

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

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

Sin Zone.js, Angular ya no parchea las APIs asíncronas del navegador (setTimeout, Promise, addEventListener). La detección de cambios se activa exclusivamente mediante Signals. Beneficios medibles:

• Reducción del tamaño del bundle de 10-15 KB (zone.js eliminado)
• Stack traces limpios sin frames de Zone.js
• Detección de cambios dirigida: solo los componentes afectados por un Signal modificado se re-renderizan

Standalone por defecto: el fin de los NgModules

Angular 19 convierte los componentes standalone en el comportamiento por defecto. Ya no es necesaria la flag standalone: true. Esta decisión simplifica la arquitectura y reduce el boilerplate.

Pregunta típica: "¿Qué impacto tiene standalone-by-default en la arquitectura de una aplicación Angular?"

@Component({
  selector: 'app-dashboard',
  imports: [CommonModule, RouterModule, UserCardComponent],
  template: `
    <nav>
      <a routerLink="/home">Home</a>
    </nav>
    @for (user of users(); track user.id) {
      <app-user-card [firstName]="user.firstName" [lastName]="user.lastName" />
    }
  `
})
export class DashboardComponent {
  users = signal<User[]>([]);
}

Cada componente declara explícitamente sus dependencias mediante imports. Los NgModules siguen disponibles por compatibilidad, pero las nuevas aplicaciones Angular 19+ ya no los necesitan. En entrevistas, explicar una migración incremental (componente por componente) en lugar de un enfoque big bang está bien valorado.

Estrategias de respuesta para entrevistas de Angular 19

Los entrevistadores técnicos evalúan tres dimensiones sobre Angular 19:

• Comprensión arquitectónica: explicar por qué los Signals reemplazan progresivamente a Zone.js, no solo cómo se usan
• Trade-offs: saber cuándo usar computed() frente a linkedSignal frente a effect(), y cuándo conservar RxJS
• Migración: describir una estrategia de migración incremental desde una aplicación Angular clásica hacia Signals y modo zoneless

La clave: evitar recitar la documentación oficial de Angular. Cada respuesta debe ilustrarse con un caso de uso concreto extraído de un proyecto real, un formulario complejo, una página de e-commerce con SSR, un dashboard en tiempo real.

Para los conceptos fundamentales de Angular antes de la entrevista, consulta la guía completa de las 25 preguntas de entrevista Angular.

Conclusión

• Los Signals de Angular 19 reemplazan los patrones @Input() + ngOnChanges por un modelo reactivo síncrono granular. signal(), computed() e input() cubren el 90% de los casos de uso
• linkedSignal resuelve el estado derivado mutable sin recurrir al antipatrón effect() + set()
• La hidratación incremental mediante @defer reduce el Time to Interactive sin sacrificar el SEO. Cada componente se hidrata según su trigger
• El modo zoneless elimina Zone.js del bundle y dirige la detección de cambios únicamente a los componentes afectados por Signals
• El render mode por ruta permite mezclar SSG, SSR y CSR en la misma aplicación según las necesidades de cada página
• Los componentes standalone-by-default eliminan la necesidad de NgModules en aplicaciones nuevas
• En entrevistas, demostrar los trade-offs (Signals vs RxJS, SSR vs CSR, zoneless vs Zone.js) importa más que la sintaxis