DI Internals — Series 2

Preview — 3 of 10 questions

A root-provided SessionStore holds the signed-in user. On the server, what goes wrong?

javascript

// module scope — shared by every request the process serves
let cachedUser: User | null = null;

@Injectable({ providedIn: 'root' })
export class SessionStore {
  user = signal<User | null>(cachedUser);   // 💥 cross-request bleed
}

ANothing: providedIn: 'root' is per request by construction

BThe store is serialised into the HTML automatically

CRoot services cannot be used during SSR at all

DIt depends on whether the injector is created per request. Angular creates a fresh application injector for each server render, so root services are per request — but any state parked in a module-level variable is shared across requests, and that is where one user's data reaches another

What does injecting it give you, and where is it null?

javascript

private req = inject(REQUEST, { optional: true });

AThe incoming server request during SSR — headers, URL, cookies — and null in the browser, which is why the injection is optional

BThe Angular HttpRequest currently in flight

CA signal that updates on every navigation

DThe Express Request object, available on both platforms

What does the compiler emit for @Injectable({ providedIn: 'root' })?

javascript

HeroService.ɵprov = ɵɵdefineInjectable({
  token: HeroService,
  factory: () => new HeroService(ɵɵinject(HttpClient)),
  providedIn: 'root',
});

AAn entry appended to the root module's providers array at build time

BA static ɵprov property on the class — created by ɵɵdefineInjectable — carrying the token, the scope and a factory. The injector reads it when it first sees the token

CA runtime registry keyed by class name

DA decorator evaluated at bootstrap, which is why order matters

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