¿Cómo cancelarías peticiones HTTP y evitarías memory leaks en componentes y servicios Angular?

Detrás de "¿Cómo cancelarías peticiones HTTP y evitarías memory leaks en componentes y servicios Angular?" suele haber una tensión real en Angular entre asincronía y rxJS.

En una entrevista fuerte gana peso la persona que habla de costes, señales de degradación, deuda aceptada y plan de validación para "Cómo cancelarías peticiones HTTP y evitarías memory leaks en componentes y servicios Angular", no solo de API o sintaxis.

Qué evalúa el entrevistador

• Si distingues qué parte de "Cómo cancelarías peticiones HTTP y evitarías memory leaks en componentes y servicios Angular" pertenece a asincronía y cuál debería resolverse en rxJS.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si sabes ubicar efectos, limpiezas, cancelación y propagación de errores sin contaminar la parte declarativa del código.

Respuesta sólida

• Distingue qué parte puede seguir siendo pura y qué parte necesita sincronizarse con el mundo exterior.
• Describe cómo controlarías suscripciones, cancelación, reintentos o cierre de recursos para que el componente no acumule efectos zombis.
• Si hay asincronía, aclara qué harías con estados intermedios, errores y cambios rápidos de entrada.

Compromisos y errores comunes

• El error habitual es usar efectos para derivar datos que podrían calcularse de forma pura o para tapar un mal diseño de dependencias.
• Sin cancelación ni limpieza es muy fácil dejar trabajo en vuelo, respuestas tardías o cierres obsoletos.

Ejemplo de código

Este fragmento sirve para bajar "Cómo cancelarías peticiones HTTP y evitarías memory leaks en componentes y servicios Angular" a código ejecutable y mostrar qué decisiones conviene hacer explícitas cuando asincronía empieza a cruzarse con rxJS.

import { HttpInterceptorFn } from '@angular/common/http';
import { catchError, throwError } from 'rxjs';

export const authInterceptor: HttpInterceptorFn = (request, next) => {
  const authenticatedRequest = request.clone({
    setHeaders: { Authorization: 'Bearer token-demo' },
  });

  return next(authenticatedRequest).pipe(
    catchError((error) => {
      console.error('Error HTTP', error.status);
      return throwError(() => error);
    }),
  );
};

Fíjate en que el ejemplo deja claras las fronteras de "Cómo cancelarías peticiones HTTP y evitarías memory leaks en componentes y servicios Angular", nombra los estados relevantes y evita trabajo implícito que luego cuesta depurar.

Ejemplo o caso real

Un caso creíble para "¿Cómo cancelarías peticiones HTTP y evitarías memory leaks en componentes y servicios Angular?" aparece cuando una funcionalidad de Angular mezcla asincronía con rxJS y el equipo empieza a tocar demasiados puntos para un cambio pequeño. Ahí conviene probar la solución sobre una pantalla o flujo acotado, medir si reduce fricción y solo después extender el patrón.

Frase corta de entrevista

Si una decisión de Angular no mejora claridad, coste de cambio o fiabilidad, probablemente aún no merece existir.