Reactivity & Data

Reactive values and resources

HTML Next keeps a few concepts separate rather than overloading one element, because their lifecycles differ. All of them are declarations: they live in the definition's <defs> region, not in the visible markup (see Components).

<state name="query" value="">        <!-- literal string -->
<state name="page" :value="1">        <!-- number, via the colon -->
<computed name="hasQuery" from="query != ''">  <!-- derived boolean -->

The design, a declared dependency graph that can be analyzed statically rather than traced at runtime, has deep prior art in signals and fine-grained reactivity⁵: Solid signals and createMemo and Angular signals are its closest current relatives, with Knockout observables as the historical ancestor. RxJS is a deliberate contrast, it models push streams, not the settled value cells <state> and <computed> are.

<data>: a declared, reactive resource

This is HTML Next's standards-shaped answer to htmx¹: instead of hx-get/hx-trigger/hx-target string attributes swapping opaque HTML, a <data> element declares a typed, reactive resource whose parameters are visible right where it lives. For a read, each <param :value> subscribes to the state it binds, so the set of params is the dependency graph: change one and the resource refetches, and bindings that read it re-render. Nothing triggers it imperatively. This is the surface Solid createResource already ships⁶, a resource whose fetch re-runs on source change and exposes loading and error; TanStack and Vue Query are the same idea with a params-keyed cache.

<data name="search" src="/api/search" type="object" debounce="200ms">
  <param name="q" :value="query">     <!-- subscribes to query: refetches when it changes -->
  <param name="page" :value="page">
</data>

Params are serialized, never interpolated into a URL string. A {name} placeholder in src is filled from the matching <param> (RFC 6570 URI Templates)²; on a read, params not named in the template become the query string. There is no string concatenation, and therefore no injection surface.

A <data> exposes a small, typed surface any binding can read:

To refetch with unchanged inputs (a manual refresh, polling) there is no imperative call: bump a state param the source depends on, or declare a poll interval. For a read, a param change cancels the stale in-flight GET request. Reads are keyed by their resolved params, giving a natural cache key.

<input bind:value="query" placeholder="Search…">
<template $match>
  <progress $when="search.pending"></progress>
  <output $when="search.error"><value of="search.error.message"></value></output>
  <ul $else>
    <li $each="r of search.value.results" $key="r.id"><value of="r.title"></value></li>
  </ul>
</template>

Writes: reactive data effects

A synchronized write is the outbound half of the same reactive resource model. A <data> with a modifying method and send="change" observes its body parameters and sends their latest snapshot when they change. This mode represents state synchronization: each body is the latest state, never a request to perform a one-shot command. debounce controls the quiet period before the effect runs, so autosave does not mean one request per keystroke. The declaration lives in <defs> and exposes .dirty, .pending, .value, .error, and .ok.

<defs>
  <!-- A modifying <data> is a reactive sink, not a hidden form. -->
  <data name="saveDraft"
        method="patch"
        src="/api/posts/{id}"
        send="change"
        debounce="500ms">
    <param name="id" :value="post.id">        <!-- resource identity -->
    <param name="title" :value="draft.title"> <!-- reactive body field -->
    <param name="tags" :value="draft.tags">
  </data>

  <!-- An explicit command stays an event for the owner to handle. -->
  <handler name="requestPublish">
    <dispatch event="publish" :value="draft">
  </handler>
</defs>

<!-- These controls may already be inside a consumer-owned native <form>. -->
<input bind:value="draft.title">
<button type="button" on:click="requestPublish">Publish</button>

<p aria-live="polite" $if="saveDraft.pending">Saving…</p>

Initial connection samples the current body as that resource key's baseline and does not send a write. After the first acknowledged write, the baseline is the last acknowledged body for that key. A body-param change marks the resource dirty and queues a write. Every queued or in-flight write captures an immutable resolved resource identity and body snapshot. While a write is pending, further body changes for the same key replace one trailing queued snapshot with the latest one. A sent write is never cancelled because cancellation cannot undo a request the server may already have applied.

A parameter consumed by the src URI template identifies the resource. Changing it activates an independent baseline for the new key; queued and in-flight work keeps its captured old key and may finish there. Completion for an old key updates only that key's stored result. It must not change the active new key's .dirty, .pending, .value, .error, or .ok.

Disconnecting removes observations, pauses unsent queued work, and preserves its dirty latest snapshot and captured key. A sent write may finish, but it cannot schedule DOM work for a detached instance. On reconnect, preserved queues resume under their own keys. For the current key, the runtime samples the current body: an unseen key gets an initial no-send baseline; a known key remains dirty and resumes synchronization when its body differs from its last acknowledged baseline. While no instance is connected, nothing new is observed or scheduled.

A writable data resource does not own controls or create a rendered <form>. The same state can feed several resources with different endpoints, methods, parameter subsets, and send options. The visible controls may be standalone, inside a native form owned by the component, or inside a form that already contains the component instance.

Commands remain explicit

Publishing, charging, sending email, and deleting are commands, not synchronization. They must not run because a dependency happened to change. Their commitment point remains author-owned: native form submission, an imperative controller call, or a component event dispatched from an internal button. An internal button may itself be a native submit button associated with the surrounding form; when it is not, its handler can dispatch the command intent without owning the endpoint. HTML Next therefore adds no <send> handler step and does not distort reactive state into a command trigger.

Lifecycle

In a reactive component most of what framework lifecycle callbacks did is absorbed by the dependency graph, so HTML Next needs far fewer hooks, and names the ones it keeps after the platform's custom-element reactions, for least surprise.

What the graph already handles

• Prop / attribute changes: the bindings, <computed>, and <data> that read a prop re-run automatically. This is attributeChangedCallback, and you never write it.
• Fetch on mount, refetch on change: declare a <data>; it runs when its params resolve and again when they change. This is the connectedCallback fetch.
• Initial and derived state: <state :value> and <computed>; initial focus is autofocus.

Declarative lifecycle events

For a reaction that is not a derivation, on:connect and on:disconnect run a handler when the component is connected or disconnected, mirroring connectedCallback/disconnectedCallback⁷ and firing again on reconnect. Because handlers are declarative, they set state or <dispatch> an event, with no imperative code. They are client-only: SSR renders the static tree, and hydration is what connects, so nothing lifecycle-driven runs on the server.

<defs>
  <state name="visible" :value="false">
  <handler name="show"><set name="visible" :value="true"></handler>
  <handler name="hide"><set name="visible" :value="false"></handler>
</defs>

<!-- lifecycle events run handlers; client-only (SSR never connects) -->
<section on:connect="show" on:disconnect="hide">…</section>

The dependency graph

Every expression exposes the paths it reads, and every <param :value> names a subscription, so the graph is known statically. This buys type-checkable expressions, predictable invalidation, ahead-of-time generation for any reactive framework, and a browser runtime that needs no dynamic code.

Relationship to TC39 Signals

Decision: HTML Next integrates with, but does not depend on, the TC39 Signals proposal.⁴ Signals are a good optional substrate for a browser runtime and a potential implementation interoperability point. They are not the authored markup model, a required implementation strategy, or a second source of observable semantics. A runtime may use native Signals, a small userland graph, or a target framework's reactivity so long as the HTML Next result is equivalent.

The TC39 proposal is intentionally lower-level than a UI system: it standardizes writable and computed cells plus dirtiness notification, while leaving effects, scheduling, DOM ownership, and automatic disposal to frameworks. HTML Next already has the missing owner: the connected template instance.

The minimum useful Signals subset

If an implementation chooses TC39 Signals, HTML Next needs the semantics of State, Computed, and Watcher: writable cells, lazy cached and glitch-free derivations, and a notification that lets the DOM layer schedule a flush. The DOM layer owns when to call watch/unwatch; authors do not.

Element reference

Sources

1. htmx (hx-get/hx-trigger/hx-target) and its Locality of Behaviour essay.
2. IETF, RFC 6570: URI Template (the {name} placeholder syntax).
3. WHATWG HTML, form submission (the native model for constructing an entry list and selecting an endpoint, method, and encoding).
4. TC39, Signals proposal (Stage 1): a candidate reactive substrate whose State, Computed, and Watcher primitives deliberately leave effects, scheduling, DOM ownership, automatic disposal, and future HTML/DOM integration to a higher layer.
5. Signals and fine-grained reactivity as a declared, statically-analyzable dependency graph: Solid signals and createMemo, Angular signals, with Knockout observables as the historical ancestor (and Vue ref/computed, Preact signals). Contrast: RxJS models push streams, not value cells.
6. Solid createResource: a resource whose fetch re-runs when its source changes, exposing loading and error, the exact surface <data> exposes as .pending/.error/.value/.ok. TanStack Query and Vue Query key a cache by request params, matching requests keyed by resolved params here.
7. WHATWG HTML, custom element reactions (connectedCallback/disconnectedCallback, the naming precedent for on:connect/on:disconnect).
8. The return-a-disposer teardown shape: Solid onCleanup and React effect cleanup.
9. WHATWG Fetch, methods: method normalization uppercases DELETE, GET, HEAD, OPTIONS, POST, and PUT; it does not include PATCH.
10. IETF, RFC 10008: The HTTP QUERY Method: a safe, idempotent method that carries request content.
11. WHATWG HTML, issue #12594: the active proposal to support method="query" and formmethod="query" in HTML forms.