Skip to content

fix(ssr): map defaultValue/defaultChecked to controlled value (v3.5.2)#45

Merged
monstercameron merged 1 commit into
masterfrom
react-parity/fix-default-value
Jun 25, 2026
Merged

fix(ssr): map defaultValue/defaultChecked to controlled value (v3.5.2)#45
monstercameron merged 1 commit into
masterfrom
react-parity/fix-default-value

Conversation

@monstercameron

Copy link
Copy Markdown
Owner

An uncontrolled form field set via defaultValue rendered empty in SSR (defaultValue is a browser-ignored attribute). Now mapped to the controlled value/checked in both renderers, flowing through input/textarea/select. Matches React; completes controlled-input SSR. Full suite + native/wasm pass. Ships as v3.5.2.

🤖 Generated with Claude Code

…(v3.5.2)

An uncontrolled form field set via defaultValue (or defaultChecked) serialized the
prop literally (<input defaultValue="x">), which the browser ignores, so the field
rendered empty/unchecked server-side. normalizeFormValueProps now maps
defaultValue -> value and defaultChecked -> checked (only when the controlled prop
is absent, so an explicit value wins), applied at the top of both host renderers.

Running before the controlled-value logic, the mapping flows through every form
element: <input> gets a value attribute, <textarea> gets text content, and
<select> marks the matching <option selected>. Matches React's
ReactDOMServerIntegrationInput/Textarea/Select; completes the controlled-input SSR
work (v3.4.9 textarea, v3.4.10 select). Covered by
TestSSRDefaultValueMapsToControlledValue; full suite + native/wasm pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@monstercameron monstercameron merged commit f9ecf3b into master Jun 25, 2026
3 checks passed
@monstercameron monstercameron deleted the react-parity/fix-default-value branch June 25, 2026 04:12
monstercameron pushed a commit that referenced this pull request Jul 6, 2026
…ty verify (#45)

- HandlePatchIdempotency drops a never-seen version below the epoch high-water
  mark (stale/reordered worker-bridge delivery) instead of regressing the DOM.
- VerifyPatchStreamIdentity recompute-and-verify capability (defense-in-depth),
  not wired into the mandatory decode path (false-reject hazard documented).
Both pinned; full runtime2 suite green. Deferred designs in DEVNOTES.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
monstercameron pushed a commit that referenced this pull request Jul 6, 2026
…r boundary (#45)

The VerifyPatchStreamIdentity capability existed and was pinned but unwired. Wire
it into ParseHostPatchPayloadWithFallback (the host-side decode boundary for every
worker-produced patch) as an ADVISORY check: after a patch is decoded across the
worker serialization boundary, its carried identity is recomputed from its decoded
parts and a mismatch is surfaced via a fail-visible diagnostic
(GWC-PATCH-IDENTITY-MISMATCH) — the patch is NOT rejected.

Advisory, not a hard gate, by design: buildPatchStreamIdentityFromParts
distinguishes nil from empty-but-non-nil ops, and streams may legitimately carry a
hand-set (non-canonical) identity (the existing header-only transport test does),
so a hard reject risks false-rejecting a valid patch and breaking rendering. The
advisory removes the silent-application gap (a corrupted/tampered body with an
intact identity is no longer applied without a trace) at zero false-reject risk.
Promotion to a hard reject stays gated on the worker-bridge harness (#83) proving
every patch reaching this boundary round-trips its identity exactly.

Pins (negative-verified): TestVerifyDecodedPatchIdentityReportsMismatchWithoutRejecting,
TestHostBoundaryDoesNotFalseAdviseOnCanonicalPatch (the safety proof: canonical
patches round-trip both the binary and structured-clone tiers with no false
advisory), TestVerifyDecodedPatchIdentitySilentOnEmptyIdentity.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants