In Angular, what does a route's providers array create, which code can inject from it, and how long do those instances live?

## What the router builds A route definition can carry its own `providers` array. When the router first needs that route, it calls `createEnvironmentInjector(route.providers, parentInjector)` and stores the result on the route. So each route with providers gets its own **`EnvironmentInjector`**, a node in the same tree as the root injector, sitting between the parent route's injector (or the root) and everything below it. ```ts { path: 'reports', providers: [ReportsStore, { provide: REPORTS_PAGE_SIZE, useValue: 50 }], loadChildren: () => import('./reports/reports.routes'), } ``` The array accepts both ordinary providers and `EnvironmentProviders` (the result of `provideX()` functions), which is how a feature area can call something like `provideHttpClient(withInterceptors([...]))` for just its own routes. ## Who can inject from it - components activated by this route and by its child routes, and their descendants; - the route's and its children's **guards** and **resolvers**, which run in the route's injection context; - the `loadComponent` and `loadChildren` functions of the route and its descendants, which also run in that context; - services created from this injector. Code outside the subtree, such as the root `App` component or a sibling `/settings` route, cannot see these providers; it resolves from root. ## When it is created | Moment | What happens | |---|---| | first navigation that matches the route | the router creates the injector while recognising the URL | | preloading pass that reaches the route | the preloader creates the injector so the loaders can run in it | | later visits | the stored injector is reused | This ties provider creation to the route, not to application start. A service whose class is referenced only from a lazily loaded routes file ends up in that lazy chunk, which is one reason route providers pair naturally with `loadChildren`. ## How long the instances live The default surprises people: leaving `/reports` does **not** destroy the route's injector. The `ReportsStore` instance and its state survive, and returning to `/reports` gets the same instance. That is often desired (a cache that outlives the page), but it also means subscriptions or timers started by those services keep running. Angular 22.2 made **`withAutoCleanupInjectors()`** stable (it replaces the deprecated `withExperimentalAutoCleanupInjectors()`). With it, after navigations the router destroys the environment injectors of routes that are no longer active, as long as the `RouteReuseStrategy` agrees via `shouldDestroyInjector(route)`; the built-in strategy's implementation returns `true`. Destroying the injector runs `ngOnDestroy` on its services and `DestroyRef` callbacks registered in it. Routes kept alive by a custom reuse strategy are not destroyed if the strategy reports their stored handles. ## Providers for a lazily loaded area A lazily loaded `Routes` array does not get an injector of its own; only a lazily loaded NgModule did. To scope services to a whole lazy area, either put `providers` on the parent route that has the `loadChildren` (as above), or wrap the lazy file's routes in a componentless parent: ```ts // reports.routes.ts export default [ { path: '', providers: [ReportsStore], children: [ { path: '', component: ReportsHome }, { path: ':id', component: ReportDetail }, ] }, ] satisfies Routes; ``` The second form keeps the providers next to the code that uses them, so the whole scope lives in the lazy chunk and the app routes file does not need to import `ReportsStore`. ## Contrast with older patterns 1. **NgModule `loadChildren`**: a lazily loaded NgModule got its own module injector; route `providers` are the standalone replacement and do not need a module. 2. **Component `providers`**: a service listed on a component gets a fresh instance per component instance, living exactly as long as that component, in the element injector tree. Route providers instead give one instance for the whole route subtree and live in the environment injector tree. 3. **`providedIn: 'root'`**: one app-wide instance. Providing the same class on a route as well creates a second, route-scoped instance that shadows the root one for that subtree, a common source of "why do I have two stores" bugs.