28 docs tagged with "guides"

This guide walks you through creating your first rxState() instance, seeding initial state, connecting async sources, and binding state into a signals-first template.

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.

The parent flag existed so that a structural directive could re-run its host

Goal. Practical recipes for @rx-angular/template/virtual-scrolling: basic setup,

Goal: accept an input that may be either a static value or an Observable, and

Since Angular v21, change detection is zoneless by default and Zone.js is

Goal

Goal

Goal

This is a case study: take a side effect wired up with manual subscribe/cleanup and refactor it to rxEffects, which ties the effect to the component lifecycle for you. rxEffects is the sanctioned replacement for the removed hold() on the functional RxState surface.

Goal. Schedule expensive rendering and background work so the browser's UI

patchZone controls whether a @rx-angular/template directive processes its

Goal. Defer app-level work (analytics, a heavy chart, a global "still

Goal

Since Angular v21, change detection is zoneless by default and Zone.js is

Goal

Goal

Goal. Get deterministic, synchronous assertions in unit tests for components

Goal. Control how the reactive @rx-angular/template directives (*rxFor,

Goal. Use RxVirtualView in a server-side-rendered / hydrated app without a flash

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.

Managing a collection in component state means writing the same add / update / remove

Goal: run Observable- or Promise-based side effects in a component without manual subscribe / takeUntil(destroy$) / ngOnDestroy bookkeeping. rxEffects owns the subscriptions and cleans them up when the host is destroyed.

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.

This page documents a zone-era OnPush performance technique: passing an

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.