Hierarchical Injectors — Series 3

Preview — 3 of 10 questions

Does this token need a separate entry in any providers array to be injectable?

javascript

export const RETRY_COUNT = new InjectionToken<number>('retry count', {
  providedIn: 'root',
  factory: () => 3,
});

ANo — passing providedIn and factory directly in the InjectionToken constructor makes the token self-sufficient, exactly like @Injectable({ providedIn: 'root' }) does for a class. inject(RETRY_COUNT) works anywhere in the app with no extra registration, returning 3 (or whatever the app overrides it with)

BYes — factory only documents the default value; a real providers entry is still required

CThis syntax is only valid for tokens typed as objects, not primitives like number

DprovidedIn: 'root' on a token, unlike on a class, requires also passing useValue

A component rendered by that lazy route injects VALIDATORS. What does it get?

javascript

// root providers
{ provide: VALIDATORS, useValue: requiredValidator, multi: true }

// a lazy route's own providers
{ provide: VALIDATORS, useValue: emailValidator, multi: true }

AOnly emailValidator — the route's own provider always shadows the root one, multi or not

BOnly requiredValidator — child injectors can't add to a multi-provided token, only override it

CAn array containing both requiredValidator and emailValidator — unlike a normal (non-multi) provider, where the closest injector's value simply replaces anything from an ancestor, a multi: true token accumulates every registration contributed by every injector in the hierarchy into one combined array

DAn error, because the same token can't be registered as multi: true at two different injector levels

Both return promises that take a few seconds. Does the app wait for firstPromise to resolve before starting secondPromise?

javascript

provideAppInitializer(() => firstPromise()),
provideAppInitializer(() => secondPromise()),

ANo — all registered initializers start running in parallel, and Angular's bootstrap process waits for all of them to resolve (via something like Promise.all) before continuing to render the application; if either one is slow, the whole app's startup is delayed by whichever takes longest, not by their sum

BYes — initializers always run sequentially, in registration order, each waiting for the previous one to finish

CNo — only the first-registered initializer's promise is actually awaited; the rest are fire-and-forget

DIt depends on whether they're registered via provideAppInitializer or the older APP_INITIALIZER token

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