Solid 2.0 - Textarea hydration bug

[sabercoy]

Describe the bug

A textarea with a reactive value causes hydration issues.

Hydration key miss for "170300310002": no server-rendered element carries this key (template: <button class=increment type=button>Clicks: <!$><!/>). A detached element was created instead; its subtree will not appear in the document or become interactive. This usually means the server and client hydration id namespaces are misaligned — when hydrating a subtree of a larger server render, wrap the document shell in <NoHydration> and re-enter with <Hydration> around the hydrated subtree (or pass hydrate() a renderId matching the server's <Hydration id>).

web.dev-D1p1Q9NU.js?v=7555594c:1570 Hydration completed with 1 unclaimed server-rendered node(s):
  <button _hk="170300310003" class="increment" type="button">Clicks: <!--$-->0<!--/--></button>

Your Example Website or App

https://github.com/sabercoy/solid2-textarea-hydration-bug

Steps to Reproduce the Bug or Issue

Run the app and see the errors in the console. It is a basic create-solid app with only the index.tsx page modified.

Expected behavior

No errors.

Screenshots or Videos

No response

Platform

• OS: Linux
• Browser: Chrome

Additional context

No response

[ryansolid]

Confirmed and fixed in #3696 — thanks for the minimal reproduction, it pinpointed it.

Root cause: on the server, <textarea value={text()} /> folds the value into the textarea's text content, and that folded child was taking the _$scope hydration-id reservation a dynamic child hole gets. The client compiles the same JSX to a plain value property effect, which never allocates an id. So the server consumed one extra child slot before Counter, and everything after the textarea hydrated one id off — exactly the …0003 vs …0002 you saw, with the button going unclaimed and the click updating detached DOM.

Same class of bug as #3015 (innerHTML/textContent), which had the fix but the textarea fold lives on a different path in both the Babel plugin and the native compiler. Both are fixed together, with a shared compiler fixture and a hydration parity-harness scenario that reproduces your report (fails pre-fix, passes after).

— Claude via Cursor

[ryansolid]

Merged to next as part of #3696 — will be in the next RC. Closing by hand since next is not the default branch.

— Claude via Cursor