რა არის custom providers და injection tokens?

Question

Accepted Answer

მარტივი `@Injectable()` კლასების გარდა, NestJS აერთებს **custom providers** — მოქნილი მეთოდებს იმის განსაზღვრისთვის, რა ხდება inject-ებული — **injection tokens** ის გამოყენებით. ეს საშუალებას გაძლევთ values inject გააკეთოთ, მოაწყოთ როგორ იქმნება instances, გაცვალოთ implementations, და inject გააკეთოთ non-class dependencies.

## ოთხი custom provider ტიპი

```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 — non-class dependencies-სთვის

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

ვინაიდან არ შეგიძლიათ interface ან plain value inject აკეთოთ type-ის მიხედვით (ისინი runtime-ზე არ არსებობს), თქვენ იყენებთ **token**-ს (სტრიქონი ან `Symbol`) `@Inject(token)` ის ერთად inject-ის გასაკეთებლად. ეს გამოიყენება configuration objects, third-party clients, ან interface-typed dependencies inject-ის გასაკეთებლად.

## useFactory — ყველაზე მძლავრი (dynamic, 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` აწყობს ფუნქციას (injected dependencies-თან) provider-ის შესაქმნელად — აუცილებელი connections, clients, ან ყველაფრისთვის, რომელიც საჭიროებს runtime configuration ან async setup.

## Implementations-ის გაცვლა (useClass) — flexibility & testing

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

ვინაიდან consumers დამოკიდებული არიან token-ზე (`PaymentService`), თქვენ შეგიძლიათ გაცვალოთ concrete class — real Stripe service production-ში, mock tests-ში — consuming code-ის დაცვლის გარეშე.

## რატომ მნიშვნელოვანია ეს

Custom providers და injection tokens ვრცელდება NestJS-ის dependency injection-ს მარტივი კლასების გარდა, უფლებას გაძლევთ მოქნილობას, რომელიც საჭიროა real-world applications-ებისთვის.

მათი გაგება მნიშვნელოვანია რამდენიმე საერთო scenario-სთვის: **non-class values inject გაკეთება** (configuration objects, constants) via `useValue` და string/Symbol tokens (ვინაიდან არ შეგიძლიათ interfaces ან plain values inject აკეთოთ type-ის მიხედვით); **dynamic/async provider creation** via `useFactory` (ყველაზე მძლავრი ფორმა — database connections, Redis clients, ან third-party SDK instances-ის შექმნა configured-ი runtime values-დან, თავიანთი injected dependencies-თან); და **implementations swap** via `useClass` token-ის მიღმა (environment-based implementations ის ხელმისაწვდომობა და, რეალურად, ადვილი **mocking tests-ში** — provide mock class token-ისთვის consumers-ის შეხების გარეშე).

ეს მოქნილობა არის ის, რაც NestJS-ის DI-ს მძლავრ აკეთებს production architecture-ისთვის და ფასდაბან testability-ის თვალსაზრისით.

ოთხი provider types (`useClass`, `useValue`, `useFactory`, `useExisting`) ის ცოდნა, როგორ მუშაობს injection tokens non-class dependencies-სთვის, და როდის სტანდარტებზე მიმართვა თითოეულისთვის არის მნიშვნელოვანი ნაბიჯი basic DI-ის გარდა — ეს არის როგორ wire up databases, external services, configuration, და swappable/mockable dependencies-ის idiom NestJS გზით, მისი ხელმისაწვდომობა frequently-needed, architecturally-significant topic-ი real applications-ებში.