Angular Interview Knowledge Hub

Angular is a TypeScript-first web application framework. It owns component rendering, template compilation, dependency injection, routing, forms, HTTP integration, build tooling, testing integration, and optional server rendering. That integrated platform reduces ecosystem assembly, but it also means architecture and upgrade choices should follow Angular's boundaries rather than treating it like a view-only library.

The entry file calls bootstrapApplication with a standalone root component and application providers. Angular creates the environment injector, initializes providers, instantiates the root component, creates its view, evaluates bindings, and attaches the rendered view to the host element. Ahead-of-time compilation has already turned templates into efficient instructions; the runtime connects those instructions to dependency injection, reactivity, events, and change detection.

Interpolation renders a string representation into text or an attribute context; property binding assigns an expression result to a DOM, directive, or component property; event binding sends an event back to component code. Two-way binding is syntax that combines an input and a corresponding change output. The important model is direction: state flows down through properties, and user intent flows up through events.

Use inputs for parent-owned data and outputs for child events. Lift state to the nearest common owner when siblings coordinate; use a scoped service when the state or workflow outlives one component tree; use the URL for navigable state. Avoid a global event bus as the default because it hides ownership and makes event order and cleanup difficult to reason about.

TypeScript gives Angular statically analyzable classes, generics, access modifiers, decorators, and tooling. Angular's compiler extends that value into templates with binding and expression type checks, but TypeScript types disappear at runtime, so interfaces cannot be DI tokens. Runtime behavior still depends on JavaScript values, Angular metadata, providers, and browser APIs.

A component is a directive with a template. Its metadata defines the selector, template, styles, imports, change-detection strategy, and host behavior; the class owns instance state and methods; Angular creates a host view and connects bindings to that instance. A good component also has a coherent responsibility and a deliberately small public API—not merely a @Component decorator.

input() declares a readonly Signal that Angular updates from the parent; output() declares a typed event channel; model() declares a writable signal exposed as an input plus a Change output for two-way binding. Prefer explicit input and output flows. Use model when the child is a true editor of a parent-owned value, not to hide ordinary state changes behind two-way syntax.

Content projection lets a component place markup supplied by its consumer into predefined ng-content slots. Angular determines the slot from selectors when it creates the view; the projected nodes remain conceptually owned by the declaring view even though they render inside the child. Use projection for layout and composition, but keep slot contracts small and avoid selectors that couple consumers to internal markup.

A view query reads elements, directives, or components created by the component's own template; a content query reads projected content supplied between the component's tags. Their results become available at different lifecycle boundaries because Angular initializes content before the component's view. Query only what the component must coordinate—exposing data through an input or output is often less coupled.

Use TemplateRef plus ViewContainerRef when a reusable template fragment should produce embedded views, and createComponent when the runtime must instantiate a real component type. Suitable cases include overlays, configurable dashboards, plugin surfaces, and schema-driven UI. The owner must also control injector scope, inputs, event subscriptions, placement, destruction, focus, and accessibility; dynamic creation is not a shortcut around normal composition.

A Signal is a synchronous getter backed by a reactive producer. While a computed value or template executes, Angular records which Signals were read; when one changes, Angular invalidates dependent computed values and marks affected views for a future render. Dependencies are dynamic and follow the branch actually read. Signals notify consumers—they do not deep-observe arbitrary object mutation.

computed expresses a value as a pure function of other Signals, caches it, and preserves one source of truth. An effect runs side-effecting code when dependencies change, so using it to copy one Signal into another creates scheduling, feedback-loop, and synchronization risks. Use effects at imperative boundaries such as logging, storage, a canvas, or a third-party API—and keep them small and cleanup-aware.

Signals model a current synchronous value and derived state with fine-grained dependency tracking. RxJS models events over time and has strong operators for cancellation, concurrency, buffering, retries, and combining asynchronous sources. Use Signals for local/view state and synchronous derivation; keep RxJS where time and stream semantics are the problem. A healthy Angular application can use both without mirroring every value in both systems.

When an OnPush template reads a Signal, Angular records the view as a consumer. Updating that Signal marks the dependent view so it is eligible for refresh on the next scheduled change-detection pass. OnPush still matters because it lets Angular skip clean subtrees; Signals improve the precision of notifications but do not make expensive templates or giant DOM trees free.

linkedSignal creates writable state whose default value follows reactive source state—for example, a selection that resets when the available options change. resource models async read state with a request, loader, status, value, error, cancellation, and reload semantics. They reduce synchronization effects, but ownership still matters: mutations and complex event workflows often belong in explicit services or RxJS pipelines.

toSignal subscribes to an Observable and exposes its latest value as a Signal; define an initial value or require a synchronous first emission when necessary, and create it in a stable owner rather than per template evaluation. toObservable exposes Signal changes as an Observable for stream composition. Convert at a boundary, not repeatedly throughout the graph, and keep error and completion semantics visible.

Angular renders through a tree of views. Framework notifications—such as a bound event, a new input, a template Signal update, or markForCheck—make relevant views eligible for refresh and schedule work. During change detection Angular traverses the required part of the view tree, reevaluates template bindings, compares results with stored values, and updates only changed DOM bindings. The scheduling source and the traversal strategy are separate concerns.

Default-strategy views are checked during ordinary application passes. An OnPush subtree can be skipped while it is clean and becomes eligible when it receives a changed input reference, handles a bound event, reads a Signal that changes, is explicitly marked, or is otherwise affected through Angular's view rules. Immutability makes input changes easy to detect, but Angular does not enforce immutable objects.

In current Angular, zoneless is the default. Angular schedules rendering from notifications it owns: template-read Signal updates, bound listeners, setInput, markForCheck, view attachment/removal, and related view operations. Zone.js-based applications instead use patched async activity as a broad scheduling signal. Zoneless reduces that global coupling, but application and library code must notify Angular through supported reactive or view APIs.

Legacy context: Zone.js-based applications remain common. Angular 21+ can opt back into zone-based scheduling with provideZoneChangeDetection.

markForCheck makes an OnPush view eligible for a future application pass. detectChanges synchronously checks the view and descendants now. detach removes a view from ordinary traversal until it is reattached or checked manually. These APIs are useful for specialized rendering loops and external integrations, but frequent manual calls can hide broken ownership or notifications; prove the need with profiling and test the lifecycle carefully.

In development mode Angular can verify that a binding did not change after it was already checked in the same render cycle. The error commonly exposes a child changing parent-visible state during view initialization, a getter with side effects, or DOM-derived state written too late. Fix the ownership or timing; setTimeout and unconditional detectChanges often silence the evidence while preserving a fragile feedback loop.

First verify what 'rerender' means: component checks, DOM mutations, or component recreation. Use Angular DevTools and browser performance traces, log identity-changing inputs and route reuse, and inspect bound events, Signal writes, AsyncPipe emissions, effects, and ChangeDetectorRef calls. Form one hypothesis, reproduce it with a minimal interaction, remove the trigger, and confirm both fewer checks and improved user-visible cost.

Angular DI maps a runtime token to a provider record. When code requests the token in an injection context, Angular searches the relevant element and environment injector hierarchy, creates the value from its provider factory if needed, caches it according to that injector's lifetime, and returns it. Provider placement therefore controls availability, instance count, lazy loading, cleanup, and architectural coupling.

A root provider is shared across the application environment; a route provider creates feature-scoped configuration and state; a component provider creates an instance for that component subtree. Resolution chooses the nearest matching provider, so lower providers shadow higher ones. Scope is a design decision: it controls sharing and isolation, but also memory, retained state, lazy-boundary behavior, and surprising duplicate instances.

useClass constructs a class for a token; useValue supplies an existing value; useFactory computes a value with dependencies; useExisting aliases one token to the exact same instance; multi collects contributions into an array. Prefer InjectionToken for non-class contracts. A common trap is using useClass when aliasing was intended, which creates a separate instance and splits state.

inject() needs an active injection context so Angular knows which injector hierarchy to search. That context exists during class field initialization and constructors created by DI, provider factories, route loaders, guards, and functions run with runInInjectionContext. It does not automatically exist later in any method or async callback; capture the dependency during construction or explicitly establish the correct context.

Search every provider declaration, including providedIn, application config, route providers, component providers, imported legacy modules, and test overrides. Identify the injection site and walk its element/environment injector chain. Add temporary instance IDs or creation traces and inspect Angular DevTools. Fix the provider boundary—not the symptom—then verify sharing, cleanup, lazy loading, and tests across navigation.

An Observable is a subscription contract and may be cold or hot. A Subject is both observer and Observable and multicasts new events to current subscribers. BehaviorSubject additionally requires and synchronously exposes a current value; ReplaySubject replays a configured history. Use the narrowest semantics needed, expose Observable rather than the writable Subject, and avoid using Subjects as a hidden application-wide event bus.

switchMap keeps only the newest inner stream and unsubscribes the previous one; mergeMap runs inners concurrently; concatMap queues them in order; exhaustMap ignores new sources while one inner is active. For typeahead use switchMap, independent saves may use bounded mergeMap, ordered writes may use concatMap, and double-submit prevention may use exhaustMap. The business rule chooses the operator.

Nested subscribe calls create independent lifecycles, making cancellation, error propagation, loading state, ordering, and cleanup harder to coordinate. Use flattening operators for dependent async work and combination operators for independent sources. A subscribe is appropriate at a true side-effect boundary, but the data-flow graph should normally be expressed before that boundary.

AsyncPipe subscribes to an Observable or Promise, returns the latest emitted value, and marks the view when a new value arrives. If the bound source identity changes it unsubscribes from the old source and subscribes to the new one; it also cleans up when the view is destroyed. Avoid creating a new cold Observable expression in the template on every check, because source replacement can repeat work.

Prefer AsyncPipe or toSignal for view consumption. For imperative subscriptions tied to an Angular owner, use takeUntilDestroyed with its DestroyRef. One-shot HttpClient streams complete, but router events, Subjects, intervals, DOM events, and long-lived stores do not. Cleanup is necessary but not sufficient: callbacks, effects, caches, and third-party listeners can retain the same component graph.

shareReplay can keep a source subscription or replayed value alive longer than intended, hide stale data behind a service lifetime, or restart work when refCount drops and later rises. The behavior depends on source completion and configuration. State the desired cache owner, invalidation, error reset, and subscriber lifecycle first; sometimes an explicit cache or share with reset options is clearer.

HttpClient Observables are cold, so each subscription starts a request. Look for multiple AsyncPipe uses, an imperative subscription plus a template subscription, repeated effect creation, nested subscriptions, retry/repeat, component recreation, and sharing that resets. Instrument subscription and network timing, prove the subscriber graph, then share or cache at the correct owner and verify invalidation—not just request count.

Define typed route records and provide them with provideRouter at application bootstrap. Router features such as preloading, component-input binding, scrolling, and tracing are added as provider features. Routed components render through outlets, while child routes create nested activation trees. NgModule routing remains relevant in legacy applications, but new feature boundaries do not require a routing module.

Use loadComponent for a standalone routed component and loadChildren for a lazy route tree. Put boundaries around meaningful user journeys so the initial route avoids unrelated code without creating request waterfalls at every nested level. Preload only likely next paths under suitable network and device conditions. Verify output chunks and navigation timing because an eager import elsewhere can pull a lazy feature into the initial graph.

Guards can redirect, prevent an unsuitable client navigation, or stop a route from matching; they are not a security boundary because users control browser code. Resolvers load data that must exist before activation, but overuse delays navigation and can hide loading UX. Backend authorization must validate every protected operation, and router failures should have explicit redirect or error behavior.

A navigation is a cancelable transaction: parse and recognize the URL, apply redirects, lazy-load route config, run guards and resolvers, build the target router state, deactivate/activate components, and commit history and scrolling behavior. Observe Router events to locate delay or cancellation, but avoid coupling product logic to a fragile event sequence when route state or a guard can express the requirement directly.

Template-driven forms suit small forms where the template naturally owns the workflow. Typed reactive forms remain a mature choice for explicit control trees, dynamic forms, and a large ControlValueAccessor ecosystem. Signal Forms, stable in Angular 22, make a Signal model the source of truth with type-safe field trees and schema validation. Choose per form and ecosystem; do not rewrite stable enterprise forms only to adopt a newer API.

Typed forms make the control tree and value shape visible to TypeScript, so setValue, patchValue, getRawValue, validators, and access patterns catch more mismatches. Nullability is deliberate because reset can produce null unless controls are non-nullable. Types do not validate runtime server data; domain parsing and validation still belong at trust boundaries.

A synchronous validator should be a pure function of current control state. Place a cross-field rule on the smallest group that owns all involved values. Async validators should debounce or avoid unnecessary requests, cancel stale work, and return structured errors; do not duplicate every server rule in the client. Error presentation should account for touched/submitted state and remain accessible.

ControlValueAccessor adapts a custom UI control to Angular's existing forms APIs. Angular writes model values through writeValue; the control reports user changes and touch through registered callbacks; setDisabledState mirrors disabled status. Keep writeValue free of change emission, preserve accessibility and focus behavior, and test model-to-view and view-to-model directions independently.

Start from a versioned domain schema rather than component conditionals. Partition the form into owned sections, create only relevant controls, use stable identity for repeated groups, centralize cross-section rules deliberately, and define draft and server-error semantics. Profile validation and rendering before adding manual change detection; virtualize or page very large repeated sections and test migrations between schema versions.

An attribute directive attaches behavior, bindings, or host interaction to an existing element or component. A structural directive controls embedded views through TemplateRef and ViewContainerRef. For normal conditionals and loops, use modern @if, @for, and @switch; write a custom structural directive only when reusable view-creation behavior adds a real domain abstraction.

Host directives let a component or directive apply another directive to its host at compile time and optionally expose selected inputs and outputs. They are useful for focus behavior, menus, selection, accessibility, and shared interaction policies. Keep composition shallow and explicit; a large invisible stack of host behavior can make provider resolution, host bindings, and event ownership hard to trace.

A pure pipe runs when its input value or reference changes, so it is efficient for deterministic display transformation but will not notice deep mutation behind a stable object reference. An impure pipe can run on every relevant check and can become extremely expensive. Prefer immutable inputs, computed state, or explicit async boundaries; use an impure pipe only for a measured case with bounded work.

Angular constructs the class, sets initial inputs, calls ngOnChanges, then ngOnInit, followed by content initialization/check hooks and view initialization/check hooks. Render callbacks run after rendering work, and destruction callbacks release owned resources. The exact list matters less than choosing the boundary whose prerequisites are actually ready and avoiding repeated work in the checked hooks.

The constructor establishes class invariants and receives dependencies; Angular inputs are not ready there. ngOnInit runs after initial inputs are set and is suitable for initialization that depends on them. Prefer field initialization and derived Signals for simple state, and avoid starting work in both places without a clear owner because tests and inheritance become harder to reason about.

afterNextRender schedules work after the next application render; afterEveryRender repeats after renders. They are appropriate for layout measurement or integration with imperative browser libraries when normal bindings cannot express the work. Register them in an injection context, separate write and read phases when possible, clean up owned resources, and remember render callbacks do not run during server rendering.

The creator of a long-lived resource should own its teardown. Use framework-managed lifetimes where possible, takeUntilDestroyed for subscriptions, and DestroyRef.onDestroy or ngOnDestroy for listeners, observers, timers, workers, and third-party instances. Also inspect services and caches: destroying a component does not free objects still retained by a root service, detached DOM, or a library callback.

Keep ephemeral interaction state in the component, lift shared view state to the nearest common owner, use a scoped service for a feature workflow, put navigable state in the URL, and treat backend data as server state with an explicit cache policy. Persist only what must survive reloads. Avoid copying one value into several stores; derived state should be computed from one authoritative source.

A global store becomes valuable when many distant features coordinate durable state, transitions need explicit events and effects, reproducible debugging matters, or policy must be standardized across teams. Component Signals and scoped services are simpler for local workflows. Evaluate ownership, event volume, server-cache needs, testability, and team fluency; application size alone is not the threshold.

Provide the store at the feature lifetime, keep writable Signals private, expose readonly Signals and computed derivations, and offer intention-revealing commands for transitions. Keep async work and error policy explicit rather than hiding them inside arbitrary effects. This is enough for many features; add a formal store when event history, cross-feature coordination, tooling, or standardized effects justify it.

Server state is owned remotely and the client holds a potentially stale snapshot; it needs request deduplication, freshness, invalidation, error, retry, and mutation reconciliation. Client state is authoritative in the browser, such as an open panel or unsaved draft. Conflating them produces stale caches and duplicated truth. Define keys, ownership, TTL or invalidation events, and optimistic rollback explicitly.

Normalize when the same entity appears in many collections, updates arrive independently, and one canonical record prevents inconsistent copies. Keep ordered IDs and derive view models with selectors or computed values. For route-local read models and small immutable responses, normalization can add indirection without value. The deciding forces are identity, update patterns, ownership, and debugging cost.

Define the failing user journey and metric—LCP, INP, navigation time, frame drops, memory, or bundle cost. Reproduce with representative data and device constraints, then use Angular DevTools, Chrome Performance/Memory/Network, source maps, and bundle analysis to locate time and retention. Change one proven constraint, compare the same workload, and verify the user metric rather than a proxy alone.

Profile whether the cost is creation, change detection, layout, paint, or repeated updates. Usually the redesign is to avoid rendering 10,000 interactive rows: virtualize, page, aggregate, or progressively disclose. Use stable track identity, OnPush/Signals, cheap templates, and batched updates. Verify frame time, memory, accessibility, keyboard behavior, and the actual user task with production-scale data.

Measure compressed and parsed cost by chunk, inspect source-map bundle output, and identify eager feature imports, heavy libraries, duplicated versions, locale/data payloads, CommonJS limits, and side-effectful packages. Create route and @defer boundaries, replace or narrowly import dependencies, and enforce budgets in CI. Verify cold-load LCP/INP and navigation waterfalls, not bundle bytes alone.

@defer lets the compiler split eligible standalone dependencies and load them on idle, viewport, interaction, timer, immediate, or a condition. Use it for expensive, non-critical regions with stable placeholders and deliberate prefetching. Do not defer above-the-fold essentials merely to improve a bundle report; account for layout shift, request waterfalls, error states, SSR, and incremental hydration behavior.

The track expression maps each item to stable logical identity. Angular uses it to match old and new collections, reuse views, move DOM, preserve focus and component state, and create or destroy only real additions/removals. Track a unique domain key; index is safe only for truly static order, and returning a new object defeats stable matching.

Angular may evaluate template expressions whenever the view is checked, so a method or getter that filters, sorts, allocates, parses, or triggers side effects can repeat frequently. Cheap pure accessors are fine. Move substantial derivation into computed Signals, pure pipes, memoized selectors, or preprocessing at the data boundary, and verify with a profile rather than banning every method syntactically.

Use client rendering for authenticated, highly interactive surfaces where server HTML adds little. Use SSR when first-response content must be fresh or request-specific and early HTML improves the journey. Prerender stable, cacheable routes at build time. Modern Angular supports hybrid choices per route; include CDN caching, backend latency, hydration cost, failure modes, and operational capacity in the decision.

Hydration matches the client view structure to server-rendered DOM, reuses those nodes, restores Angular listeners and state, and can replay early events. It improves continuity and avoids a destructive rerender, but requires valid, deterministic HTML and careful browser-only code. Hydration does not remove the cost of downloading and executing the client application.

Incremental hydration lets the server render the main content of a @defer block while the browser leaves that subtree dehydrated until a hydrate trigger fires. Angular then loads its dependencies, hydrates the boundary, and replays captured events. It can reduce initial JavaScript without above-the-fold layout replacement, but nested boundaries, trigger choice, and interaction readiness must be designed and measured.

Capture the server HTML and the DOM before Angular hydrates, then compare the failing subtree. Check invalid table/nesting markup, direct DOM manipulation, random/time/locale output, request-specific state not transferred, browser-only branches, whitespace configuration, and third-party scripts that mutate early. Fix determinism and ownership; use skip hydration only as a narrow temporary boundary.

A refresh executes the server render while client navigation may not. Inspect the server stack and route render mode, then find top-level or lifecycle access to window, document, storage, layout, and DOM libraries. Check request-specific authentication, environment configuration, absolute URLs, ESM compatibility, and transferred data. Add a server-render test for the route and verify both direct and client navigation.

Unit-test domain transformations and failure rules; component-test public inputs, outputs, accessibility, and rendered behavior; integration-test routing, forms, HTTP adapters, and state boundaries; browser-test a small set of critical journeys. Avoid tests that only restate Angular or assert private method calls and DOM structure with no product meaning. Optimize for fault detection and refactor confidence.

New Angular CLI projects use Vitest with a DOM emulation environment by default, and ng test integrates the runner. Karma is still supported and common in mature applications. TestBed remains Angular's component and DI test utility regardless of runner. Use real-browser mode or E2E tests for layout and browser APIs that a simulated DOM cannot validate.

Legacy context: Karma remains supported and is common in existing projects; migrate because it improves the workflow, not merely to follow a default.

Update state through the same input, event, or Signal API production uses, await fixture.whenStable when rendering is scheduled, and assert visible behavior. A blanket fixture.detectChanges can hide code that fails to notify Angular in zoneless production. Test computed values as pure derivations where useful, and test effects through the external boundary they synchronize—not their implementation details.

Use the HTTP testing provider and controller to assert request shape and drive response/error timing; use RouterTestingHarness to navigate real route configuration and inspect activated UI; exercise forms through controls and user-facing behavior. Mock the external boundary, not every collaborator. Keep a smaller browser suite for focus, native validation, history, and cross-page behavior.

Angular escapes interpolation and sanitizes untrusted values in security-sensitive binding contexts such as HTML and URLs. Templates themselves are trusted executable code and must never be assembled from user input. DomSanitizer bypass methods assert that a value is already safe—they do not sanitize it. Prefer structured rendering, server validation, CSP, and Trusted Types over bypasses.

JavaScript-readable storage makes tokens available to any successful XSS. HttpOnly, Secure, SameSite cookies reduce token theft but require a CSRF strategy and careful domain/session design. Short-lived in-memory access tokens plus protected refresh mechanisms are another pattern. The backend must validate every token and authorization decision; Angular interceptors are convenience, not enforcement.

Users can modify browser code, call APIs directly, and bypass a client route entirely. A guard improves navigation UX and can avoid rendering an inappropriate screen, but it cannot protect data or operations. The server must authenticate the caller and authorize every request against current policy, regardless of which Angular route was visible.

A strong CSP and Trusted Types policy reduce the paths by which injected text becomes executable, but they require compatible build and runtime behavior. Every third-party script runs with page privileges and can affect performance, privacy, hydration, and token exposure. Inventory, pin, review, sandbox where possible, load only with justified consent, monitor changes, and keep a removal path.

Align deployable applications and libraries to business domains with named owners and enforced dependency direction. Standardize the paved road—Angular version, build, testing, observability, security, design-system primitives, and API clients—while letting teams own domain decisions. Use automated boundaries and compatibility tests, not review committees. Measure lead time, upgrade adoption, incidents, bundle budgets, and cross-team dependency wait time.

Build a platform when many teams repeatedly solve the same build, auth, observability, testing, deployment, accessibility, and upgrade problems and inconsistency creates measurable risk. Treat it as a product: paved-road defaults, escape hatches, versioned contracts, migrations, documentation, telemetry, and support. Do not centralize domain state or every component; platform success is reduced cognitive load and faster safe delivery, not control.

Define the supported public API, accessibility behavior, tokens, visual regression contract, and browser/Angular range. Prefer composable primitives over domain-specific mega-components. Deprecate with telemetry and time, ship schematics or codemods, test representative consumers, canary releases, and support parallel versions when necessary. A platform team owns migration ergonomics, not only package publication.

Micro-frontends are justified when domains need genuinely independent release and ownership boundaries that a modular monolith cannot provide. Costs include duplicate framework/runtime code, shared dependency negotiation, routing, authentication, cross-app state, design consistency, observability, accessibility, and failure isolation. Start with repository and module boundaries; adopt runtime composition only with measurable autonomy requirements and a platform that owns the seams.

Define representative devices, networks, and critical journeys, then set field-oriented LCP, INP, CLS, error, and navigation targets plus build-time JavaScript/CSS/image budgets. Enforce regression checks in CI and monitor real-user percentiles by application and route. Assign owners, publish trend dashboards, and use time-bounded exceptions with remediation—not one universal byte limit detached from product context.

Inventory module roles first: declarations, provider scope, routing, initialization, and library compatibility. Run Angular's standalone migrations in small steps, convert leaf components and lazy routes, move providers deliberately, and use importProvidersFrom as a temporary bridge. Keep builds and behavior tests green, compare bundles and DI lifetimes, and remove obsolete modules only after consumers have moved.

Legacy context: NgModules remain valid and interview-relevant in maintained applications; standalone is the recommended direction for new Angular code.

Start with local UI state and pure derived view models where Signals remove manual Subjects and subscriptions. Keep RxJS for cancellation, concurrency, WebSockets, and multi-event workflows; bridge once at feature boundaries with toSignal or toObservable. Define ownership and migration conventions, add zoneless compatibility tests, measure bundle/runtime effects, and avoid mirroring every store selector into a second Signal store.

Map Angular, TypeScript, Node, RxJS, builder, test-runner, and library compatibility first. Upgrade one major at a time with ng update, commit automated migrations separately, replace abandoned blockers, and run unit, integration, SSR, visual, performance, and production smoke tests at each step. Release intermediate states when possible, monitor canaries, and avoid combining framework, state, design-system, and domain rewrites into one change.

First reach a supported Angular/Node/TypeScript baseline and eliminate custom webpack assumptions or abandoned test utilities that block upgrades. Move to the stable application builder and its esbuild/Vite-based toolchain, then evaluate Vitest migration for test speed and maintenance. Preserve production output, SSR behavior, source maps, coverage meaning, and browser-level tests; tooling change is successful only if delivery gets faster without losing confidence.

Automate a navigation loop, force comparable garbage-collection conditions, and verify the retained heap grows after components should be destroyed. Compare heap snapshots and dominator/retainer paths for component instances, detached DOM, subscriptions, listeners, timers, overlays, caches, and third-party objects. Fix the retaining owner, repeat the same loop, and verify both heap stabilization and correct feature behavior.

Protect the backend with rollback, flags, or rate limits if needed, then capture Network initiators and application traces. Count component creation, Observable subscriptions, Signal effect creation, AsyncPipe consumers, retry loops, router reactivation, and polling timers. Build the exact fan-out graph, remove or share at the owning boundary, define invalidation, and verify request cardinality across navigation and error paths.

Record a controlled long-running session and trend heap after GC, DOM node count, listeners, timers, subscriptions, Signal/effect activity, cache sizes, network frequency, long tasks, and frame time. Compare idle and active periods and take heap/CPU profiles early and late. Find the accumulating owner or increasing work rate, mitigate safely, and verify a soak test under production-like data.

Confirm the browser received the fresh payload, then trace HTTP/service-worker/CDN caches, shareReplay or resource lifetime, store selectors, optimistic state, mutation behind stable references, Signal equality, route reuse, and template pipes. Instrument version/timestamp at each boundary to locate where the value diverges. Fix ownership or invalidation and verify reload, navigation, offline, and concurrent-mutation paths.

Verify the chunk with source-map/bundle analysis, then trace every import of its entry component, route tree, shared barrel, provider, constant, stylesheet, and query. A static import anywhere reachable from the initial graph defeats the lazy boundary; @defer dependencies also must meet eligibility rules. Remove the eager edge, rebuild, and test both cold-load bytes and first navigation behavior.