In Angular SSR, what happens when a visitor requests a docs page that getPrerenderParams did not list, and how do PrerenderFallback.Server, Client and None differ?
answer
- unlisted path, fallback decides
- default is Server
- Client sends the shell
- None hands the request on
basics
~20 sThe route's fallback decides. PrerenderFallback.Server, the default, renders the page on the server at request time; Client sends the client-rendered shell; None makes Angular's engine decline the request, so the next handler, usually a 404, answers.
solid answer
~50 sA prerendered route with `getPrerenderParams` can take a `fallback` of type `PrerenderFallback`. When a request hits a path the build did not list, Angular's server engine uses it: `Server`, the default when `fallback` is omitted, renders that path per request like `RenderMode.Server`; `Client` returns the client-side shell and lets the browser render; `None` means Angular does not handle the request at all, so whatever comes next in your server, typically a 404 handler, answers. `fallback` is only accepted on routes that define `getPrerenderParams`, and it only matters when the app is deployed with Angular's server: with the static output mode no fallback routes exist, and unknown paths are up to the static host. Choose `Server` for content published between builds, `Client` for pages that need no SEO, and `None` when the list is complete and unknown slugs should be 404s.
go deeper
Remember that a prerendered route with getPrerenderParams has a fallback for unlisted paths, and that Server is the default.
Explain what each of Server, Client and None does, and that fallback only works when Angular's server handles the request.
Choose the fallback from how content is published and how not-found pages must behave, including the 200-versus-404 question.
Align fallback choices with the publishing workflow and hosting model so new content and broken links behave predictably.
## The situation A documentation site prerenders `docs/:slug` from a slug list at build time. After deployment, a writer publishes a new page, or a visitor mistypes a URL. The request arrives for `docs/new-page`, and there is no prerendered file for it. The route's **fallback** decides what happens. ## The three strategies `PrerenderFallback` is an enum from `@angular/ssr`, set with the `fallback` property of a prerendered server route that also has `getPrerenderParams`: | Value | What Angular's server engine does for an unlisted path | Typical use | |---|---|---| | `PrerenderFallback.Server` (default) | Renders the page at request time, like `RenderMode.Server` | Content added between builds must work immediately | | `PrerenderFallback.Client` | Serves the client-side shell; the browser renders the page | Pages where SEO and first paint matter little | | `PrerenderFallback.None` | Declines the request; the next handler in your server answers | The list is complete; unknown slugs should be 404s | With `None`, Angular's request handler returns nothing for that path, so in a Node server the request falls through to whatever middleware follows, usually a not-found handler. ```ts import { RenderMode, PrerenderFallback, ServerRoute } from '@angular/ssr'; export const serverRoutes: ServerRoute[] = [ { path: 'docs/:slug', renderMode: RenderMode.Prerender, fallback: PrerenderFallback.Server, // explicit, though it is the default async getPrerenderParams() { return [{ slug: 'getting-started' }, { slug: 'routing' }]; }, }, ]; ``` ## Rules around the setting - **Only with `getPrerenderParams`.** The type for a prerendered route without parameters declares `fallback` as `never`; a fixed path has nothing to fall back from. - **Only with a server.** Fallbacks are resolved by Angular's server engine. When the build uses the static output mode, fallback routes are not generated, and a request for an unlisted path is handled entirely by the static host. - **The default is not `None`.** Omitting `fallback` means unlisted slugs are rendered on the server. A site that expects unknown slugs to 404 must either set `None` or make the page itself render a not-found state. ## Choosing a strategy 1. **Is the list always complete at build time?** If yes and unknown slugs are mistakes, `None` avoids spending server time on them. 2. **Can content appear between builds?** If yes, `Server` serves new pages immediately with full HTML, at the cost of per-request rendering for those paths. 3. **Is server rendering unavailable or unwanted for these paths?** `Client` avoids server rendering work, but the first paint waits for JavaScript and crawlers get less. ## Interactions to watch - With `Server`, the fallback render runs with a real request, so code that behaves differently when `REQUEST` exists can produce pages that differ from the prerendered ones. Keep the page independent of the request so both paths match. - With `Server`, a mistyped slug renders your "not found" state but, unless the page sets a status through the response, answers with `200`. Decide explicitly how not-found pages report their status. - With `Client`, the shell is the same for every path; the page's data is fetched in the browser. ## A worked decision For the documentation site, suppose writers publish several pages a day and the site deploys nightly: 1. Listed slugs are prerendered, so most traffic hits static files. 2. New pages published during the day are not in the list yet, so `PrerenderFallback.Server` renders them per request until the next build includes them. 3. Mistyped slugs also go through the server render; the page shows a not-found state and should set a `404` status for that render. If instead the site deployed on every publish, the list would always be complete, and `PrerenderFallback.None` would let mistyped slugs go straight to the server's 404 handler without any rendering work. ## Why interviewers ask it It separates candidates who have deployed a prerendered Angular site from those who have only built one: the default fallback, the server requirement and the static-host behaviour are the details that decide what a visitor sees.
- Why does PrerenderFallback have no effect on a purely static deployment?Fallbacks are decisions made by Angular's server engine at request time. With the static output mode there is no server: the build writes only the listed pages and does not emit fallback routes, so an unlisted path is resolved by the static host's own rules, such as its 404 page.
- With fallback Server, what status does a mistyped slug return?The page is rendered at request time like any server-rendered route, so it answers `200` unless something sets a different status. If the component shows a not-found state, set the status explicitly for that render, or use `None` and let the server's not-found handler answer.
saying these in an interview costs you the question
- Unlisted slugs return 404 by default.
- PrerenderFallback.Client renders the page on the server first.
- Fallback works the same on a static file host.
- You can set fallback on any prerendered route, parameters or not.
- PrerenderFallback.None makes Angular send an empty 200 response.