Browse documentation
Documentation

Idle warming

Edit this guide on GitHub

Idle region warming

Hearth pre-mounts inactive if $(...) regions outside list items after the document loads. Inactive per-row arms remain lazy, so pooled row retargets do not update speculative hidden content. The region stays under a hearth-when wrapper with display: none until its condition becomes true. It keeps its scope and DOM nodes across route changes.

Speculative hydration runs at background priority in slices with a 4 ms budget. The hydrator yields between nodes. List reconciliation yields between row visits, retargets, insertions, and removals, including later updates while hidden. A browser without scheduler.postTask uses requestIdleCallback, or timers as a final fallback. Input and rendering can run between slices. If navigation arrives during preparation, the region finishes pending hydration before becoming visible. Disposing the owning scope cancels its pending work. Render replacements remain synchronous so signal adoption and dependency subscriptions complete before their callers continue. Failed speculative bindings are reported without stopping sibling hydration.

A list with a limit of one can prepare one detached row shell even when its current query is empty. Nested lists in that shell see placeholder fields until a real row is assigned. They use the same indexed query engine as visible lists. The shell lives in the existing bounded item pool, and its row signal retargets labels, reactions, and comments without rebuilding their DOM. This does not pre-render every issue or cache a page per route.

Expressions in inactive regions can run before the first visit. Keep side effects in event handlers. A guarded expression or placeholder row can throw during preparation. The failure invalidates only the warmed region that owns the failing content, and activation disposes that speculative scope and hydrates a fresh copy synchronously with the real condition and row values. Failed shells are not reused in the activated copy. Empty route parameters are not special-cased by the database. Queries still apply their predicates and use equality indexes, so an absent key produces an empty result. The first lookup may build an index.