@rx-angular/isr
Incremental Static Regeneration (ISR) for Angular SSR (@angular/ssr). It caches
Incremental Static Regeneration (ISR) for Angular SSR (@angular/ssr). It caches
Complete export surface of @rx-angular/isr, split by entry point: @rx-angular/isr/server, @rx-angular/isr/browser, and @rx-angular/isr/models. Every signature is source-derived (package 21.0.1).
By default ISR does not cache a page whose server render produced an HTTP error. It falls back to client-side rendering so an error page never gets cached and served to every visitor. This recipe shows how to change that default and how to flag your own non-HTTP errors.
Incremental Static Regeneration (ISR) caches server-rendered Angular pages and
Goal
Welcome 🙌
On-demand revalidation lets you refresh a cached page the moment its data changes (for example after a CMS update) instead of waiting for the scheduled revalidate window to expire.
Field-level reference for a subset of ISRHandlerConfig fields, plus the deprecated RenderConfig.modifyGeneratedHtml history. For the full field table see ISRHandlerConfig.
Configuration object passed to the ISRHandler constructor. Source-derived (package 21.0.1), all 18 fields below. Defaults are applied in the ISRHandler constructor / render pipeline, not on the interface itself.
ISR can store arbitrary extra data alongside a cached page, for example how long the API requests behind that page took, so you can show how much time serving from cache saved. You write to the bag with IsrService.addExtra and read it back with getExtra.
When a page renders differently depending on request state (for example logged-in vs. anonymous users), a single cached copy would be served to everyone, causing a content shift after hydration. Cache variants let ISR store and serve a distinct cached copy per request state.
Sometimes you need to alter the HTML ISR handles, for example injecting a tracking script into pages served from cache, or stamping generated pages before they are stored. ISR exposes two hooks for this: modifyCachedHtml (runs on serve-from-cache, on every request) and modifyGeneratedHtml (runs once, on the fresh render, before the page is cached).
Cache handling in ISR is pluggable: the default InMemoryCacheHandler keeps rendered pages in RAM, and the built-in FileSystemCacheHandler persists them to disk. When you need a different backing store (Redis, a database, an object store), you supply your own handler by extending the CacheHandler abstract class.