Angular interview questions

A route guard implemented as a CanActivateFn runs before the router activates the route. If it returns an Observable that resolves to false (or a UrlTree redirect), navigation is blocked and no AdminModule component is created until the license check passes, while the lazy chunk stays lazy for the rest of the app. Calling the API in the module constructor does not block anything, so components would still render. Loading the module eagerly defeats lazy loading and checks the license globally rather than on admin navigation. A spinner inside AdminComponent means the component has already rendered before the check finishes, which violates the requirement.

Angular's Router matches routes in array order, and the literal ** path matches any URL segment sequence. Listing it last guarantees that only URLs unmatched by earlier routes fall through to it. Placing it earlier would shadow every subsequent route.

The component property on a Route tells the Router which component to instantiate and insert into the <router-outlet> when the route's path matches the URL. redirectTo sends the user to a different path instead of rendering a component, loadChildren lazy-loads a set of child routes, and canActivate is a guard that decides whether navigation may proceed, so none of them names the component to render.

The route property that triggers lazy loading of a child module is loadChildren, which takes a function returning a dynamic import. The .then() callback receives the module namespace object and returns the named export AdminModule, which is the NgModule class to load. Angular's build tooling splits the imported file into a separate bundle that is fetched only when the admin route is first navigated to. The component property is a static reference and loadComponent lazy-loads a single standalone component, so neither fits a module-based lazy load.

With the default NoPreloading strategy, Angular does not fetch lazy-loaded bundles at startup. The dynamic import() in loadChildren or loadComponent is only evaluated when the router matches a navigation to that route for the first time, which causes the browser to request the separate chunk on demand. Later navigations to the same route reuse the already-loaded chunk.

When Angular lazy-loads a module referenced by loadChildren, it creates a child injector for that module. Any provider in the lazy module's providers array, including a bare @Injectable() FeatureService with no providedIn, is registered in that child injector rather than the root injector, so only components in or below FeatureModule can inject it. The claim that it is merged app-wide is false because lazy providers are not merged into the root. The claim that RouterModule.forChild() is required is false because forChild() only registers route configuration, not DI providers. The tree-shaking claim is false because an explicit entry in a providers array keeps the class in the bundle; tree-shaking concerns providedIn: 'root' or 'any' services that nothing references.

The router treats each resolver's return value as a data source it must wait on. For an Observable, it takes the first emitted value (similar to first() or take(1)) and tears down the subscription, so the stream does not need to complete; an infinite Observable works. When a route has several resolvers, they are invoked together and combined with forkJoin-style semantics, so they run in parallel and the route activates only once all of them have produced a value. Returning null is a valid resolved value: it is stored in ActivatedRoute.data and navigation proceeds normally. A plain synchronous value is also accepted, because the router wraps non-Observable results before using them. Resolvers run after the guards, not before, so the statement about guards reading resolved data is backwards.

The admin and dashboard bundles are preloaded; the reports bundle is not. canLoad guards exist specifically to gate whether a lazy route's code bundle is downloaded. The RouterPreloader evaluates canLoad guards before preloading and skips routes where they return false — so reports (whose reportsGuard returns false for non-admins) is excluded from preloading. canMatch guards, by contrast, run after the route's module or component is already loaded; they only determine whether the route matches the current URL segment and do not gate the bundle download or preloading decision. Therefore, the admin route (guarded only by canMatch) is still preloaded even though adminGuard returns false, the unguarded dashboard route is always preloaded by PreloadAllStrategy, and only the reports route (guarded by canLoad returning false) is withheld. This distinction is the core reason Angular 15+ deprecated canLoad in favor of canMatch: canMatch provides no 'code protection' guarantee — the bundle is always fetched — whereas canLoad prevents unauthorized users from downloading protected code.

The Router builds the activated route chain from the matched route tree, a → b → c, and that chain includes componentless routes, which exist only to group children. During activation, the Router checks canActivate for each route in the chain that is newly activated (not reused from a previous navigation with the same route config). Since none of a, b, or c was active before this navigation, all three guards run, so the statement is true. The presence or absence of a component affects only what is rendered in a router-outlet, not whether the guard is invoked.

Angular's router takes only the first value emitted by a resolver's Observable (it applies first() internally) and then unsubscribes, so the never-completing stream does not block navigation. timer(0, 100) emits 0 at t = 0 ms, and the map((n) => n + 1) operator turns that into 1. The router stores 1 as the count data, so route.snapshot.data['count'] is 1 when ngOnInit runs, and the later emissions 2, 3, … are discarded.