Hvad er custom providers og injection tokens?

Question

Accepted Answer

Udover simple `@Injectable()` klasser understøtter NestJS **custom providers** — fleksible måder at definere, hvad der bliver injiceret — ved hjælp af **injection tokens**. Dette lader dig injicere værdier, konfigurere hvordan instanser oprettes, bytte implementeringer ud, og injicere ikke-klasse-afhængigheder.

## De fire custom provider typer

```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-afhængigheder

```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 ikke kan injicere en interface eller en almindelig værdi efter type (de eksisterer ikke ved runtime), bruger du et **token** (en streng eller `Symbol`) med `@Inject(token)` til at injicere det. Dette er hvordan du injicerer konfigurationsobjekter, tredjepartsklients, eller interface-typede afhængigheder.

## useFactory — den mest kraftfulde (dynamisk, 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` kører en funktion (med injicerede afhængigheder) for at producere provideren — vigtig for forbindelser, klienter, eller hvad som helst, der skal have runtime-konfiguration eller async setup.

## Bytte implementeringer ud (useClass) — fleksibilitet & testing

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

Fordi consumere afhænger af tokenet (`PaymentService`), kan du bytte den konkrete klasse ud — en rigtig Stripe-service i produktion, en mock i tests — uden at ændre noget consumerkode.

## Hvorfor det betyder noget

Custom providers og injection tokens udvider NestJS's dependency injection udover simple klasser, hvilket giver dig den fleksibilitet, der er nødvendig for rigtige applikationer.

At forstå dem er vigtigt for flere almindelige scenarier: **injicering af ikke-klasse-værdier** (konfigurationsobjekter, konstanter) via `useValue` og streng/Symbol tokens (da du ikke kan injicere interfaces eller almindelige værdier efter type); **dynamisk/async provider-oprettelse** via `useFactory` (den mest kraftfulde form — oprettelse af databaseforbindelser, Redis-klienter, eller tredjeparts-SDK-instanser konfigureret fra runtime-værdier, med deres egne injicerede afhængigheder); og **bytte implementeringer ud** via `useClass` bag et token (hvilket muliggør miljø-baserede implementeringer og, afgørende, nemt **mocking i tests** — give en mock-klasse for et token uden at røre consumere).

Denne fleksibilitet er hvad der gør NestJS's DI kraftfuld for produktionsarkitektur og fantastisk testability.

At kende de fire provider-typer (`useClass`, `useValue`, `useFactory`, `useExisting`), hvordan injection tokens fungerer for ikke-klasse-afhængigheder, og hvornår man skal bruge hver enkelt, er et vigtigt skridt udover grundlæggende DI — det er hvordan du forbinder databaser, eksterne services, konfiguration, og byttbare/mockbare afhængigheder på den idiomatiske NestJS-måde, hvilket gør det til et hyppigt-påkrævet, arkitektonisk-betydningsfuldt emne i rigtige applikationer.