Kas yra dinaminiai moduliai ir forRoot/forFeature šablonas?

Question

Accepted Answer

**Dinaminiai moduliai** yra moduliai, kurie gali būti **konfigūruojami jų importavimo metu** — vietoje statinio `@Module({...})`, jie turi statinius metodus (tradiciškai **`forRoot`** ir **`forFeature`**), kurie grąžina modulį, sukonfigūruotą su jūsų perduotais argumentais. Taip konfigūruojami, pakartotinai naudojami moduliai (config, duomenų bazė, JWT) priima parinktis.

## Problema, kurią jie sprendžia

```text
A static module is fixed — but reusable modules (DatabaseModule, ConfigModule,
JwtModule) need to be CONFIGURED per app (connection URL, secret, options).
Dynamic modules let a module accept configuration at import time.
```

## Jūs jau juos naudojate

```ts
@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),               // ← forRoot with options
    TypeOrmModule.forRoot({ type: "postgres", url: ... }),  // ← configured at import
    JwtModule.register({ secret: process.env.SECRET }),      // ← register variant
    TypeOrmModule.forFeature([User, Post]),                  // ← forFeature for specifics
  ],
})
export class AppModule {}
```

`.forRoot()`/`.register()`/`.forFeature()` iškvietimai, kuriuos matote importuojant modulius, yra dinaminių modulių metodai, priimantys konfigūraciją.

## forRoot vs forFeature konvencija

```text
forRoot()    → configure the module ONCE, globally (the connection, the secret, core setup)
               called in the root/app module a single time
forFeature() → register feature-specific pieces in each feature module that needs them
               (e.g. TypeOrmModule.forFeature([User]) registers entities per module)
```

Konvencija: `forRoot` dėl globalios/vienakartinės konfigūracijos; `forFeature` dėl kiekvieno funkcionalumo registracijos, kurią iškviečiate keliuose moduliuose.

## Savo dinaminio modulio kūrimas

```ts
@Module({})
export class StorageModule {
  static forRoot(options: StorageOptions): DynamicModule {
    return {                                  // returns a configured module
      module: StorageModule,
      providers: [
        { provide: "STORAGE_OPTIONS", useValue: options },   // inject the passed options
        StorageService,
      ],
      exports: [StorageService],
      global: true,                            // optionally make it global
    };
  }
}
// usage: StorageModule.forRoot({ bucket: "my-bucket", region: "us-east-1" })
```

Statinis metodas grąžina `DynamicModule` objektą (modulis + teikėjai + eksportai), sujungdamas perduotas parinktis į modulio teikėjus (dažnai per injekavimo žetoną).

## Asinchroninė konfigūracija (forRootAsync)

```ts
// configure using OTHER injected dependencies (e.g. ConfigService) — async/factory
StorageModule.forRootAsync({
  useFactory: (config: ConfigService) => ({ bucket: config.get("BUCKET") }),
  inject: [ConfigService],
});
```

`forRootAsync` variantas leidžia konfigūracijai priklausyti nuo kitų teikėjų (pvz., `ConfigService`) — iš esmės reikalingas, kai parinktys gaunamos iš patvirtintos konfigūracijos.

## Kodėl tai svarbu

Dinaminiai moduliai ir `forRoot`/`forFeature` šablonas yra svarbi NestJS koncepcija **konfigūruojamiems, pakartotinai naudojamiems moduliams** kurti — ir jų supratimas yra brangus tiek *naudojant* ekosistemą, tiek *kuriant* bendrintus modulius.

Beveik kiekvienas pagrindinis NestJS modulis (ConfigModule, TypeOrmModule, JwtModule, BullModule, CacheModule) yra dinaminis modulis, konfigūruojamas per `.forRoot()`/`.register()`/`.forFeature()`, todėl suvokimas, ką šie iškvietimai daro (konfigūracijos perdavimas moduliui importavimo metu, o ne statinis importas), paaiškina, kaip visa ekosistema yra sujungta.

**forRoot vs forFeature konvencija** (forRoot vienkartinei globaliai sąrankai, kaip duomenų bazės ryšys ar slaptas kodas; forFeature kiekvieno funkcionalumo registracijai, kaip objektų registracija kiekviename modulyje) yra šablonas, su kuriuo susidursite nuolat.

Senioriniam lygio kuriams žinios apie tai, kaip **kurti savo dinaminius modulius** (grąžinant `DynamicModule` su teikėjais, sukonfigūruotais iš perduotų parinkčių, dažnai per injekavimo žetonus, su asinchroniniais variantais config-priklausomai sąrangai), yra tai, kas jums leidžia kurti pakartotinai naudojamus, konfigūruojamus modulius — bendrą infrastruktūrą (saugojimas, išorės API klientai, pasirinktinė konfigūracija), kurią kitos programos dalys ar kiti projektai importuoja su savomis nustatyomis.

Tai yra sudėtingesnis klausimas, tačiau jis yra esminis suprantant NestJS modulinę architektūrą giliai ir kuriant profesionalias, pakartotinai naudojamas modulio bibliotekas, todėl tai yra svarbi galimybė architektūrizuojant dideles, gerai struktūrizuotas NestJS sistemas.