2.0.0-beta.28: Hydration mismatch when using spread + ternary on an attribute + `For`

[dangkyokhoang]

Describe the bug

The below pattern causes hydration mismatch:

const Icon: Component<any> = (props) => {
  const rest = omit(props, "iconNode");
  return (
    <svg {...rest} stroke-width={props.cond ? props.x : 2}>
      <For each={props.iconNode}>{([tag, attrs]) => <div />}</For>
    </svg>
  );
};

Hydration completed with 4 unclaimed server-rendered node(s):
  <div _hk="2100"></div>
  <div _hk="2110"></div>
  <div _hk="2120"></div>
  <div _hk="2130"></div>

For as a sibling also causes the issue:

const TextInput: Component<any> = (props) => {
  return (
    <>
      <input {...props} data-test={props.cond ? props.x : 2} />
      <For each={[1, 2]}>{() => <div />}</For>
    </>
  );
};

Your Example Website or App

https://stackblitz.com/edit/nitrojs-nitro-uqjyhazp?file=src%2Fapp.tsx

Steps to Reproduce the Bug or Issue

1. Go to the link above
2. See console logs

Expected behavior

No hydration issue

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

No response

[ryansolid]

Fixed in dom-expressions 851ef225, which will ship with the next compiler release.

Root cause — the dom generate wrapped conditional attribute expressions merged into a spread (<svg {...rest} stroke-width={cond ? a : 2}>) in a client-only condition memo. The memo consumes a hydration id from the owner chain on the client, but the ssr generate emits the bare ternary and never allocates one — so every id after the spread drifts, and the <For> rows fail to claim their server-rendered nodes (the unclaimed-node warnings and duplicated rows you saw).

Fix — spread attribute getters now emit the bare expression on the dom generate, matching ssr and matching non-spread dynamic attributes (which never memoized). Nothing is lost: attribute values are primitives and the spread assign pass already dedupes writes against the previous value, so the memo only added per-read allocation churn.

While verifying, we found and fixed the same asymmetry in the other direction for component conditional props (<Comp title={cond ? a : b} />): the dom generate memoizes but ssr didn't. There the memo stays (prop values can be expensive) and the ssr generate now emits it too — the server sync memo allocates an owner id exactly like the client's, so ids stay aligned. Both fixes land identically in the Babel plugin and the Rust compiler, with fixture coverage for each position.