Reactivity & Data

Reactive sources

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 read

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. 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="SearchResults" 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)²; 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. A param change cancels any in-flight request, and requests 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: the native form

Reactivity covers reads completely, but a write has an irreducible moment, the user commits, and you do not POST on every keystroke. The platform already has the declarative write primitive: form submission³. A write is a <form> with the same param model as <data>, async-enhanced (no full-page navigation), exposing the identical .pending/.error surface. The only difference from a read is when it sends: a read sends when a param changes, a write sends on submit.

<!-- a write is the native form primitive, async-enhanced -->
<form name="save" method="post" src="/api/posts/{id}" on:success="afterSave">
  <param name="id" :value="post.id">        <!-- {id} → path -->
  <input name="title" bind:value="draft.title">  <!-- a control → body -->
  <param name="tags" :value="draft.tags">   <!-- no control → body -->
  <button>Publish</button>
</form>

<!-- save.pending / save.error read exactly like a <data> source -->
<p aria-live="polite" $if="save.pending">Saving…</p>

Named inputs and <param> serialize the same way, routed by method: to the query string for GET, to the body for POST/PUT/PATCH, exactly as a native form already does. Post-write side effects (leave edit mode, announce success) belong to the form's lifecycle, so they run from an on:success handler, not inline.

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.

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 write primitive and its param serialization).
4. TC39, Signals proposal (a candidate reactive substrate).
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.