On-Demand Route Chunks

## Eager versus lazy in the route table A route with `component: ReportsPage` references the class directly, so the build includes it in the same JavaScript bundle as the routes file; for the root routes that is the **initial bundle** every user downloads. Angular's router offers two properties that instead take a **loader function** returning a `Promise` (or an `Observable`) of what to load: | Property | Loads | Typical file | When it downloads during a navigation | |---|---|---|---| | `loadComponent` | one **standalone** component | `reports-page.ts` | after guards and resolvers, just before activation | | `loadChildren` | a child route configuration (`Routes`), or an NgModule in older code | `reports.routes.ts` | during route matching, because the router needs the child routes to match the rest of the URL | The loader usually wraps a dynamic `import()`. Because the path in `import()` is a literal, the build tool can see it and put the target file, and anything only it imports, into a separate **lazy chunk**. ## `loadComponent` ```ts { path: 'reports', loadComponent: () => import('./reports/reports-page').then((m) => m.ReportsPage) } ``` The loaded class must be a standalone component. In development mode the router throws if it gets an NgModule (the message tells you to use `loadChildren` instead) or a non-standalone component. Since v19, components are standalone by default, so a new component needs no extra flag. ## `loadChildren` with a routes file ```ts // app.routes.ts { path: 'reports', loadChildren: () => import('./reports/reports.routes').then((m) => m.REPORTS_ROUTES) } // reports/reports.routes.ts export const REPORTS_ROUTES: Routes = [ { path: '', component: ReportsHome }, { path: ':id', component: ReportDetail }, ]; ``` The whole reports area, its child routes and the components they reference directly, becomes one lazy chunk, loaded the first time a URL under `/reports` is matched. A lazily loaded `Routes` array must use standalone components. Older applications return an NgModule class instead (`then((m) => m.ReportsModule)`); the router compiles it and uses the module's own injector for the children. That form still works but is not what new code uses. ## What a default export changes If the lazy file declares `export default class ReportsPage` or `export default [...] as Routes`, the `.then(...)` step can be dropped: ```ts { path: 'reports', loadComponent: () => import('./reports/reports-page') }, { path: 'admin', loadChildren: () => import('./admin/admin.routes') }, ``` The router detects a module object with a `default` property and unwraps it (the `DefaultExport<T>` type in the route typings allows this). It changes only the syntax: the chunk and the loading behaviour are the same. Some teams prefer named exports for grep-ability and consistent imports; both are valid. ## Details interviewers follow up on - **The loader runs in an injection context**, the route's environment injector, so it can call `inject()`; a loader can, for example, pick between two component files based on an injected feature-flag service. - **A route may have both** `loadComponent` (its own layout component) and `loadChildren` (its children). - **The loaded result is cached on the route**: later navigations reuse it without calling the loader again. If the download fails, nothing is cached and the next navigation tries again. - **The lazy path must not also be imported statically** from eager code, or the build has to include it in the eager bundle and the split is lost. ## What the user sees while a chunk downloads A lazy route does not render a fallback on its own. While the chunk is in flight, the navigation is still pending, so the previous page stays on screen; the new component appears only once the chunk has arrived and been evaluated. If the download fails, for example because the network dropped, the navigation fails with a `NavigationError` and the user stays where they were; nothing is cached, so clicking again retries the load. That is why apps with slow networks often add a global progress indicator for pending navigations, or preload the chunks users are likely to need next. ## Choosing between them 1. One screen with no child routes: `loadComponent`. 2. A feature area with several routes, shared route-level providers or its own guards: `loadChildren` pointing at a routes file. 3. The landing page and anything on the first screen: usually eager, because making it lazy only adds a round trip before first render.