Was sind Custom Provider und Injection Tokens?

Question

Accepted Answer

Über einfache `@Injectable()` Klassen hinaus unterstützt NestJS **Custom Provider** — flexible Möglichkeiten, um zu definieren, was injiziert wird — über **Injection Tokens**. Dies ermöglicht es dir, Werte zu injizieren, zu konfigurieren, wie Instanzen erstellt werden, Implementierungen auszutauschen und Nicht-Klassen-Abhängigkeiten zu injizieren.

## Die vier Custom-Provider-Typen

```ts
@Module({
  providers: [
    // 1. useClass — standard (or swap the implementation behind a token)
    { provide: PaymentService, useClass: StripePaymentService },

// 2. useValue — inject a constant/object/mock (great for config and testing)
    { provide: "CONFIG", useValue: { apiKey: "abc", timeout: 5000 } },

// 3. useFactory — compute the provider dynamically (can use other deps)
    {
      provide: "DATABASE_CONNECTION",
      useFactory: async (config: ConfigService) => {
        return await createConnection(config.get("DB_URL"));   // async setup
      },
      inject: [ConfigService],        // dependencies for the factory
    },

// 4. useExisting — create an alias for an existing provider
    { provide: "ALIAS", useExisting: PaymentService },
  ],
})
export class AppModule {}
```

## Injection Tokens — für Nicht-Klassen-Abhängigkeiten

```ts
// classes can be tokens directly (by type). For values/interfaces, use a string/Symbol token:
@Injectable()
export class PaymentProcessor {
  constructor(@Inject("CONFIG") private config: AppConfig) {}   // inject by token
}
```

Da du keine Schnittstelle oder einen einfachen Wert nach Typ injizieren kannst (sie existieren zur Laufzeit nicht), verwendest du ein **Token** (ein String oder `Symbol`) mit `@Inject(token)` um es zu injizieren. So injizierst du Konfigurationsobjekte, Clients von Drittanbietern oder schnittstellentypisierte Abhängigkeiten.

## useFactory — die mächtigste (dynamisch, asynchrones Setup)

```ts
// create a provider whose value depends on runtime config / async initialization
{
  provide: "REDIS_CLIENT",
  useFactory: (config: ConfigService) => new Redis(config.get("REDIS_URL")),
  inject: [ConfigService],
}
```

`useFactory` führt eine Funktion aus (mit injizierten Abhängigkeiten), um den Provider zu erstellen — essentiell für Verbindungen, Clients oder alles, das Laufzeitkonfiguration oder asynchrones Setup benötigt.

## Implementierungen austauschen (useClass) — Flexibilität & Testen

```ts
// inject a different implementation based on environment
{
  provide: PaymentService,
  useClass: process.env.NODE_ENV === "test" ? MockPaymentService : StripePaymentService,
}
```

Da Consumer vom Token (`PaymentService`) abhängen, kannst du die konkrete Klasse austauschen — einen echten Stripe-Service in der Produktion, einen Mock in Tests — ohne irgendwelchen Consumer-Code zu ändern.

## Warum es wichtig ist

Custom Provider und Injection Tokens erweitern NestJS's Dependency Injection über einfache Klassen hinaus und geben dir die Flexibilität, die für echte Anwendungen notwendig ist.

Sie zu verstehen ist wichtig für mehrere häufige Szenarien: **Nicht-Klassen-Werte injizieren** (Konfigurationsobjekte, Konstanten) über `useValue` und String/Symbol Tokens (da du Schnittstellen oder einfache Werte nicht nach Typ injizieren kannst); **dynamische/asynchrone Provider-Erstellung** über `useFactory` (die mächtigste Form — Datenbankverbindungen, Redis-Clients oder Third-Party-SDK-Instanzen erstellen, konfiguriert aus Laufzeitwerten, mit ihren eigenen injizierten Abhängigkeiten); und **Implementierungen austauschen** über `useClass` hinter einem Token (ermöglicht umgebungsbasierte Implementierungen und, entscheidend, einfaches **Mocken in Tests** — stelle eine Mock-Klasse für einen Token zur Verfügung, ohne Consumer zu verändern).

Diese Flexibilität ist das, was NestJS's DI für Produktionsarchitektur mächtig und ausgezeichnete Testbarkeit macht.

Die vier Provider-Typen (`useClass`, `useValue`, `useFactory`, `useExisting`) zu kennen, zu verstehen, wie Injection Tokens für Nicht-Klassen-Abhängigkeiten funktionieren, und wann man zu welchem greifen sollte, ist ein wichtiger Schritt über einfaches DI hinaus — es ist die Weise, wie du Datenbanken, externe Services, Konfiguration und austauschbare/mockbare Abhängigkeiten auf die idiomatische NestJS-Art verbindest, was es zu einem häufig benötigten, architektonisch signifikanten Thema in echten Anwendungen macht.