Dynamic Modules — Series 3

Preview — 3 of 10 questions

What does global: true on the returned object do?

javascript

static forRoot(options: CacheOptions): DynamicModule {
  return {
    module: CacheModule,
    global: true,
    providers: [{ provide: CACHE_OPTIONS, useValue: options }, CacheService],
    exports: [CacheService],
  };
}

AIt caches the module so repeated forRoot() calls return the same instance

BIt makes this registration's exports visible application-wide without importing the module elsewhere — the dynamic equivalent of the @Global() decorator, expressed per call so the same module can be global in one application and scoped in another

CIt forces every provider in the module to Scope.DEFAULT

DIt registers the module before all others, guaranteeing it initialises first

What does extending ConfigurableModuleClass provide?

javascript

export const { ConfigurableModuleClass, MODULE_OPTIONS_TOKEN } =
  new ConfigurableModuleBuilder<StorageOptions>().build();

@Module({ providers: [StorageService], exports: [StorageService] })
export class StorageModule extends ConfigurableModuleClass {}

AA @Global() registration and an options validation step

BA lifecycle hook that re-reads the options when they change

CA base class implementing OnModuleInit for the options provider

DReady-made register/registerAsync (or forRoot/forRootAsync) static methods, plus a provider bound to MODULE_OPTIONS_TOKEN — so the boilerplate of accepting options synchronously and asynchronously is generated rather than hand-written

What distinguishes an extra from an ordinary option?

javascript

const { ConfigurableModuleClass, MODULE_OPTIONS_TOKEN } =
  new ConfigurableModuleBuilder<StorageOptions>()
    .setExtras({ isGlobal: false }, (definition, extras) => ({
      ...definition,
      global: extras.isGlobal,
    }))
    .build();

StorageModule.register({ bucket: 'uploads', isGlobal: true });

AExtras configure the module definition rather than the service: isGlobal changes how the module is registered and is stripped before the rest reaches MODULE_OPTIONS_TOKEN, so StorageService never sees a field that means nothing to it

BExtras are optional while ordinary options are required

CExtras are resolved asynchronously and ordinary options synchronously

DExtras are merged into every provider's constructor arguments

Answer all 10 questions (7 more), see explanations for every answer, and track your score.