DI Container Internals

Preview — 3 of 10 questions

Within the Nest container, what does an InstanceWrapper hold for a scoped provider?

javascript

// Conceptual shape of an InstanceWrapper:
// {
//   name, metatype, scope, host,
//   instance,                       // DEFAULT scope
//   getInstanceByContextId(ctxId),  // scoped lookup
//   isResolved, isAlias, inject
// }

AA single resolved instance shared by everyone

BThe compiled JavaScript of the provider

COnly the provider's source file path

DMetadata (token, metatype, scope, dependencies) plus a per-ContextId map of resolved instances, so scoped instances are looked up by context

Which statement most accurately contrasts Nests DI with Angulars?

javascript

// Nest: module-scoped, server scopes
@Injectable({ scope: Scope.REQUEST })
export class RequestScoped {}
// Angular analog (providedIn / component providers) targets the view tree,
// which has no REQUEST-per-HTTP concept.

AThey are identical; Nest reuses Angular's injector at runtime

BNest cannot do hierarchical injection at all

CAngular has no concept of tokens; Nest does

DBoth use decorator + reflect-metadata-based DI, but Nest's injectors are organized around backend modules with strict encapsulation and server-side scopes (REQUEST/TRANSIENT), while Angular's hierarchical injectors map to component/element trees with providedIn

What is the correct way to build a single custom decorator that applies several existing decorators at once?

javascript

import { applyDecorators, UseGuards, SetMetadata } from '@nestjs/common';

export function Auth(...roles: string[]) {
  return applyDecorators(
    SetMetadata('roles', roles),
    UseGuards(AuthGuard, RolesGuard),
  );
}
// Usage: @Auth('admin')

ACall each decorator manually at every usage site

BConcatenate their strings

CUse applyDecorators(...) from @nestjs/common to compose them into one reusable decorator

DIt is impossible to compose decorators

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