RenderEvent: any UI can participate

RenderEvent lets a library place output it already owns into a Typed template. Choose the representation from that output: live DOM objects or serialized HTML.

Application authors usually need renderable values instead. If a library only configures one template element, use a scoped ref. Implement RenderTemplate only when the library must interpret template literals and their parts for a target.

Choose output by what the producer actually has

The producing Fx supplies sequencing, failures, required services, and cancellation. Constructing an event value does none of those things by itself.

DOM output preserves exact object identity. Its containing Typed range controls placement; the producer owns updates inside those objects and any resources it starts. HTML output is an ordered sequence of serialization chunks, not a series of replacement views.

Compose at the smallest useful boundary

import { Fx } from "@typed/fx";
import { html } from "@typed/template";
import { DomRenderEvent } from "@typed/template/RenderEvent";

const chart = Fx.sync(() => DomRenderEvent(document.createElement("canvas")));

export const page = html`<main>
  <section aria-label="Chart">${chart}</section>
</main>`;

Each run creates a canvas, and the template inserts that exact object. For an adapter that also starts a timer or acquires a library instance, keep that work scoped beside the output. Using DomRenderEvent shows a complete canvas example with recurring work and teardown; multi-node output covers persistent ranges.

HtmlRenderEvent asserts that the producing serializer owns escaping: the constructor does not sanitize its string. Keep application text in ordinary interpolation. See Using HtmlRenderEvent for ordered chunks, completion, and escaping.

Public isDomRenderEvent and isHtmlRenderEvent guards distinguish the representations at adapter boundaries. Continue with the compilation pipeline only when output transport is insufficient and you need a template interpreter.