Static Route Generation

## Where the setting lives An Angular app with server rendering has two route lists: - the **client routes** in `app.routes.ts`, used by the Angular router; - the **server routes** in `app.routes.server.ts`, a `ServerRoute[]` that tells `@angular/ssr` how to render each path. The server routes are registered in the server config: ```ts // app.config.server.ts import { ApplicationConfig, mergeApplicationConfig } from '@angular/core'; import { provideServerRendering, withRoutes } from '@angular/ssr'; import { appConfig } from './app.config'; import { serverRoutes } from './app.routes.server'; const serverConfig: ApplicationConfig = { providers: [provideServerRendering(withRoutes(serverRoutes))], }; export const config = mergeApplicationConfig(appConfig, serverConfig); ``` Each server route picks one `RenderMode`: `Server` (render per request), `Client` (send the client-side shell) or `Prerender`, which is the subject here. ## What RenderMode.Prerender does For a route marked `RenderMode.Prerender`, the build does the rendering work ahead of time: 1. `ng build` extracts the application's routes and matches each against the server routes. 2. For every prerendered path, it bootstraps the app on the server, navigates to the path and waits until the application is stable. 3. It serializes the result, including any transferred state, into HTML. 4. It writes the file to the browser output folder as `<path>/index.html`, for example `pricing/index.html`. At runtime: - With Angular's server engine, the matching file is returned for `GET` and `HEAD` requests with an `ETag`, and a matching `If-None-Match` gets a `304`. The route's `headers` are added to the response. - With no server at all (the build's static output mode), any static file host can serve the files directly. ## The default: everything is prerendered The CLI schematic that adds SSR generates this server routes file: ```ts import { RenderMode, ServerRoute } from '@angular/ssr'; export const serverRoutes: ServerRoute[] = [ { path: '**', renderMode: RenderMode.Prerender }, ]; ``` So in a freshly generated app every client route is prerendered. That works for routes without parameters. A route with a parameter such as `docs/:slug` has no single path to render, so it needs a `getPrerenderParams` function that lists the concrete values; without one the build fails. ## What a prerendered page cannot know Prerendering happens once, at build time, for everyone: | Question | Prerendered answer | |---|---| | Who is the visitor? | Unknown: the `REQUEST` token is `null` during static generation | | Which cookies or headers were sent? | None | | Which query string was used? | The file is chosen by path; the query string does not select a different file | | Which HTTP status should be sent? | Not configurable: prerender server routes have no `status` property | | Is the data current? | As current as the last build | Pages that are the same for every visitor (marketing pages, documentation, blog posts) fit well. Pages whose content depends on the visitor or the request belong on `RenderMode.Server` or `RenderMode.Client`. ## A worked example A small documentation site might configure its server routes like this: ```ts import { RenderMode, ServerRoute } from '@angular/ssr'; export const serverRoutes: ServerRoute[] = [ { path: '', renderMode: RenderMode.Prerender }, // landing page { path: 'pricing', renderMode: RenderMode.Prerender }, // same for everyone { path: 'account/**', renderMode: RenderMode.Server }, // depends on the visitor { path: '**', renderMode: RenderMode.Prerender }, // everything else ]; ``` The build writes `index.html` and `pricing/index.html`; account pages are rendered per request because they depend on who is asking. Documentation pages with a `:slug` parameter would additionally need `getPrerenderParams`. ## Costs to keep in mind - **Build time and output size** grow with the number of prerendered paths. - **Code must be server-safe**, exactly as for per-request rendering, because the same server platform renders it. - **Data sources must be reachable during the build**, since components fetch their data at build time. ## Why interviewers ask it It checks whether a candidate knows where Angular's render modes are configured, what the generated default does, and the boundary of what a build-time render can contain.