Reference

Advanced and Custom Runtimes

Use advanced and custom runtimes with the current published Askr packages.

@askrjs/askr0.0.59

How to use advanced and custom runtimes

Create a custom runtime only when implementing a renderer host or isolated execution environment; normal applications should use the default runtime.

Import the published @askrjs/askr entrypoint.
Keep advanced and custom runtimes configuration next to the component, route, or server composition root that owns it.
Handle pending, unavailable, cancellation, and failure states, then verify the production path.

import { createRuntime, getDefaultRuntime } from '@askrjs/askr';

const applicationRuntime = getDefaultRuntime();

// Renderer authors provide the complete host contract.
const isolatedRuntime = createRuntime({ renderer: customRendererHost });

Create a runtime

`createRuntime(options?)` from @askrjs/askr builds a fresh `AskrRuntime` instance, optionally seeded with a custom `scheduler` or `renderer` via `AskrRuntimeOptions`. Most apps never call this directly — `createSPA`/`createIsland` from @askrjs/askr/boot set one up for you — but it's there for embedding Askr inside a host that needs its own runtime instance.

Renderer host

An `AskrRuntime` exposes a `.renderer` (a `RuntimeRendererHost`) and a `.configureRenderer(renderer)` method for swapping it. The host interface covers the low-level DOM operations the runtime depends on — `evaluate`, `cleanupInstancesUnder`, `teardownNodeSubtree`, and keyed-list reconciliation via `getKeyMapForElement`/`isKeyedReorderFastPathEligible` — which is the seam you'd implement to target a non-browser render surface.

Default runtime

`getDefaultRuntime()` returns the process-wide singleton `AskrRuntime` that `state()`, `derive()`, and friends use implicitly when you don't construct your own. Reach for this when you need to inspect or configure the runtime that's already backing your running app rather than standing up an isolated one.

Advanced constraints

Because component instances track internal fields like `_ownershipGeneration`, `evaluationGeneration`, and `_pendingReadSources` to drive its scheduler and dependency tracking, custom renderer hosts need to respect the existing lifecycle hooks (`evaluate`, cleanup callbacks) rather than mutating the DOM independently. Treat everything prefixed with an underscore in the type declarations as internal — it's there for the runtime's own bookkeeping, not a stable integration point.