Which Angular routes should not use RenderMode.Prerender, and what goes wrong when a request-dependent page is prerendered?

## The core constraint `RenderMode.Prerender` renders a route **once**, during the build, for **everyone**. The render has no request behind it: - `inject(REQUEST)` returns `null` during static generation, as the token's own documentation states; - there are no cookies, no `Authorization` header, no `Accept-Language`, no client IP; - the page is chosen by **path**; a query string does not select a different file; - the route's server configuration has no `status` property for prerendering, so the status cannot vary. Anything the page would normally read from the request is absent or at its default value when the HTML is produced. ## What goes wrong, by page type | Page | What gets baked in | What users see | |---|---|---| | Signed-in dashboard | The logged-out or empty state | A flash of wrong content until client code replaces it | | Search results by `?q=` | The result for no query | The same HTML for every query until the browser takes over | | Localized page chosen by `Accept-Language` | The build machine's default | Every visitor gets one language in the HTML | | Stock levels or prices | Values from build day | Stale data until the next deploy | | "Not found" for a bad id | A normal page | A `200` status for missing content | Each case also affects crawlers, which see only the baked-in HTML. ## Why hydration does not save you After the prerendered HTML loads, the app boots and may fetch fresh, user-specific data. That fixes the view eventually, but: 1. The first paint shows the wrong content, which is often worse than a loading state. 2. If the browser's first render differs structurally from the prerendered DOM, hydration reports mismatches. 3. Crawlers and link previews keep the wrong version. ## Choosing a better mode - **`RenderMode.Server`** renders per request and can read `REQUEST`, cookies and headers, and set a `status`. Use it for personalised pages, query-driven pages and correct not-found responses. - **`RenderMode.Client`** sends the client shell. Use it for signed-in areas that crawlers never see. - **Split the page.** Prerender the shared shell and render the personal part in the browser after hydration, for example a documentation page with a prerendered article and a client-rendered "your progress" widget. ## Build-time traps that look like request-time bugs - Components that call `Date.now()` or pick random items bake one value into the file. - Environment-specific configuration read during the build reflects the build environment, not the one serving traffic. - A prerendered route whose data source is unreachable during the build fails the build, or renders an error state into the file if the error is caught. ## The silent default The CLI's SSR schematic generates a single `{ path: '**', renderMode: RenderMode.Prerender }` server route. That default is convenient, and it is also how request-dependent pages end up prerendered by accident: 1. A developer adds an `account` route to the client routes. 2. It has no parameters, so it matches the catch-all and is prerendered without any error. 3. The build writes `account/index.html` in its signed-out state, and nobody notices until a user reports the flash. Parameterized routes fail loudly because `getPrerenderParams` is missing; parameterless ones do not. A safer server routes file lists the request-dependent sections explicitly, for example `account/**` with `RenderMode.Server` or `RenderMode.Client`, before the catch-all, and code review checks new routes against it. ## A quick test for each route Ask three questions: 1. Would two visitors, at the same moment, see different HTML? If yes, do not prerender. 2. Does the data change more often than you deploy? If yes, prerendering serves stale pages. 3. Does the page need a status other than `200`? If yes, it needs a server render. If all three answers are no, prerendering is a strong fit.