🎤 Preguntas de entrevista — Angular

Preguntas típicas de entrevista sobre Angular, con todas las alternativas desglosadas: qué significa cada una y por qué la correcta es la correcta. No basta memorizar la respuesta — la gracia es poder descartar las otras sabiendo qué son. Las primeras 15 vienen de la Evaluación 1 (2026-08-12). Las preguntas 16-29 vienen de la Evaluación 2 (2026-08-17, ✅ 100/100) — esa evaluación fue de respuesta directa, no de opción múltiple, así que las tablas de abajo usan conceptos reales relacionados (mencionados en el propio examen o parte del mismo ecosistema Angular) para poder comparar por qué la respuesta correcta es la correcta — no fueron alternativas literales del examen.

🧰 Servicios e inyección de dependencias

1. ¿Qué mecanismo usa Angular para proporcionar servicios a los componentes?

Alternativa	Qué es realmente	¿Por qué sí / no?
Herencia	Concepto de POO: una clase hija recibe métodos de su clase padre (extends)	❌ Sirve para reutilizar código entre clases, no para "entregar" un servicio a un componente
Inyección de dependencias	Angular crea la instancia del servicio y se la entrega al que la pide (constructor o inject())	✅ El componente no hace new ProductoService() — lo declara y Angular se lo inyecta
Property Binding	Enlazar un valor de la clase a una propiedad del HTML: [src]="foto"	❌ Conecta datos con el DOM, no clases entre sí
Directivas	Instrucciones que cambian el aspecto o comportamiento de un elemento (*ngIf, ngClass)	❌ Actúan sobre el template, no proveen servicios

🧪 La idea de fondo: con DI el componente dice qué necesita, no cómo construirlo. Angular mantiene una sola instancia compartida (singleton) — por eso dos componentes que inyectan el mismo servicio ven los mismos datos. Si cada uno hiciera new, cada uno tendría su propia copia y no compartirían nada.

2. ¿Qué decorador marca una clase como servicio inyectable?

Alternativa	Qué es realmente	¿Por qué sí / no?
@Component	Marca una clase como componente: tiene template, estilos y vive en el DOM	❌ Es para piezas visuales, no para lógica compartida
@NgModule	Agrupaba componentes/servicios en módulos (API clásica, hoy en desuso con standalone)	❌ Organiza, no marca inyectables
@Injectable	Marca la clase como "inyectable": Angular puede crearla y entregarla vía DI	✅ Con providedIn: 'root' queda disponible en toda la app sin registrarla a mano
@Directive	Marca una clase como directiva (lógica que se pega a un elemento HTML existente)	❌ Modifica elementos del DOM, no es un servicio

💡 Los 4 son decoradores (la @ antes de una clase): etiquetas que le dicen a Angular qué rol juega esa clase. La pregunta en el fondo evalúa si sabes distinguir los roles: componente = vista, directiva = comportamiento de DOM, módulo = agrupador, injectable = servicio.

🌐 HTTP, interceptores y environments

3. ¿Qué clase se usa para hacer peticiones HTTP?

Alternativa	Qué es realmente	¿Por qué sí / no?
HttpModule	La API antigua de HTTP de Angular (paquete @angular/http, retirada en Angular 8)	✅ en el examen — era la única alternativa que existió en Angular
RestClient	No existe en Angular (es un nombre típico de Java/Spring)	❌ Inventada
FetchService	No existe en Angular (suena a la API fetch() del navegador, pero ese no es su nombre)	❌ Inventada

📝 La respuesta moderna es HttpClient. La línea de tiempo:

@angular/http (HttpModule)  →  @angular/common/http (HttpClient)
         hasta Angular 7            desde Angular 4.3, único desde la 8

Cómo se activa hoy (standalone, tu app-05):
app.config.ts → provideHttpClient()

En una entrevista di HttpClient, y suma puntos mencionar que se inyecta en un servicio y devuelve Observables (no Promises) → ver Clase 11.

4. ¿Qué método HTTP se usa para actualizar un recurso completo?

Alternativa	Qué hace realmente	¿Por qué sí / no?
GET	Lee datos; no envía cuerpo, no modifica nada en el servidor	❌ Solo consulta
POST	Crea un recurso nuevo (el servidor le asigna id)	❌ Crea, no actualiza
PUT	Reemplaza el recurso completo con lo que envías	✅ "Actualizar completo" es su definición exacta
DELETE	Elimina el recurso	❌ Borra, no actualiza

🧪 La pregunta trampa que suele venir después: ¿PUT vs PATCH? PUT manda el objeto entero (lo que no mandes, se pierde); PATCH manda solo los campos que cambian. Regla mnemotécnica: PUT = poner todo, PATCH = parchar un pedazo.

5. ¿Cuál es la función de un interceptor HTTP?

Alternativa	Qué es realmente	¿Por qué sí / no?
Crear componentes	Eso lo hace el CLI (ng generate component)	❌ Nada que ver con HTTP
Modificar peticiones/respuestas	Un "peaje" por el que pasa toda petición saliente y respuesta entrante	✅ Puede leerlas, clonarlas y modificarlas antes de que sigan su camino
Generar rutas	Eso es del Router (provideRouter(routes))	❌ Otro subsistema
Validar formularios	Eso es de Forms (Validators.required, etc.)	❌ Otro subsistema

💡 Por qué existe: sin interceptor, cada servicio tendría que repetir el mismo código (agregar el token, manejar el error 401, prender el spinner). El interceptor lo centraliza:

Componente → Servicio → [ INTERCEPTOR ] → Internet → API
                             ↑ aquí se agregan headers,
                               se loguea, se manejan errores…

6. ¿Dónde se suele colocar el token de autenticación de las peticiones?

Alternativa	Qué es realmente	¿Por qué sí / no?
angular.json	Config del build (estilos globales, assets, presupuestos) — vive en tu máquina	❌ Nunca viaja al servidor
Headers mediante interceptor	El interceptor agrega Authorization: Bearer <token> a cada petición	✅ Un solo lugar, todas las peticiones salen autenticadas
Componente raíz	App — el primer componente que se pinta	❌ Es UI; poner el token ahí no lo adjunta a nada
tsconfig.json	Config del compilador TypeScript (strict, target, paths)	❌ Tampoco viaja; es de desarrollo

🧪 Esta pregunta une la 5 con la práctica: el caso de uso número 1 de un interceptor es exactamente este. Si en una entrevista te piden "un ejemplo real de interceptor", responde: "agregar el token JWT en el header Authorization de todas las peticiones".

7. ¿Cuál es la función de environment.ts?

Alternativa	Qué es realmente	¿Por qué sí / no?
Definir estilos	Los estilos van en .css/.scss (globales en styles.css)	❌
Configuración por entorno	Constantes que cambian entre desarrollo y producción (URL de la API, flags)	✅ El build elige el archivo según el entorno
Crear componentes	ng generate component	❌
Definir rutas	app.routes.ts + provideRouter	❌

💡 El mecanismo: hay (al menos) dos archivos gemelos y el build hace el cambio solo:

environment.ts        →  apiUrl: 'http://localhost:3000'   (ng serve)
environment.prod.ts   →  apiUrl: 'https://api.miapp.com'   (ng build)

El código siempre importa environment.apiUrl — nunca escribes la URL "a mano" en el servicio, así no hay que tocar código al pasar a producción.

🔄 Observables y operadores RxJS

📌 Contexto para todo este bloque: RxJS es la librería de programación reactiva que Angular usa para datos que llegan con el tiempo (HTTP, tecleo, clicks). Los operadores se encadenan dentro de .pipe(...) y transforman el flujo de emisiones antes de que llegue al .subscribe().

8. ¿Qué es un Observable?

Alternativa	Qué es realmente	¿Por qué sí / no?
Función que se ejecuta una sola vez	Describe más a una Promise (un solo valor, una sola vez)	❌ El Observable puede emitir muchas veces
Fuente de datos suscribible	Un "canal" que emite 0, 1 o N valores a lo largo del tiempo	✅ Y es perezoso: sin .subscribe() no pasa nada
Directiva	Lógica pegada a un elemento del DOM	❌ Otro mundo
Componente	Vista + lógica + estilos	❌ Otro mundo

🧪 Observable vs Promise (clásico de entrevista):

	Promise	Observable
Valores	Uno solo	0, 1 o muchos
¿Cuándo arranca?	Al crearse (eager)	Al suscribirse (lazy/frío)
¿Cancelable?	No	Sí (unsubscribe, switchMap)
Operadores	No	map, filter, debounceTime…

Profundiza en Conceptos — Observable y .subscribe().

9. ¿Qué operador transforma los valores que emite un Observable?

Alternativa	Qué hace realmente	¿Por qué sí / no?
filter	Deja pasar o bloquea cada valor según una condición (no lo cambia)	❌ Filtra, no transforma
map	Aplica una función a cada valor y emite el resultado	✅ "Transformar" es su definición
tap	"Espía" el valor (para hacer console.log o efectos) y lo deja pasar intacto	❌ No modifica el flujo
merge	Mezcla varios Observables en uno (emite lo que llegue de cualquiera)	❌ Combina fuentes, no transforma valores

💡 Es el mismo map de los arrays, pero sobre emisiones:

[1, 2, 3].map(n => n * 2)                    // arrays  → [2, 4, 6]
numeros$.pipe(map(n => n * 2))               // RxJS    → emite 2, 4, 6

10. ¿Qué operador evita procesar emisiones demasiado rápidas?

Alternativa	Qué hace realmente	¿Por qué sí / no?
switchMap	Cambia a un Observable nuevo y cancela el anterior	❌ Cancela, pero no "espera silencio"
debounceTime	Espera N ms sin emisiones nuevas antes de dejar pasar la última	✅ "Evitar emisiones rápidas" = debounce
combineLatest	Emite la combinación de los últimos valores de varios Observables	❌ Combina fuentes
forkJoin	Espera que todos completen y emite una sola vez	❌ Es el "Promise.all"

💡 La imagen mental: el usuario teclea "angular" en un buscador:

sin debounce:  a → an → ang → angu → angul → angula → angular   (7 peticiones ❌)
debounceTime(300): ....................(300 ms de silencio)... → angular (1 petición ✅)

11. ¿Qué operador cancela la petición anterior cuando llega un valor nuevo?

Alternativa	Qué hace realmente	¿Por qué sí / no?
switchMap	Por cada valor lanza un Observable interno y cancela el anterior si seguía vivo	✅ Switch = "se cambia" al nuevo y abandona el viejo
tap	Espía sin modificar	❌
filter	Deja pasar o no, según condición	❌
forkJoin	Espera a que todos completen	❌

🧪 El combo de buscador (pregunta estrella de entrevista): debounceTime(300) + switchMap(texto => this.api.buscar(texto)). El primero evita disparar de más; el segundo garantiza que si el usuario siguió tecleando, la búsqueda vieja se cancela y jamás pisa a la nueva (sin él, una respuesta lenta y vieja puede llegar después y sobreescribir los resultados buenos).

12. ¿Qué operador espera a que varios Observables terminen y entrega todo junto?

Alternativa	Qué hace realmente	¿Por qué sí / no?
debounceTime	Espera silencio entre emisiones	❌
forkJoin	Espera que todos los Observables completen y emite un único valor combinado	✅ El Promise.all de RxJS
map	Transforma cada valor	❌
BehaviorSubject	No es un operador — es un tipo de Subject (ver pregunta 13)	❌ Ni siquiera es de esta categoría

⚠️ Gotcha: forkJoin solo emite cuando todos completan. Un Observable que nunca completa (p. ej. un Subject abierto) deja a forkJoin esperando para siempre. Con peticiones HTTP funciona perfecto porque cada petición completa al responder.

13. ¿Qué distingue a un BehaviorSubject?

Alternativa	Qué significaría	¿Por qué sí / no?
No emite valores	Sería un Observable inútil	❌ Emite como cualquier Subject
Valor inicial + conserva el último	Nace con un valor y "recuerda" el último emitido	✅ Quien se suscribe tarde recibe el valor actual al instante
Solo funciona con HttpClient	Los Subjects no dependen de HTTP para nada	❌ Inventada
Un solo suscriptor	Al revés: los Subjects son multicast (muchos suscriptores)	❌ Es exactamente su fortaleza

💡 La familia Subject (un Subject es un Observable al que además puedes empujarle valores con .next()):

Tipo	¿Valor inicial?	¿Qué recibe un suscriptor tardío?
Subject	No	Nada — solo lo que se emita después
BehaviorSubject	Sí (obligatorio)	El último valor, al instante
ReplaySubject(n)	No	Los últimos n valores

Por eso BehaviorSubject es el estándar para estado compartido (usuario logueado, carrito): cualquier componente que llegue tarde ve la "foto" actual, no una pantalla vacía.

14. ¿Cuál es la ventaja del pipe async en el template?

Alternativa	Qué significaría	¿Por qué sí / no?
Suscripción automática	El template se suscribe solo y se desuscribe al destruir el componente	✅ Menos código y cero fugas de memoria
Convertir a Promise	Al revés: async consume Observables (y Promises) tal cual	❌ No convierte nada
Eliminar servicios	Los servicios siguen existiendo igual	❌ Inventada
Reemplazar ngFor	@for/*ngFor itera listas; async "desenvuelve" Observables — se combinan	❌ Roles distintos

🧪 Por qué importa la desuscripción: un .subscribe() manual que no se cancela sigue vivo aunque el componente muera → fuga de memoria y código ejecutándose de fondo. El pipe async (@for (p of productos$ | async; ...)) hace el ciclo completo por ti: suscribe al pintar, desuscribe al destruir. Es la opción "a prueba de olvidos".

🗃️ NgRx (manejo de estado)

15. ¿Qué representa el evento que dispara un cambio de estado en NgRx?

Alternativa	Qué es realmente en NgRx	¿Por qué sí / no?
Reducer	Función pura que recibe (estado actual, action) y devuelve el estado nuevo	❌ Calcula el cambio, no lo dispara
Store	El contenedor único donde vive todo el estado de la app	❌ Guarda, no dispara
Action	El evento que describe qué pasó: [Carrito] Agregar producto	✅ Todo cambio de estado empieza con una Action despachada
Selector	Función que lee un pedazo del estado desde el Store	❌ Consulta, no modifica

💡 El circuito completo (las 4 alternativas son las 4 piezas — la pregunta evalúa si conoces el rol de cada una):

Componente ──dispatch──▶ ACTION ("qué pasó")
                           │
                           ▼
                        REDUCER (estado viejo + action = estado nuevo)
                           │
                           ▼
                         STORE (guarda el estado único)
                           │
                           ▼
                       SELECTOR (el componente lee lo que necesita)

Es el patrón Redux: el estado nunca se modifica directo — siempre viaja por este circuito, lo que hace los cambios predecibles y fáciles de depurar.

🎨 Angular Material

16. ¿Qué paquete se instala para agregar Angular Material a un proyecto? (pregunta 1 de la Evaluación 2)

Comando	Qué hace realmente	¿Instala Angular Material?
npm install @angular/material	Descarga el paquete npm de Angular Material	✅ Es la respuesta del examen — agrega la dependencia
ng add @angular/material	Ejecuta el schematic: instala el paquete y configura tema, animaciones y fuentes	✅ En la práctica es el comando recomendado — hace todo en un paso
npm install @angular/cdk	Instala el Component Dev Kit, una dependencia de Material (a11y, overlay, drag&drop)	❌ No trae los componentes visuales en sí
npm install @angular/flex-layout	Librería de layout responsive, hoy deprecada (reemplazada por CSS Grid/Flexbox nativo)	❌ No es Angular Material

💡 npm install solo trae el paquete; ng add además ejecuta su schematic de configuración (tema, BrowserAnimationsModule, fuentes de Material Icons). Por eso en la práctica se usa más ng add, aunque el examen pedía el comando npm install.

17. ¿Qué componente de Angular Material se usa para crear un panel lateral de navegación? (pregunta 2)

Alternativa	Qué es realmente	¿Por qué sí / no?
mat-sidenav	Panel lateral, se usa junto a mat-sidenav-container/mat-sidenav-content	✅ Es el componente de navegación lateral
mat-toolbar	Barra superior (o inferior) para título, logo y acciones	❌ Es horizontal, no un panel lateral
mat-drawer	Componente base más genérico del que mat-sidenav hereda comportamiento	❌ Existe, pero mat-sidenav es la variante pensada para navegación
mat-menu	Menú desplegable contextual (aparece flotando sobre un botón)	❌ No es un panel fijo, es un popup

<mat-sidenav-container>
  <mat-sidenav mode="side" opened>Menú</mat-sidenav>
  <mat-sidenav-content>Contenido principal</mat-sidenav-content>
</mat-sidenav-container>

18. ¿Qué componente de Angular Material se utiliza para mostrar notificaciones breves y temporales? (pregunta 3)

Alternativa	Qué es realmente	¿Por qué sí / no?
mat-snackbar (MatSnackBar)	Muestra un aviso breve en la parte inferior, con duración configurable	✅ "Breve y temporal" es su definición exacta
mat-dialog	Ventana modal: bloquea la pantalla hasta que el usuario responde	❌ No es breve ni desaparece solo
mat-menu	Menú desplegable de opciones	❌ No es una notificación
mat-table	Tabla de datos (ver pregunta 26)	❌ Otro propósito por completo

this.snackBar.open('Datos guardados correctamente', 'Cerrar', { duration: 3000 });

🧪 Snackbar vs Dialog, pregunta clásica de entrevista: el snackbar no bloquea la interacción y se cierra solo (o con un botón de acción); el dialog sí bloquea hasta que el usuario cierra o confirma. Usa snackbar para "guardado ✅" y dialog para "¿confirmas eliminar este registro?".

🔐 Autenticación y seguridad (JWT)

20. En un login con JWT, ¿qué se almacena en el cliente para mantener la sesión? (pregunta 5)

Alternativa	Qué es realmente	¿Por qué sí / no?
El token JWT	Cadena firmada por el backend que identifica al usuario	✅ El cliente lo reenvía en cada petición para probar quién es
La contraseña del usuario	El secreto que se usó una sola vez para hacer login	❌ Nunca se guarda — si se filtra, compromete la cuenta entera
El ID de sesión del servidor	Identificador de una sesión guardada en el backend (auth basada en sesión, no en token)	❌ Es otro paradigma: JWT es stateless, no depende de que el servidor recuerde nada
Usuario y clave en una cookie plana	Guardar las credenciales tal cual, sin cifrar ni expirar	❌ Inseguro — cualquiera que lea la cookie tiene la cuenta

Authorization: Bearer <token>

💡 Por qué JWT es stateless: el token ya trae adentro (firmado, no cifrado) los datos del usuario y su expiración. El backend solo verifica la firma — no necesita guardar nada en una base de sesiones, lo que lo hace fácil de escalar entre servidores.

21. ¿Cuál es la función principal de un Guard de autenticación? (pregunta 6)

Alternativa	Qué es realmente	¿Por qué sí / no?
Prevenir el acceso a una ruta si no se cumplen condiciones (p. ej. estar autenticado)	Función que Angular ejecuta antes de activar una ruta	✅ Es su rol exacto: CanActivate
Interceptor	Modifica peticiones/respuestas HTTP (ver pregunta 22)	❌ Actúa sobre HTTP, no sobre rutas
Resolver	Precarga datos antes de activar una ruta, para que el componente nazca con la info lista	❌ Prepara datos, no bloquea acceso
Pipe	Transforma un valor en el template ({{ fecha | date }})	❌ Nada que ver con rutas ni seguridad

canActivate(): boolean {
  if (this.authService.isAuthenticated()) return true;
  this.router.navigate(['/login']);
  return false;
}

📎 Ya viste la base de esto (servicio Auth con signal, ng g guard) en la Clase 9 — Routing avanzado; el canActivate en sí quedó pendiente ahí y esta pregunta lo completa en teoría.

22. ¿Dónde se recomienda agregar el token JWT a las peticiones HTTP salientes? (pregunta 7)

Alternativa	Qué es realmente	¿Por qué sí / no?
En un interceptor HTTP	"Peaje" centralizado por el que pasa toda petición saliente	✅ Un solo lugar agrega el header a todas las peticiones
En cada servicio, a mano	Repetir setHeaders: { Authorization: ... } en cada método HTTP	❌ Funciona, pero duplica código y es fácil olvidarlo en algún lugar
En el componente raíz (App)	El primer componente que se pinta	❌ Los componentes no interceptan peticiones HTTP
En environment.ts	Solo guarda configuración estática por entorno (URLs, flags)	❌ No ejecuta lógica en cada petición

intercept(req: HttpRequest<any>, next: HttpHandler) {
  const token = localStorage.getItem('token');
  const authReq = req.clone({ setHeaders: { Authorization: `Bearer ${token}` } });
  return next.handle(authReq);
}

23. ¿Qué estrategia restringe el acceso según el tipo de usuario? (pregunta 8)

Alternativa	Qué es realmente	¿Por qué sí / no?
Roles y permisos	Cada usuario tiene un rol (ADMIN, EDITOR, USER, SUPERVISOR…) que determina qué puede hacer	✅ Es la estrategia completa: define y valida qué le corresponde a cada tipo de usuario
Solo Guards	Protegen rutas, pero por sí solos solo verifican "¿está logueado?", no "¿qué rol tiene?"	❌ Necesitan el dato del rol para poder filtrar — son el mecanismo, no la estrategia
Solo Interceptor	Modifica peticiones HTTP, no decide qué puede ver el usuario en la UI	❌ Otro propósito
Solo *ngIf en el template	Oculta botones/secciones visualmente	❌ Solo es cosmético — sin validación en el Guard o el backend, el usuario podría acceder igual por URL directa o API

if (user.role === 'ADMIN') { /* permitir acción */ }

⚠️ Gotcha de seguridad: ocultar un botón con *ngIf no es "seguridad" — es UX. La restricción real tiene que validarse también en el Guard (frontend) y en el backend, porque cualquiera puede llamar a la API directo sin pasar por la UI.

⚡ Diseño responsive y rendimiento

19. ¿Qué característica de diseño adapta la app a distintos tamaños de pantalla? (pregunta 4)

Alternativa	Qué es realmente	¿Por qué sí / no?
Diseño Responsive	La interfaz se adapta a celulares, tablets y computadoras (media queries, unidades relativas, grid/flex)	✅ Es la respuesta — trata de adaptación visual, no de velocidad
Lazy Loading	Carga recursos (módulos, imágenes) solo cuando se necesitan	❌ Es rendimiento (menos peso inicial), no adaptación de layout
Tree Shaking	El bundler elimina del build el código que nunca se usa	❌ Reduce tamaño del bundle, no cambia el layout
Change Detection	Mecanismo que actualiza la vista cuando cambian los datos	❌ Es reactividad, no diseño visual

💡 Confusión típica: los tres distractores sí son de rendimiento, pero la pregunta pide algo de diseño/layout. Aprender a distinguir "se ve bien en cualquier pantalla" (responsive) de "carga/corre rápido" (Lazy Loading, Tree Shaking, Change Detection) es justo lo que esta pregunta evalúa.

24. ¿Para qué se utiliza trackBy dentro de un ngFor? (pregunta 9)

Alternativa	Qué hace realmente	¿Por qué sí / no?
Optimizar el renderizado, evitando recrear elementos del DOM innecesariamente	Angular identifica cada ítem por un valor único (item.id) en vez de por posición	✅ Sin trackBy, Angular destruye y recrea el DOM entero de la lista ante cualquier cambio
*ngFor sin trackBy	Compara por referencia/posición del array	❌ Es exactamente el comportamiento que trackBy evita — más lento con listas grandes
@for con track	La sintaxis moderna de control flow (Angular 17+) que exige indicar el track por defecto	❌ No es la respuesta a esta pregunta (que usa *ngFor), pero es su equivalente actual — mismo concepto, sintaxis nueva
ngOnChanges	Hook del ciclo de vida que detecta cambios en @Input (ver Clase 4)	❌ Es otro mecanismo — detecta cambios de props, no optimiza listas

trackById(index: number, item: Usuario) { return item.id; }

<div *ngFor="let usuario of usuarios; trackBy: trackById">{{ usuario.nombre }}</div>

25. ¿Qué hace ChangeDetectionStrategy.OnPush? (pregunta 10)

Alternativa	Qué hace realmente	¿Por qué sí / no?
Verifica cambios solo cuando cambian las referencias de los @Input o se dispara un evento	Angular deja de revisar ese componente en cada ciclo de detección — solo lo hace ante señales puntuales	✅ "Menos verificaciones" es su definición y su beneficio
Estrategia por defecto (Default)	Angular revisa todos los componentes en cada ciclo de detección de cambios	❌ Es lo contrario — más seguro pero más costoso en apps grandes
ngZone.runOutsideAngular()	Ejecuta código fuera de la zona de Angular para que no dispare detección de cambios en absoluto	❌ Otra técnica de rendimiento, más agresiva — evita la detección en vez de reducirla
Signals	Mecanismo de reactividad más nuevo que notifica cambios de forma granular, reduciendo la necesidad de configurar OnPush a mano	❌ No es la respuesta, pero es hacia donde Angular está evolucionando para este mismo problema

@Component({
  selector: 'app-usuario',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UsuarioComponent {
  @Input() usuario!: Usuario;
}

🎨 Angular Material (continuación)

26. En un dashboard administrativo, ¿qué elemento muestra datos tabulares con orden y paginación? (pregunta 11)

Alternativa	Qué es realmente	¿Por qué sí / no?
mat-table	El componente de tabla de Angular Material	✅ Es la respuesta — se combina con matSort y mat-paginator
matSort	Directiva que agrega ordenamiento por columna a una mat-table existente	❌ Complementa a la tabla, no la reemplaza
mat-paginator	Componente de paginación, separado de la tabla	❌ También complementa, no muestra los datos por sí solo
*ngFor sobre un <table> HTML plano	Se puede armar una tabla a mano iterando un array	❌ Funciona, pero sin orden/paginación integrados hay que programarlos todos a mano

<table mat-table [dataSource]="dataSource" matSort>...</table>
<mat-paginator [pageSize]="10"></mat-paginator>

🚀 Build y despliegue (CI/CD)

27. ¿Qué comando genera un build de producción en Angular? (pregunta 12)

Alternativa	Qué hace realmente	¿Por qué sí / no?
ng build --configuration production	Compila la app con la configuración de producción (minificado, optimizado)	✅ Genera los archivos que se publican en el hosting
ng serve	Levanta el servidor local de desarrollo, con recarga en vivo	❌ Es para desarrollar, no genera archivos para publicar
ng test	Ejecuta las pruebas unitarias del proyecto	❌ No compila para producción
ng deploy	Publica el build cuando el proyecto tiene un mecanismo de deploy configurado (p. ej. angular-cli-ghpages)	❌ Es un paso posterior — primero se necesita el build

28. ¿Qué ofrecen plataformas como Netlify y Vercel para el deploy de frontend? (pregunta 13)

Alternativa	Qué es realmente	¿Por qué sí / no?
Despliegue continuo, hosting y configuración de dominio de forma sencilla	Conectan el repositorio Git y publican automáticamente en cada push	✅ Es su propuesta de valor completa
Solo hosting estático sin CI (tipo bucket S3 puro)	Sirve archivos, pero no reconstruye el sitio automáticamente ante cada cambio	❌ Falta la parte de build automático + integración Git
Backend-as-a-Service completo (tipo Firebase con base de datos)	Ofrece también backend/DB gestionada	❌ Netlify/Vercel se enfocan en frontend; el backend es un servicio aparte (o funciones serverless)
Un simple CDN sin build	Solo distribuye archivos ya compilados, sin tocar el código fuente	❌ Netlify/Vercel sí compilan el proyecto por ti

Git Push → Repositorio → Build automático → Deploy

29. ¿Qué busca principalmente un pipeline de CI/CD? (pregunta 15)

Alternativa	Qué es realmente	¿Por qué sí / no?
Automatizar la integración, las pruebas y el despliegue del código	Todo el ciclo Commit → Build → Test → Deploy corre solo, sin pasos manuales	✅ Es la definición completa de CI/CD
Solo control de versiones	Eso es lo que hace Git en sí (guardar historial de cambios)	❌ CI/CD se apoya en Git, pero es un paso más
Solo testing manual	Ejecutar pruebas a mano, sin automatización	❌ Es justo lo opuesto a "Continuous Integration"
Solo hosting	Eso es lo que ofrecen Netlify/Vercel (pregunta 28)	❌ El pipeline es el proceso completo; el hosting es solo el destino final del deploy

Commit → Build → Test → Deploy

💡 CI (Continuous Integration) = integrar cambios seguido + validar automático (instalar deps, compilar, testear, revisar calidad). CD (Continuous Delivery/Deployment) = automatizar la publicación de esas versiones ya validadas.

📎 Apuntes relacionados

• Evaluación 1 — de donde salen las preguntas 1-15
• Evaluación 2 — de donde salen las preguntas 16-29
• Clase 9 — Routing avanzado (Guards)
• Clase 11 — Servicios y HTTP en la práctica
• Conceptos — Observable y .subscribe()