Kaj so custom providerji in injection tokeni?

Question

Accepted Answer

Poleg preprostih `@Injectable()` razredov NestJS podpira **custom providerje** — fleksibilne načine za opredelitev tega, kaj se vbrizga — z uporabo **injection tokenov**. To vam omogoča vbrizgavanje vrednosti, konfiguriranje kako se ustvarijo instance, zamenjavo implementacij in vbrizgavanje odvisnosti, ki niso razredi.

## Štiri vrste custom providerjev

```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 tokeni — za odvisnosti, ki niso razredi

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

Ker ne morete vbrizgati vmesnika ali navadne vrednosti po vrsti (ne obstajajo med izvajanjem), uporabite **token** (niz ali `Symbol`) z `@Inject(token)` za vbrizgavanje. Tako vbrizgate konfiguracijske objekte, odjemalce tretjih strani ali odvisnosti, ki so tipizirane z vmesniki.

## useFactory — najbolj moč (dinamično, asincrono nastavljanje)

```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` zažene funkcijo (z vbrizganimi odvisnostmi) za proizvodnjo providerja — bistveno za povezave, odjemalce ali karkoli, kar potrebuje konfiguriranje med izvajanjem ali asincrono nastavljanje.

## Zamenjava implementacij (useClass) — fleksibilnost in testiranje

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

Ker potrošniki zavezani na token (`PaymentService`), lahko zamenjate konkretni razred — pravi Stripe servis v produkciji, navidez podatke pri testih — brez spreminjanja kakršnegakoli potrošniškega koda.

## Zakaj je to pomembno

Custom providerji in injection tokeni razširijo odvisnostno vbrizgavanje NestJS-a onkraj preprostih razredov, kar vam daje fleksibilnost, potrebno za aplikacije v realnem svetu.

Razumevanje je pomembno za več pogostih scenarijev: **vbrizgavanje vrednosti, ki niso razredi** (konfiguracijski objekti, konstante) preko `useValue` in string/Symbol tokenov (ker ne morete vbrizgati vmesnikov ali navadnih vrednosti po vrsti); **dinamično/asincrono ustvarjanje providerjev** preko `useFactory` (najbolj moč oblika — ustvarjanje povezav do podatkovne baze, Redis odjemalcev ali instanc SDK-jev tretjih strani, konfiguriranih iz vrednosti med izvajanjem, z lastnimi vbrizganimi odvisnostmi); in **zamenjava implementacij** preko `useClass` za token (omogočanje implementacij na osnovi okolja in, ključno, enostavljnega **mokiranje pri testih** — zagotovite mock razred za token brez dotikanja potrošnikov).

Ta fleksibilnost je tisto, kar naredi odvisnostno vbrizgavanje NestJS-a zmogljivo za produkcijsko arhitekturo in odličnu testabilnost.

Znanje štirih vrst providerjev (`useClass`, `useValue`, `useFactory`, `useExisting`), kako injection tokeni delujejo za odvisnosti, ki niso razredi, in kdaj se obrniti na posamezne, je pomemben korak onkraj osnovnega odvisnostnega vbrizgavanja — to je način, kako povežete podatkovne baze, zunanje storitve, konfiguracije in zamenljive/mokljive odvisnosti na idiomatičen NestJS način, kar ga naredi pogosto potrebno, arhitekturno pomembno temo v resničnih aplikacijah.