Hva er custom providers og injection tokens?

Question

Accepted Answer

Utover enkle `@Injectable()` klasser, støtter NestJS **custom providers** — fleksible måter å definere hva som skal injiseres — ved bruk av **injection tokens**. Dette lar deg injisere verdier, konfigurere hvordan instanser opprettes, bytte implementasjoner, og injisere ikke-klasse-avhengigheter.

## De fire custom provider-typene

```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 — for ikke-klasse-avhengigheter

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

Siden du ikke kan injisere et interface eller en enkel verdi etter type (de eksisterer ikke ved kjøretid), bruker du et **token** (en streng eller `Symbol`) med `@Inject(token)` for å injisere det. Dette er hvordan du injiserer konfigurasjons-objekter, tredjeparts-klienter, eller interface-typede avhengigheter.

## useFactory — den mest kraftfulle (dynamisk, async-oppsett)

```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` kjører en funksjon (med injiserte avhengigheter) for å produsere provider-en — essensielt for tilkoblinger, klienter, eller noe som trenger kjøretids-konfigurering eller async-oppsett.

## Bytte implementasjoner (useClass) — fleksibilitet & testing

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

Fordi konsumenter er avhengige av token-en (`PaymentService`), kan du bytte den konkrete klassen — en ekte Stripe-tjeneste i produksjon, en mock i tester — uten å endre noen konsument-kode.

## Hvorfor det betyr noe

Custom providers og injection tokens utvider NestJS's dependency injection utover enkle klasser, og gir deg fleksibiliteten som trengs for virkelige applikasjoner.

Å forstå dem er viktig for flere vanlige scenarioer: **injisere ikke-klasse-verdier** (konfigurasjons-objekter, konstanter) via `useValue` og streng/Symbol-tokens (siden du ikke kan injisere interfaces eller enkle verdier etter type); **dynamisk/async provider-opprettelse** via `useFactory` (den kraftfulleste formen — opprette database-tilkoblinger, Redis-klienter, eller tredjeparts-SDK-instanser konfigurert fra kjøretids-verdier, med sine egne injiserte avhengigheter); og **bytte implementasjoner** via `useClass` bak et token (muliggjør miljø-baserte implementasjoner og, kritisk, lett **mocking i tester** — gi en mock-klasse for et token uten å berøre konsumenter).

Denne fleksibiliteten er det som gjør NestJS's DI kraftfull for produksjons-arkitektur og utmerket testabilitet.

Å kjenne de fire provider-typene (`useClass`, `useValue`, `useFactory`, `useExisting`), hvordan injection tokens fungerer for ikke-klasse-avhengigheter, og når du skal bruke hver enkelt, er et viktig skritt utover grunnleggende DI — det er hvordan du kobler sammen databaser, eksterne tjenester, konfigurering, og utskiftbare/mockbare avhengigheter på den idiomatiske NestJS-måten, noe som gjør det til et hyppig påkrevd, arkitektur-betydningsfullt tema i virkelige applikasjoner.