Wat zijn custom providers en injection tokens?

Question

Accepted Answer

Buiten eenvoudige `@Injectable()` klassen ondersteunt NestJS **custom providers** — flexibele manieren om te definiëren wat wordt ingespoten — met behulp van **injection tokens**. Dit stelt je in staat om waarden in te spuiten, te configureren hoe instanties worden gemaakt, implementaties uit te wisselen, en niet-class afhankelijkheden in te spuiten.

## De vier custom provider types

```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 — voor niet-class afhankelijkheden

```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
}
```

Omdat je geen interface of gewone waarde op type kunt inspuiten (deze bestaan niet in runtime), gebruik je een **token** (een string of `Symbol`) met `@Inject(token)` om deze in te spuiten. Dit is hoe je configuratieobjecten, third-party clients, of interface-getypeerde afhankelijkheden injecteerd.

## useFactory — het meest krachtig (dynamisch, async 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` voert een functie uit (met ingespoten afhankelijkheden) om de provider te produceren — essentieel voor verbindingen, clients, of alles wat runtime configuratie of async setup nodig heeft.

## Implementaties uitwisselen (useClass) — flexibiliteit & testen

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

Omdat consumers afhankelijk zijn van de token (`PaymentService`), kun je de concrete klasse uitwisselen — een echte Stripe service in productie, een mock in tests — zonder consumerende code te veranderen.

## Waarom het belangrijk is

Custom providers en injection tokens breiden NestJS's dependency injection uit beyond eenvoudige klassen, wat je de flexibiliteit geeft die nodig is voor real-world applicaties.

Het begrijpen ervan is belangrijk voor verschillende veel voorkomende scenario's: **niet-class waarden injecteren** (configuratieobjecten, constanten) via `useValue` en string/Symbol tokens (omdat je interfaces of gewone waarden niet op type kunt injecteren); **dynamisch/async provider creatie** via `useFactory` (de meest krachtige vorm — database verbindingen, Redis clients, of third-party SDK instanties aanmaken die geconfigureerd zijn met runtime waarden, met hun eigen ingespoten afhankelijkheden); en **implementaties uitwisselen** via `useClass` achter een token (wat omgeving-gebaseerde implementaties mogelijk maakt en, cruciaal, eenvoudig **mocking in tests** — een mock klasse leveren voor een token zonder consumers aan te raken).

Deze flexibiliteit is wat NestJS's DI krachtig maakt voor productie architectuur en uitstekende testbaarheid.

Het kennen van de vier provider types (`useClass`, `useValue`, `useFactory`, `useExisting`), hoe injection tokens werken voor niet-class afhankelijkheden, en wanneer je elk ervan inzet, is een belangrijke stap beyond basis DI — het is hoe je databases, externe services, configuratie, en verwisselbare/mockbare afhankelijkheden op de idiomatische NestJS manier verbindt, wat het een veel-benodigde, architecturaal-significante onderwerp in real applicaties maakt.