feat(forms): Datastar transport for the SSR form #36

Merged

mprihoda merged 4 commits from forms-datastar into main

2026-07-13 09:01:13 +00:00

mprihoda commented

2026-07-12 20:13:37 +00:00

(Migrated from github.com)

What

Adds a Datastar variant of the SSR form interpreter, at parity with the HTMX one:

FormTransport seam (forms/jvm): the form-level wiring attributes (change-triggered re-render, submission) move behind a small trait. FormTransport.htmx renders byte-identical attributes to the previous inline ones; the committed-choice re-render selector list is shared by both transports.
forms-datastar module (published as iw-support-forms-datastar): DatastarFormTransport emits data-on:submit and a selector-filtered data-on:change, both posting via @post('…', {contentType: 'form'}). Depends on scalatags-datastar / scalatags-datastar-sse 0.1.0-SNAPSHOT resolved from the code.iterative.works Forgejo registry.
datastarForm scenario: shares the extracted InquiryFormLoop state machine with the ssrForm scenario — parity by construction; only rendering differs. Actions answer datastar-patch-elements SSE morphing the form by id, with a plain-HTML no-JS fallback.

Why no endpoint/header discrimination

Datastar v1.0.2's {contentType: 'form'} respects novalidate and appends the submitter's name/value like a native submission (verified in fetch.ts source), so the existing __submit/named-button protocol works unchanged. The whole variant surface is two form-level attributes plus SSE responses.

Proof

datastar-form.feature mirrors ssr-form.feature word for word — 7 browser scenarios, all green on first run (30 e2e scenarios total), including typed text surviving a change-triggered morph.
Route-level spec pins the SSE wire format, the datastar-request header branch, and the shared-loop outcome.
__.compile clean with zero warnings; full __.test green.

Notes

The SNAPSHOT pin on scalatags-datastar is fragile — worth cutting a tagged release there before this ships downstream.

🤖 Generated with Claude Code

## What Adds a Datastar variant of the SSR form interpreter, at parity with the HTMX one: - **`FormTransport` seam** (`forms/jvm`): the form-level wiring attributes (change-triggered re-render, submission) move behind a small trait. `FormTransport.htmx` renders byte-identical attributes to the previous inline ones; the committed-choice re-render selector list is shared by both transports. - **`forms-datastar` module** (published as `iw-support-forms-datastar`): `DatastarFormTransport` emits `data-on:submit` and a selector-filtered `data-on:change`, both posting via `@post('…', {contentType: 'form'})`. Depends on `scalatags-datastar` / `scalatags-datastar-sse` 0.1.0-SNAPSHOT resolved from the code.iterative.works Forgejo registry. - **`datastarForm` scenario**: shares the extracted `InquiryFormLoop` state machine with the `ssrForm` scenario — parity by construction; only rendering differs. Actions answer `datastar-patch-elements` SSE morphing the form by id, with a plain-HTML no-JS fallback. ## Why no endpoint/header discrimination Datastar v1.0.2's `{contentType: 'form'}` respects `novalidate` and appends the submitter's name/value like a native submission (verified in `fetch.ts` source), so the existing `__submit`/named-button protocol works unchanged. The whole variant surface is two form-level attributes plus SSE responses. ## Proof - `datastar-form.feature` mirrors `ssr-form.feature` word for word — 7 browser scenarios, all green on first run (30 e2e scenarios total), including typed text surviving a change-triggered morph. - Route-level spec pins the SSE wire format, the `datastar-request` header branch, and the shared-loop outcome. - `__.compile` clean with zero warnings; full `__.test` green. ## Notes - The SNAPSHOT pin on scalatags-datastar is fragile — worth cutting a tagged release there before this ships downstream. 🤖 Generated with [Claude Code](https://claude.com/claude-code)