@barefootjs/jsx 0.33.2 → 0.33.3

package/src/props-binding.ts

@@ -68,3 +68,54 @@ export function buildPropAliasMap(params: readonly ParamInfo[]): Map<string, str
   }
   return map
 }
+
+/**
+ * The two component bindings that forward the caller's leftover props:
+ * the destructured `...rest` binding and a whole undestructured `(props)`
+ * parameter. Both phases carry these names — the analyzer context in
+ * Phase 1, the client-JS context in Phase 2 — so the resolver below takes
+ * them as data rather than binding to either context type.
+ */
+export interface RestSpreadBindings {
+  restPropsName: string | null
+  propsObjectName: string | null
+}
+
+/**
+ * Which of `bindings` the name `name` ultimately reaches, walking through
+ * any bare `const x__alias = <name>` hop recorded in `constantValues`
+ * (name → initializer text). `'rest'` for the destructured rest binding,
+ * `'props'` for the whole props object, `null` for anything else.
+ *
+ * The single definition of "this `{...spread}` forwards the caller's
+ * leftover props", shared by the two phases that must agree on it: Phase 1
+ * decides whether the host element gets a slot id (#2754 — without one the
+ * spread has no client-side patch point at all, so a pure CSR mount drops
+ * every caller-supplied attribute), and Phase 2 decides whether to route
+ * the spread to `applyRestAttrs` and filter it out of the template's
+ * `spreadAttrs({...})` merge. Two copies of the rule would let an element
+ * qualify for one and not the other, which is exactly the silent-drop
+ * shape #2754 reports.
+ *
+ * Walks hop by hop (not a precomputed set) so a multi-hop alias
+ * (`const p2 = props; const p3 = p2`) resolves through every link;
+ * `visited` guards a constant cycle (`const a = b; const b = a`). A
+ * constant whose value isn't a bare identifier on the chain (a real
+ * computed object) stops the walk, so a genuinely different spread
+ * expression is never mistaken for the rest object.
+ */
+export function resolveRestSpreadOriginCore(
+  bindings: RestSpreadBindings,
+  constantValues: ReadonlyMap<string, string | undefined>,
+  name: string,
+): 'rest' | 'props' | null {
+  const visited = new Set<string>()
+  let current: string | undefined = name.trim()
+  while (current !== undefined && !visited.has(current)) {
+    if (bindings.restPropsName && current === bindings.restPropsName) return 'rest'
+    if (bindings.propsObjectName && current === bindings.propsObjectName) return 'props'
+    visited.add(current)
+    current = constantValues.get(current)?.trim()
+  }
+  return null
+}

package/src/types.ts

@@ -348,19 +348,43 @@ export interface IRElement {
   slotId: string | null
   needsScope: boolean
   /**
-   * Set on the first ELEMENT among a `needsScopeComment` fragment root's own
-   * top-level children (#2732) — the fragment's five hydration markers
-   * (`bf-s`/`bf-h`/`bf-m`/`bf-r`/`bf-p`) move to the wrapping
-   * `<!--bf-scope:...-->` comment instead of an element attribute, but
-   * `data-key` has to stay on an element because the client runtime's
-   * `mapArray` adopt loop reads it as a DOM attribute
-   * (`primaryEl.dataset.key`, map-array.ts). "First element, not first
-   * node" mirrors the CSR runtime's own resolution of the identical
-   * ambiguity (`component.ts`'s `roots.find(isElement)`, #2735) rather than
-   * inventing a second answer. Always `undefined` when `needsScope` is
-   * true — the two are mutually exclusive ways of carrying the same key.
-   */
-  carriesDataKey?: boolean
+   * The row-key attribute this element carries, resolved ONCE here instead
+   * of independently by 16 emit sites (#2753 root-cause: the client
+   * runtime's `mapArray` stamping an index key onto unkeyed rows SSR never
+   * emits, and disagreeing with SSR's depth-suffixed name on nested rows —
+   * see that issue for the two measured shapes). Replaces the `carriesDataKey`
+   * boolean (#2732/#2744): a boolean was a degenerate encoding of the same
+   * decision — "does this element get a key attribute, and what is it
+   * called" — that still left the VALUE and the depth-derived NAME to be
+   * re-derived by every adapter (a mutable stack in Hono, a
+   * `currentLoopKeyDepth` field in every DSL adapter) and by the client
+   * runtime. Absent means "this element carries no key attribute" — the
+   * correct, final answer for an unkeyed loop's row, not a hint adapters
+   * still have to gate further.
+   *
+   * Two disjoint sources, both resolved at IR-build time
+   * (`resolveKeyAttrs`/loop construction in `jsx-to-ir.ts`):
+   *
+   *   - `value` present: this element is DIRECTLY a `.map()` row root
+   *     compiled inline in this same component (`IRLoop.key`/`.depth`
+   *     already resolved the expression and nesting depth) — adapters lower
+   *     `value` exactly like any other attribute-value expression.
+   *   - `value` absent: this element is one of the component's own possible
+   *     render roots (a plain element/if-statement-branch root, or — when
+   *     `needsScope` is false because hydration markers moved to a wrapping
+   *     `<!--bf-scope:...-->` comment (#2732) — the first eligible element
+   *     of a `needsScopeComment` fragment root) that RELAYS a key an
+   *     external caller supplies at runtime, when THIS component is itself
+   *     invoked as a caller's keyed loop row (the `data-key` prop / Rust
+   *     `bf.data_key` field, or client `createComponent`'s `key` argument).
+   *     There is no local expression to lower here, only a name.
+   *
+   * "First element, not first node" (for the fragment-root shape) mirrors
+   * the CSR runtime's own resolution of the identical ambiguity
+   * (`component.ts`'s `roots.find(isElement)`, #2735) rather than inventing
+   * a second answer.
+   */
+  keyAttr?: { name: string; value?: string }
   /**
    * Page-lifecycle boundary id for an element lowered from `<Region>`
    * (spec/router.md). Set only on region host elements; adapters emit it as
@@ -382,6 +406,16 @@ export interface IRExpression {
   expr: string
   /** Pre-transformed expr with destructured prop refs rewritten to _p.xxx (for client JS templates). */
   templateExpr?: string
+  /**
+   * Marks a VALUE moved into element content by a lowering (today only
+   * `lowerFormControlValueSsr`'s `<textarea>`, #2765) — client builders
+   * must escape it, unlike the normal pre-rendered-HTML `${...}` case.
+   *
+   * Not read via `templateExpr` instead: that field also rebinds to
+   * `_p.xxx`, which drops a destructured prop's `?? {}` default when the
+   * builder's output lives in init scope (`client-js-generation.test.ts`).
+   */
+  escapeInClientTemplate?: boolean
   /**
    * Structured parse of `expr` (`parseExpression(expr.trim())`), attached once
    * during IR construction so SSR adapters emit from the tree instead of each