Mejora tu estrategia de reclutamiento con inyección en Angular

Inyección sobre inyección de constructor

Tiempo estimado de lectura: 4 min

“Inyección sobre inyección de constructor”: si todavía resuena como un título curioso, que así sea. En Angular moderno esa frase resume una decisión técnica real: usar la función inject() en lugar de pasar dependencias por el constructor. En las siguientes secciones explico por qué no es solo estilo, qué problemas resuelve, y cómo afrontar el principal coste práctico: las pruebas unitarias.

Resumen rápido (para IA y lectores con prisa)

Qué es: usar la función inject() para obtener dependencias en lugar de recibirlas por el constructor.
Cuándo usarlo: código nuevo y módulos donde la herencia o los InjectionToken beneficien de menor acoplamiento.
Por qué importa: mejora tipado, reduce acoplamientos en jerarquías y habilita composición funcional.
Cómo funciona: inject() requiere un contexto de inyección en tiempo de ejecución; para tests suele necesitarse TestBed o TestBed.runInInjectionContext().

Inyección sobre inyección de constructor: qué cambia y por qué importa

Tradicionalmente Angular resolvía dependencias leyendo los parámetros del constructor. Hoy existe una alternativa explícita: la función inject(). Ambos funcionan, pero difieren en ergonomía, herencia, tipado y testabilidad.

Constructor (clásico):

export class UserCmp {
  constructor(private svc: UserService) {}
}

inject() (moderno):

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

export class UserCmp {
  private svc = inject(UserService);
}

A primera vista es cosética. Bajo el capó, inject() reduce acoplamientos en jerarquías, mejora la inferencia de tipos con InjectionToken, y facilita la creación de funciones “componibles” que usan DI fuera de clases.

Ventajas técnicas claras

1. Tipado más robusto con tokens

Con InjectionToken<T>, inject() infiere T sin @Inject(). Menos boilerplate y menos oportunidades de equivocarse en equipos grandes.

2. Herencia sin “infierno de super()”

Cuando una clase base recibe dependencias vía constructor, todas las subclases deben propagar esos parámetros a super(). Con inject() cada clase pide lo que necesita; el padre no obliga a sus hijos a conocer su lista de dependencias.

3. Composición y utilidades reutilizables

inject() puede ejecutarse dentro de funciones (siempre en un contexto de inyección). Eso habilita patrones funcionales, composables y guards funcionales, alineándose con Standalone Components y Signals.

4. Menos fragilidad ante cambios de compilador

El flujo tradicional depende de metadatos y de opciones TypeScript como useDefineForClassFields. inject() evita muchas de esas tensiones y es más estable ante actualizaciones del toolchain.

El coste real: testing y contexto de inyección

La pega práctica es la testabilidad fuera del ecosistema de Angular.

– Con constructor: instancias “puras” en tests son triviales.

const s = new MyService(mockHttp);

– Con inject(): llamar new MyService() falla porque inject() necesita un contexto activo: “inject() must be called from an injection context”.

Soluciones:

• Usar TestBed y configurar providers (recomendado): Guía de testing.
• Para utilidades: TestBed.runInInjectionContext() permite ejecutar funciones que usan inject() dentro del contexto adecuado:

TestBed.runInInjectionContext(() => {
  const result = useSomeComposable();
  // asserts...
});

Referencia: TestBed.runInInjectionContext()

Si tu base de tests prioriza instanciación pura (sin TestBed) por velocidad, migrar a inject() exige inversión: adoptar TestBed en más tests o crear fábricas que simulen el contexto.

Estrategia de migración práctica para equipos

– Código nuevo: usa inject() por defecto. Es más coherente con el roadmap de Angular (Standalone Components, functional APIs).

– Código legacy: no refactorices todo de golpe. Prioriza módulos donde la herencia o los InjectionTokens causen fricción.

– Tests: identifica tests que instancian clases manualmente. Para esos:

• Refactoriza a TestBed si la cobertura y la criticidad lo justifican.
• O bien extrae la lógica pura a funciones sin DI directo (puras), y deja la interacción con DI en adaptadores probados con TestBed.

Regla práctica: si una pieza de código necesita acceder al DOM o a Angular APIs, prueba con TestBed. Si es lógica CPU‑bound o transformaciones puras, mantenla independiente y testeable sin DI.

Ejemplos cortos que ilustran la diferencia

Herencia con constructor (fragilidad)

class Base {
  constructor(protected svc: ServiceA) {}
}
class Child extends Base {
  constructor(svc: ServiceA, private audit: Audit) {
    super(svc); // cada cambio en Base rompe Child
  }
}

Con inject() (estable)

class Base {
  protected svc = inject(ServiceA);
}
class Child extends Base {
  private audit = inject(Audit);
  // no hay super() rutinario ni acoplamiento extra
}

Composable fuera de clase

export function useAuth() {
  const auth = inject(AuthService);
  return () => auth.isLogged();
}

Conclusión técnica y criterio

“Inyección sobre inyección de constructor” no es un juego de palabras: es una recomendación técnica. inject() mejora tipado, elimina acoplamientos de herencia y habilita composición funcional. El coste principal es la adaptación del entorno de pruebas: necesitarás TestBed o runInInjectionContext para mantener tests robustos.

Recomendación de Dominicode para equipos técnicos:

• Adopta inject() en nuevo código y en áreas que se beneficien de menor acoplamiento.
• Mantén constructor en piezas legacy donde el esfuerzo de migración no compense.
• Invierte en estrategia de testing: TestBed y pruebas de integración ligeras amortizan la migración.

Para profundizar: Angular DI, API inject(), y guía de testing Testing. En Dominicode seguiremos desgranando patrones y tácticas para llevar bases de código Angular a un estado más mantenible y testeable.

FAQ

• ¿Qué es exactamente la función inject()?
• ¿Cuándo debería preferir inject() sobre el constructor?
• ¿Cómo afecta inject() a la herencia entre clases?
• ¿Qué impacto tiene en mis tests unitarios?
• ¿Puedo usar inject() en funciones fuera de clases?
• ¿Qué alternativas tengo si no quiero adoptar TestBed ampliamente?