Mik a custom provider-ek és az injection token-ek?

Question

Accepted Answer

Az egyszerű `@Injectable()` osztályokon túl a NestJS támogatja az **custom provider-ek** — rugalmas módok annak meghatározására, hogy mi kerül injektálásra — az **injection token-ek** segítségével. Ez lehetővé teszi értékek injektálását, a példányok létrehozásának konfigurálását, implementációk cseréjét és nem osztály jellegű dependenciák injektálását.

## A négy custom provider típus

```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 token-ek — nem osztály jellegű dependenciákhoz

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

Mivel nem injektálhat interfészt vagy egyszerű értéket típussal (futásidőben nem léteznek), egy **token**-t (string vagy `Symbol`) használ a `@Inject(token)`-nel az injektálásához. Így injektál konfigurációs objektumokat, harmadik féltől származó ügyfeleket vagy interfész típusú dependenciákat.

## useFactory — a legerősebb (dinamikus, aszinkron 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],
}
```

A `useFactory` egy függvényt futtat (injektált dependenciákkal), hogy előállítson egy provider-t — alapvető a kapcsolatok, ügyfelek vagy bármely futásidőben konfigurált vagy aszinkron setup-ot igénylő dolog számára.

## Implementációk cseréje (useClass) — rugalmasság és tesztelés

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

Mivel a fogyasztók a token-ből függenek (`PaymentService`), kicserélheti a konkrét osztályt — egy valódi Stripe szolgáltatás az éles környezetben, egy mock a tesztekben — anélkül, hogy megváltoztatná a felhasználó kódot.

## Miért fontos

A custom provider-ek és injection token-ek kiterjesztik a NestJS függőségi injektálását az egyszerű osztályokon túl, és megadják a valós alkalmazásokhoz szükséges rugalmasságot.

Fontos megérteni őket számos gyakori forgatókönyv miatt: **nem osztály jellegű értékek injektálása** (konfigurációs objektumok, konstansok) a `useValue` és string/Symbol token-eken keresztül (mivel nem injektálhat interfészeket vagy egyszerű értékeket típussal); **dinamikus/aszinkron provider-ek létrehozása** a `useFactory` segítségével (a legerősebb forma — adatbázis-kapcsolatok, Redis ügyfelek vagy futásidőben konfigurált harmadik féltől származó SDK példányok létrehozása a saját injektált dependenciáikkal); és **implementációk cseréje** a `useClass` segítségével egy token mögött (lehetővé teszi a környezetfüggő implementációkat és crucially, könnyed **mockingot a tesztekben** — egy mock osztályt biztosíthat egy token-hez anélkül, hogy a fogyasztókat módosítaná).

Ez a rugalmasság az, ami a NestJS függőségi injektálását erőssé teszi az éles architektúrához és kiváló tesztelhetőséget ad.

A négy provider típus (`useClass`, `useValue`, `useFactory`, `useExisting`), az injection token-ek működése nem osztály jellegű dependenciák számára, és mikor kell mindegyikhez fordulni, az alapvető függőségi injektálás után egy fontos lépés — így köthet össze adatbázisokat, külső szolgáltatásokat, konfigurációt és cserélhető/mockelhető dependenciákat az idiomatikus NestJS módon, ami az idiomatic NestJS módszert teszi a valós alkalmazásokban gyakran szükséges, architektúrailag szignifikáns témává.