Czym są dostawcy niestandardowi i tokeny iniekcji?

Question

Accepted Answer

Poza prostymi klasami `@Injectable()`, NestJS obsługuje **dostawców niestandardowych** — elastyczne sposoby definiowania tego, co zostaje wstrzyknięte — używając **tokenów iniekcji**. Pozwala to na wstrzykiwanie wartości, konfigurowanie sposobu tworzenia instancji, zamianę implementacji oraz wstrzykiwanie zależności spoza klasy.

## Cztery typy dostawców niestandardowych

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

## Tokeny iniekcji — dla zależności spoza klasy

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

Ponieważ nie możesz wstrzyknąć interfejsu lub wartości zwykłej według typu (nie istnieją w runtime), używasz **tokenu** (ciągu znaków lub `Symbol`) z `@Inject(token)` aby go wstrzyknąć. To jest sposób na wstrzykiwanie obiektów konfiguracyjnych, klientów trzecich stron lub zależności o typie interfejsu.

## useFactory — najbardziej potężny (dynamiczny, 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` uruchamia funkcję (z wstrzykiwanymi zależnościami) aby wyprodukować dostawcę — niezbędne dla połączeń, klientów lub czegokolwiek wymagającego konfiguracji runtime lub setup async.

## Zamiana implementacji (useClass) — elastyczność i testowanie

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

Ponieważ konsumenci zależą od tokenu (`PaymentService`), możesz zamienić konkretną klasę — rzeczywistą usługę Stripe w produkcji, mock w testach — bez zmiany kodu konsumentów.

## Dlaczego to ważne

Dostawcy niestandardowi i tokeny iniekcji rozszerzają dependency injection NestJS poza proste klasy, dając ci elastyczność potrzebną dla rzeczywistych aplikacji.

Zrozumienie ich jest ważne dla kilku typowych scenariuszy: **wstrzykiwanie wartości spoza klasy** (obiekty konfiguracyjne, stałe) przez `useValue` i tokeny string/Symbol (ponieważ nie możesz wstrzyknąć interfejsów lub wartości zwykłych według typu); **dynamiczne/async tworzenie dostawcy** przez `useFactory` (najbardziej potężna forma — tworzenie połączeń do baz danych, klientów Redis lub instancji SDK trzecich stron skonfigurowanych ze wartości runtime, z własnymi wstrzykiwanymi zależnościami); oraz **zamiana implementacji** przez `useClass` za tokenem (umożliwiająca implementacje zależne od środowiska i, najważniej, łatwe **mockowanie w testach** — podanie klasy mock dla tokenu bez dotykania konsumentów).

Ta elastyczność to właśnie to co czyni DI NestJS potężnym dla architektury production i doskonałą testowalność.

Znajomość czterech typów dostawcy (`useClass`, `useValue`, `useFactory`, `useExisting`), jak działają tokeny iniekcji dla zależności spoza klasy, i kiedy sięgnąć po każdy z nich to ważny krok poza podstawowy DI — to jak okablowujesz bazy danych, usługi zewnętrzne, konfigurację i zamienialne/mockowane zależności w idiomatyczną metodę NestJS, czyniąc to często potrzebnym, architektonicznie znaczącym tematem w rzeczywistych aplikacjach.