For a new Angular 22 app with routing, an HttpClient auth interceptor and SSR hydration, what goes into app.config.ts, and why?

## The scenario A new Angular 22 app needs three things wired at the application level: **routing**, **HttpClient** with an auth interceptor, and **client hydration** because the pages are server-rendered. In a standalone app all three are provider functions listed in `app.config.ts`: ```ts import { ApplicationConfig, provideBrowserGlobalErrorListeners } from '@angular/core'; import { provideRouter } from '@angular/router'; import { provideHttpClient, withInterceptors } from '@angular/common/http'; import { provideClientHydration, withEventReplay } from '@angular/platform-browser'; import { routes } from './app.routes'; import { authInterceptor } from './core/auth.interceptor'; export const appConfig: ApplicationConfig = { providers: [ provideBrowserGlobalErrorListeners(), provideRouter(routes), provideHttpClient(withInterceptors([authInterceptor])), provideClientHydration(withEventReplay()), ], }; ``` ## Line by line - **`provideBrowserGlobalErrorListeners()`** — generated by the CLI in every new project's config; it routes uncaught browser errors to Angular's `ErrorHandler`. - **`provideRouter(routes)`** — registers the `Router` and its services with the route table. Optional behaviour is added with `withX()` feature functions as extra arguments, for example `withComponentInputBinding()`. - **`provideHttpClient(withInterceptors([authInterceptor]))`** — configures `HttpClient` and registers a functional interceptor. - **`provideClientHydration(withEventReplay())`** — tells the browser app to reuse the server-rendered DOM instead of discarding it; `withEventReplay()` captures clicks made before hydration finishes and replays them afterwards. ## What is deliberately *not* in the file The v20–v22 defaults removed several lines that older tutorials show: | Line from older configs | Why it is absent in v22 | |---|---| | `provideZoneChangeDetection({ eventCoalescing: true })` | Zoneless is the default since v21; add a zone provider only to opt back in | | `withFetch()` inside `provideHttpClient` | `FetchBackend` is the default since v22; `withFetch()` is deprecated and does nothing | | `withIncrementalHydration()` | Incremental hydration is on by default with `provideClientHydration` since v22; the function is deprecated | | `importProvidersFrom(HttpClientModule)` | `HttpClientModule` is deprecated in favour of `provideHttpClient` | | `RouterModule.forRoot(routes)` | Replaced by `provideRouter(routes)` in standalone apps | A related v21 change: `HttpClient` is injectable **without** any provider. `provideHttpClient()` is still how you configure it — here it is needed because of the interceptor. ## Why functions instead of modules The module era configured the same things with `RouterModule.forRoot(routes, { ... })` and `HttpClientModule`. The function-based APIs improve on that in several ways: 1. **Composable features.** Each optional behaviour is its own `withX()` function passed as an argument, so the config lists exactly what is enabled, and each function is typed for the provider it belongs to. 2. **Unused features stay out of the bundle.** A feature you never import and call is never referenced, so the bundler can leave its code out. An options-object API has to ship code for every option it might read. 3. **Guarded placement.** These functions return **`EnvironmentProviders`**. A component's `providers` array rejects them with `NG0207`, so app-wide infrastructure cannot be accidentally re-created per component. 4. **No module graph to reason about.** There are no `forRoot`/`forChild` pairs and no risk of importing a root-level module twice. ## Does the order of the array matter? Rarely. Each function registers providers for different tokens, so their order is irrelevant. Order matters only when **two entries provide the same token**: the injector keeps the **last** registration for a non-multi token, while multi-providers accumulate. That is worth knowing when a server config is merged on top of this one. ## A review checklist for an existing `app.config.ts` Configs that have lived through several upgrades collect lines that no longer earn their place. When reviewing one against v22, check each entry: - **Is it a no-op?** `withFetch()` now does nothing; `withIncrementalHydration()` is deprecated because the behaviour is already on. - **Is it an opt-out in disguise?** `provideZoneChangeDetection()` is not a harmless leftover — it re-enables zone-driven change detection. Keep it only on purpose. - **Is it a deprecated module?** `importProvidersFrom(HttpClientModule)` should become `provideHttpClient(...)`. - **Does it need to be global?** A provider used by one lazily loaded feature can move to that route's `providers`, shrinking what every page pays for at startup. - **Is it duplicated?** Two entries for the same token mean the later silently wins, which usually hides a mistake. The `ng update` migrations handle many of these mechanically, but a human still needs to decide the zone question and the global-versus-route question. ## Where the details live This file only shows *which* functions to call. The meaning of each router feature, each HttpClient feature and the hydration options are separate subjects; interviewers asking about `app.config.ts` usually want the list, the reason each line is there, and awareness of the defaults that removed lines.