@charcuterie/ui 0.2.0 → 1.0.1

package/src/LogViewer/LogViewer.tsx

@@ -35,7 +35,9 @@ export type LogViewerProps = {
  * Three repos render a scrolling log pane —
  * mux-magic's `JobLogsDisclosure` and `StepLogs`, rip-deck's
  * `LogModal` — and between them they have four defects that this
- * component exists to not have.
+ * component exists to not have. A fifth, below the effects, is not
+ * theirs: it is defect 1 coming back through the front door, in this
+ * component, found by the first app to consume it.
  *
  * ### 1. The one that follows nothing
  *
@@ -121,6 +123,70 @@ export const LogViewer = ({
     // for defect 1, and the dependency *is* the fix.
   }, [isFollowing, shownLines])
 
+  /**
+   * Defect 1 again, and the effect above cannot see it: **a pane can
+   * be measured before it has a box.**
+   *
+   * `AccordionSection` renders its panel with `hidden` rather than
+   * unmounting it, deliberately — "a panel that unmounts loses a
+   * scroll position, a partially typed form, and any subscription its
+   * content opened — and the fleet's log panes are exactly that." A
+   * `hidden` subtree has no layout, so the effect above runs on mount
+   * with `scrollHeight 0` and writes `scrollTop = 0`, and then never
+   * runs again: neither `isFollowing` nor `shownLines` changes when
+   * the section is opened. Measured in mux-magic on a 60-line pane:
+   *
+   * ```
+   * while collapsed : scrollTop 0   scrollHeight 0     clientHeight 0
+   * after expanding : scrollTop 0   scrollHeight 976   clientHeight 254
+   * ```
+   *
+   * That is this component's own `}, [])` bug, rebuilt out of two
+   * components whose individual decisions are both right, and
+   * invisible to both of their test suites — `LogViewer`'s mounted
+   * visible, `Accordion`'s holding content that never measures
+   * itself. mux-magic hit it in its first week as a consumer and
+   * worked around it downstream, in a `DisclosedLogViewer` that
+   * withheld the pane until the section had been opened once. This is
+   * that workaround coming into the library so it can be deleted.
+   *
+   * ### Why the box and not the viewport
+   *
+   * An `IntersectionObserver` answers "is it on screen", which is a
+   * different question with two wrong answers here: a pane below the
+   * fold on a long page is *not* intersecting and has perfectly good
+   * layout, and scrolling the page later would re-fire for no reason.
+   * `ResizeObserver` answers "does it have a box, and is that box
+   * still the same size" — which is the precondition the measurement
+   * above actually needs. Per spec it does not fire at `observe()`
+   * time for an element that is not being rendered, so gaining a box
+   * *is* the first callback, and that is the reveal.
+   *
+   * It pays for itself twice: a window resize re-wraps the lines and
+   * changes what is at the bottom, and a following pane should be at
+   * the new bottom rather than a few lines above it.
+   *
+   * Only while following. A user who scrolled up to read an error is
+   * not dragged back by resizing their window.
+   */
+  useEffect(() => {
+    const pane = paneRef.current
+
+    if (!pane || !isFollowing) {
+      return
+    }
+
+    const observer = new ResizeObserver(() => {
+      pane.scrollTop = pane.scrollHeight
+    })
+
+    observer.observe(pane)
+
+    return () => {
+      observer.disconnect()
+    }
+  }, [isFollowing])
+
   return (
     <div
       className={toClassName(

package/src/Menu/Menu.mdx

@@ -101,3 +101,26 @@ a keystroke buffer and a timer in a component that has neither, for a menu you c
 three arrow presses.
 
 <Canvas of={MenuStories.Interactive} />
+
+## One trigger, two slots
+
+A `Menu` and a `Tooltip` on the same button — the obvious thing to write, and until 1.0.1
+it did not work.
+
+Both components clone onto the trigger and both hand it a floating-ui
+`refs.setReference` — the element each of them positions its panel against. Every merge in
+the library was last-write-wins, so the inner `Tooltip` wrote its ref and the `Menu`'s was
+gone. A menu with no reference element is not an error: floating-ui simply leaves the panel
+at `left: 0; top: 0`, in the corner of the viewport, which reads as a CSS bug.
+
+A `ref` is a subscription and an `on*` is a listener, and neither survives being replaced.
+So both are **merged** now — between two slots by `mergeSlotWiring`, and between a slot and
+the element you wrote by `useClonedChild`, which is what makes
+`<Menu trigger={<Button ref={buttonRef} onClick={toggle} />} />` keep your ref *and* your
+handler.
+
+`SharedTrigger` is padded so the trigger sits away from the viewport origin: at the corner,
+an anchored panel and an unanchored one land in the same place, and the test asserts that
+padding is still there before it asserts anything else.
+
+<Canvas of={MenuStories.SharedTrigger} />

package/src/Menu/Menu.stories.tsx

@@ -13,6 +13,7 @@ import {
   SettingsIcon,
   UndoIcon,
 } from "../icons.storyHelpers.tsx"
+import { Tooltip } from "../Tooltip/Tooltip.tsx"
 import type { MenuItem } from "./Menu.tsx"
 import { Menu } from "./Menu.tsx"
 
@@ -72,6 +73,40 @@ const MenuHarness = ({
   )
 }
 
+/**
+ * The same harness, with a `Tooltip` between the `Menu` and the
+ * button — two components cloning onto **one** trigger, which is what
+ * image-viewer wanted and could not have.
+ */
+const TooltipTriggerHarness = ({
+  isInitiallyVisible = false,
+  tip,
+  triggerLabel,
+}: {
+  isInitiallyVisible?: boolean
+  tip: string
+  triggerLabel: string
+}): ReactNode => {
+  const { hide, isVisible, toggle } = useVisibility({
+    isVisible: isInitiallyVisible,
+  })
+
+  return (
+    <Menu
+      isVisible={isVisible}
+      items={BAY_ACTIONS}
+      onDismiss={hide}
+      trigger={
+        <Tooltip label={tip}>
+          <Button appearance="outline" onClick={toggle}>
+            {triggerLabel}
+          </Button>
+        </Tooltip>
+      }
+    />
+  )
+}
+
 const meta = {
   title: "Components/Menu",
   component: Menu,
@@ -143,6 +178,38 @@ export const AllStates: Story = {
   ),
 }
 
+/**
+ * **One trigger, two slots.** `Menu` and `Tooltip` both clone onto
+ * the button and both hand it a `ref` — floating-ui's
+ * `refs.setReference`, which is the anchor each of them positions
+ * against. Until 1.0.1 the second clone's ref simply replaced the
+ * first's, so the panel it belonged to had no anchor and rendered in
+ * the top-left corner of the viewport.
+ *
+ * Hover the button and open the menu: the tip and the panel are both
+ * attached to it.
+ */
+export const SharedTrigger: Story = {
+  args: {
+    isVisible: false,
+    onDismiss: noop,
+    trigger: <Button appearance="outline">Actions</Button>,
+  },
+  render: () => (
+    // Padded, and the padding is load-bearing rather than pretty: an
+    // anchor that has been dropped leaves floating-ui at
+    // `left: 0; top: 0`, so a trigger sitting in the corner of the
+    // viewport is a trigger where "anchored" and "not anchored" look
+    // identical. `Menu.test.tsx` asserts the padding is still here.
+    <div className="p-16">
+      <TooltipTriggerHarness
+        tip="Everything that can be done to this bay."
+        triggerLabel="Bay 5"
+      />
+    </div>
+  ),
+}
+
 /**
  * Open it and arrow down. Focus lands on the first item **on
  * opening** — a menu that leaves the caret on the trigger is one a

package/src/Menu/Menu.test.tsx

@@ -7,8 +7,12 @@ import { mountStory } from "../mountStory.testHelpers.ts"
 import { expectAgentDrivable } from "../testing/index.ts"
 import * as stories from "./Menu.stories.tsx"
 
-const { AllStates, AllVariants, Interactive } =
-  composeStories(stories)
+const {
+  AllStates,
+  AllVariants,
+  Interactive,
+  SharedTrigger,
+} = composeStories(stories)
 
 test("the menu is named, and its items are menuitems", async () => {
   const { canvas, canvasElement } =
@@ -200,3 +204,110 @@ test("the menu is not portalled out of its canvas", async () => {
 
   await expectNoAxeViolations(canvasElement)
 })
+
+/**
+ * **One trigger, two slots** — the defect image-viewer reported, and
+ * the one shape `mergeSlotProps` did not cover when it shipped in
+ * 1.0.0.
+ *
+ * `Menu` and `Tooltip` both clone onto the button and both hand it a
+ * floating-ui `refs.setReference`. That is not an attribute, so
+ * last-write-wins destroyed one of them: the inner `Tooltip` wrote
+ * its own and the `Menu` was left with **no reference element at
+ * all**. Nothing threw, nothing was unnamed, axe was clean, and the
+ * panel rendered at `left: 0; top: 0` — a positioning bug that reads
+ * as CSS.
+ *
+ * So the assertion is geometric, and it is the only kind that can
+ * see this: the panel is where the trigger is. Nothing in `Menu`
+ * writes that number — floating-ui computes it from the reference
+ * element, and a dropped ref means no reference element.
+ */
+const expectAnchoredTrigger = (trigger: HTMLElement) => {
+  const triggerRect = trigger.getBoundingClientRect()
+
+  // The precondition, stated rather than assumed. An unanchored
+  // panel lands at the viewport origin, so a trigger that also sits
+  // at the origin makes every assertion below pass for the wrong
+  // reason. The story's padding is what keeps them apart, and this
+  // is where its removal fails.
+  expect(triggerRect.left).toBeGreaterThan(32)
+
+  expect(triggerRect.top).toBeGreaterThan(32)
+
+  return triggerRect
+}
+
+test("a menu sharing its trigger with a tooltip is still anchored to it", async () => {
+  const { canvas, canvasElement } =
+    await mountStory(SharedTrigger)
+
+  const trigger = expectAgentDrivable(canvas, {
+    name: "Bay 5",
+    role: "button",
+  })
+
+  const triggerRect = expectAnchoredTrigger(trigger)
+
+  await userEvent.click(trigger)
+
+  const menu = await waitFor(() =>
+    expectAgentDrivable(canvas, { role: "menu" }),
+  )
+
+  // `bottom-start` with `offset(4)`: flush with the trigger's
+  // inline start, four pixels below it. Before the fix this read
+  // `left 0, top 0` — and it read that *forever*, so waiting for it
+  // costs a timeout rather than hiding a failure. The wait is for
+  // floating-ui's first position, which lands a frame after the
+  // panel does.
+  await waitFor(() => {
+    const menuRect = menu.getBoundingClientRect()
+
+    expect(Math.round(menuRect.left)).toBe(
+      Math.round(triggerRect.left),
+    )
+
+    expect(Math.round(menuRect.top)).toBe(
+      Math.round(triggerRect.bottom) + 4,
+    )
+  })
+
+  await expectNoAxeViolations(canvasElement)
+})
+
+/**
+ * The other ref, in the same composition — because a fix that
+ * reversed the priority instead of merging would leave *this* one
+ * pointing at nothing and the test above would still pass.
+ */
+test("the tooltip sharing that trigger is anchored to it too", async () => {
+  const { canvas } = await mountStory(SharedTrigger)
+
+  const trigger = expectAgentDrivable(canvas, {
+    name: "Bay 5",
+    role: "button",
+  })
+
+  const triggerRect = expectAnchoredTrigger(trigger)
+
+  trigger.focus()
+
+  const tip = await waitFor(() =>
+    expectAgentDrivable(canvas, { role: "tooltip" }),
+  )
+
+  // The **main axis** only: `top` with `offset(6)`. The cross axis
+  // is not asserted because `shift({ padding: 8 })` legitimately
+  // moves it — a 229px tip over a 71px button cannot be centred
+  // this close to the edge — and an assertion that has to allow for
+  // that is one an unanchored tip at the viewport origin would also
+  // satisfy. This one it cannot: unanchored reads `bottom 24`.
+  await waitFor(() => {
+    const tipRect = tip.getBoundingClientRect()
+
+    expect(Math.round(tipRect.bottom)).toBe(
+      Math.round(triggerRect.top) - 6,
+    )
+  })
+})

package/src/Popover/Popover.mdx

@@ -85,6 +85,11 @@ announces nothing.
 have. An extra `<div>` around it is how a toolbar's layout quietly changes, and it is why
 this is the pattern v1 chose and M2 ported.
 
+It **composes** rather than overwrites: your button's own `ref` and its own `onClick` are
+still called, with the popover's added. Until 1.0.1 they were replaced — silently, because a
+ref that is never called and a handler that never runs both look exactly like nothing
+happening.
+
 ## Escape *is* pressable here
 
 Unlike `Modal`'s. `useDismiss` listens for a keydown rather than relying on a UA default

package/src/Select/Select.stories.tsx

@@ -9,11 +9,19 @@ import { Field } from "../Field/Field.tsx"
 import type { SelectItem } from "./Select.tsx"
 import { Select } from "./Select.tsx"
 
-const PROFILES: SelectItem[] = [
+/**
+ * `as const satisfies`, which is a **typecheck** of the `readonly`
+ * widening as much as it is a story: a consumer's options table is
+ * usually a constant, and until 1.0.1 handing one to `options`
+ * failed with `TS4104` — image-viewer copied the array at every call
+ * site to get past it. If that widening is ever reverted, this line
+ * is where `yarn typecheck` says so.
+ */
+const PROFILES = [
   { label: "Lossless remux", value: "lossless" },
   { label: "Compressed 1080p", value: "compressed" },
   { isDisabled: true, label: "Dolby Vision", value: "dv" },
-]
+] as const satisfies readonly SelectItem[]
 
 const GROUPED: SelectItem[] = [
   {

package/src/Select/Select.tsx

@@ -23,7 +23,7 @@ export type SelectOption = {
 
 export type SelectOptionGroup = {
   label: string
-  options: SelectOption[]
+  options: readonly SelectOption[]
 }
 
 export type SelectItem = SelectOption | SelectOptionGroup
@@ -56,7 +56,15 @@ export type SelectProps = Omit<
    */
   label?: string
   onChange?: (value: string) => void
-  options: SelectItem[]
+  /**
+   * `readonly`, because a caller's list is usually a constant and
+   * TypeScript will not hand a `readonly` array to a mutable
+   * parameter — image-viewer hit `TS4104` on an `as const` options
+   * table and had to spread a copy at every call. This component
+   * only ever `.map`s over it, so demanding a mutable array was
+   * asking for a permission it never uses.
+   */
+  options: readonly SelectItem[]
   /**
    * A disabled first entry, not a real option. Reads as a prompt to
    * a sighted user and cannot be submitted, which is what a

package/src/Tooltip/Tooltip.tsx

@@ -17,9 +17,11 @@ import {
 } from "@floating-ui/react"
 import type { ReactElement, ReactNode } from "react"
 
+import type { SlotProps } from "../slotProps.ts"
+import { mergeSlotProps } from "../slotProps.ts"
 import { toClassName } from "../toClassName.ts"
 
-export type TooltipProps = {
+export type TooltipProps = SlotProps & {
   /**
    * The control the tip describes. **Cloned, not wrapped** — the
    * same slot contract as `Popover`'s trigger.
@@ -83,6 +85,19 @@ export type TooltipProps = {
  * anything a touch user *must* read belongs in a `Field`'s
  * `description` instead. Building a long-press would make the tip
  * load-bearing on exactly the surface where it is least reliable.
+ *
+ * ### A slot is a pass-through
+ *
+ * A `Tooltip` is the natural thing to put between a `Field` and its
+ * control — mux-magic's `FieldLabel` renders a `FieldTooltip` for
+ * exactly that reason. Both components clone onto their one child, so
+ * an outer `Field` used to hand *this component* the `id`,
+ * `aria-describedby`, `aria-invalid` and `required` meant for the
+ * `<input>`, and this component dropped all four without a word.
+ *
+ * Anything in `SlotProps` that arrives from above is forwarded to the
+ * trigger, and `aria-describedby` is **merged** with the tip's own id
+ * rather than overwriting it. `slotProps.ts` has the reasoning.
  */
 export const Tooltip = ({
   children,
@@ -90,6 +105,7 @@ export const Tooltip = ({
   delay = 200,
   label,
   placement = "top",
+  ...receivedSlotProps
 }: TooltipProps): ReactNode => {
   const { isVisible, setIsVisible } = useVisibility()
 
@@ -121,10 +137,18 @@ export const Tooltip = ({
       useRole(context, { role: "tooltip" }),
     ])
 
-  const clonedTrigger = useClonedChild(children, {
-    ...getReferenceProps(),
-    ref: refs.setReference,
-  })
+  const clonedTrigger = useClonedChild(
+    children,
+    // `mergeSlotProps` rather than a spread, because
+    // `getReferenceProps()` writes an `aria-describedby` of its own —
+    // `useRole` pointing the trigger at the tip — and an outer
+    // `Field` writes one naming its description and its error. A
+    // spread keeps whichever went last.
+    mergeSlotProps(receivedSlotProps, {
+      ...getReferenceProps(),
+      ref: refs.setReference,
+    }),
+  )
 
   return (
     <>

package/src/index.ts

@@ -68,6 +68,8 @@ export type {
 export { EmptyState } from "./EmptyState/EmptyState.tsx"
 export type { FieldProps } from "./Field/Field.tsx"
 export { Field } from "./Field/Field.tsx"
+export type { FieldGroupProps } from "./Field/FieldGroup.tsx"
+export { FieldGroup } from "./Field/FieldGroup.tsx"
 export type { FileDropZoneProps } from "./FileDropZone/FileDropZone.tsx"
 export { FileDropZone } from "./FileDropZone/FileDropZone.tsx"
 export type { IconButtonProps } from "./IconButton/IconButton.tsx"
@@ -145,6 +147,8 @@ export type {
 export { SortableTableHeader } from "./SortableTableHeader/SortableTableHeader.tsx"
 export type { SpinnerProps } from "./Spinner/Spinner.tsx"
 export { Spinner } from "./Spinner/Spinner.tsx"
+export type { SlotProps } from "./slotProps.ts"
+export { mergeSlotProps } from "./slotProps.ts"
 export {
   getAsyncIntent,
   getAsyncLabel,

package/src/slotProps.ts

@@ -0,0 +1,163 @@
+import type { InputHTMLAttributes } from "react"
+
+import { mergeSlotWiring } from "./slotWiring.ts"
+
+/**
+ * The props a **cloning ancestor** injects into the control below it.
+ *
+ * `Field` and `Tooltip` both take one child and `cloneElement` onto
+ * it — "cloned, not wrapped", which is what lets a `Field` go around
+ * an `<input>`, a `Select`, or an app's own control without changing
+ * that control's layout. The contract has a hole in it the moment two
+ * of them are nested:
+ *
+ * ```tsx
+ * <Field label="Pattern" isRequired>
+ *   <Tooltip label="A JavaScript regular expression">
+ *     <input />
+ *   </Tooltip>
+ * </Field>
+ * ```
+ *
+ * `Field` clones onto the **`Tooltip` element**, so `id`,
+ * `aria-describedby`, `aria-invalid` and `required` are handed to a
+ * component that declares none of them — and `cloneElement` does not
+ * care. React drops them without a warning, TypeScript never sees
+ * them (`Children.only` returns a `ReactElement` with `any` props),
+ * every test still passes, and the render is pixel-identical. The
+ * `<label>` then points at an `id` that is nowhere in the document.
+ *
+ * **Silent prop-dropping is the worst version of this**, so the rule
+ * is: *a slot component is a pass-through*. Anything in `SlotProps`
+ * that arrives from above is forwarded to the child this component
+ * clones onto, so a chain of slots behaves like the one control at
+ * the bottom of it.
+ *
+ * ### The list is closed, the forwarding is not
+ *
+ * Worth being exact, because the two are easy to conflate. This type
+ * is a closed list of five keys rather than an index signature: it is
+ * exactly the wiring `Field` writes plus the wiring `Tooltip` writes,
+ * it is greppable, and it is the set whose **merge semantics are
+ * defined** — which for four of them is last-write-wins and for
+ * `aria-describedby` is a join.
+ *
+ * The *runtime* forwards everything. Both components collect their
+ * received props with a rest spread and `mergeSlotProps` starts from
+ * `...receivedProps`, so an ancestor's `onPointerEnter`, its
+ * `onFocus`, its `ref` — none of which are named here — reach the
+ * control at the bottom too. That is not an oversight, it is load
+ * bearing: a `Tooltip` around a `Field` hands down `useHover`,
+ * `useFocus`, `useDismiss` and `refs.setReference`, and a `Field`
+ * that forwarded only the five keys below would leave the tip with no
+ * trigger and no anchor. A closed *runtime* filter would be
+ * mux-magic's `FieldTooltip` defect rebuilt inside the fix for it.
+ *
+ * The five keys, and who writes them:
+ *
+ * | Key | Written by |
+ * | --- | --- |
+ * | `aria-describedby` | `Field` (its description and its error) **and** `Tooltip` (its tip) — the one key that is a list, and the reason `mergeSlotProps` exists |
+ * | `aria-invalid` | `Field`, derived from `error` being present |
+ * | `aria-required` | `Field`, from `isRequired` — the announced constraint, for a composite control the browser does not validate |
+ * | `id` | `Field`, so its `<label htmlFor>` has something to point at. A caller may also pass one directly, which is how a consumer pins a stable id for a deep link or an autofill hint |
+ * | `required` | `Field`, from `isRequired` — the constraint the browser validates |
+ *
+ * ### Why these are `Pick`ed and not written out
+ *
+ * Three of the five are booleans whose names cannot start with `is`
+ * or `has`, because they are not our names — they are the DOM's, and
+ * they are spread onto a DOM node verbatim. The house rule has
+ * [no carve-out](../../../docs/decisions/2026-07-29-is-has-rule-has-no-external-api-carve-out.md)
+ * for that: a *type property* is a shape we own, an object literal
+ * key is someone else's contract, and no `eslint-disable` is
+ * available because unused disable directives are themselves an
+ * error.
+ *
+ * So this type does not declare a shape. It **selects** one out of
+ * React's own `InputHTMLAttributes`, which is the honest description
+ * of what it is: five keys of the props React already types for an
+ * `<input>`, forwarded unchanged. The same reasoning as the
+ * `Record<string, boolean>` in `createReactAdapter` — we are not
+ * describing React's shape, we are naming the keys of it we touch —
+ * and it has the side benefit that `aria-invalid` gets React's real
+ * type (`"grammar"` and `"spelling"` are legal values) rather than
+ * the `boolean` a hand-written version would have narrowed it to.
+ */
+export type SlotProps = Pick<
+  InputHTMLAttributes<HTMLElement>,
+  | "aria-describedby"
+  | "aria-invalid"
+  | "aria-required"
+  | "id"
+  | "required"
+>
+
+/**
+ * Merge what arrived from above with what this component writes
+ * itself.
+ *
+ * Everything here is a single value and last-write-wins is correct
+ * for it — **except `aria-describedby`, which is a list**. Two slot
+ * components each writing their own onto one control is the entire
+ * nesting problem in one attribute: a `Field` naming its description
+ * and its error, and a `Tooltip` naming its tip. A plain spread keeps
+ * one of them and loses the other, which is the same silent drop by a
+ * shorter route.
+ *
+ * **Outer first.** A screen reader reads the list in order, and the
+ * field's own description and error are the control's primary
+ * explanation; a tip is supplementary by construction. The ordering
+ * inside a single `Field` — description, then error — is `Field`'s
+ * own concern and is unaffected.
+ *
+ * `undefined` in `ownProps` is *absence*, not an instruction to
+ * clear. Both callers spell their optional wiring as
+ * `isRequired || undefined`, so a plain spread would let an inner
+ * `Field` with no error erase an outer one's `aria-invalid` — the
+ * same silent drop, one level down.
+ *
+ * ### The wiring is not a value, and does not last-write-win
+ *
+ * `ref` and the `on*` handlers are merged rather than replaced, by
+ * `mergeSlotWiring`. This was the 1.0.0 hole: `mergeSlotProps`
+ * settled the five *attributes* and left the two props that are not
+ * attributes on last-write-wins, so a `Menu` and a `Tooltip` on one
+ * trigger each handed it a floating-ui `refs.setReference` and the
+ * inner one won. The outer panel had no anchor and rendered in the
+ * corner of the viewport — no error, no failing test, and it looks
+ * like a CSS bug.
+ */
+export const mergeSlotProps = <
+  OwnProps extends Record<string, unknown>,
+>(
+  receivedProps: SlotProps,
+  ownProps: OwnProps,
+): OwnProps & SlotProps => {
+  const definedOwnProps = Object.fromEntries(
+    Object.entries(ownProps).filter(
+      ([, value]) => value !== undefined,
+    ),
+  ) as OwnProps
+
+  const describedBy = [
+    receivedProps["aria-describedby"],
+    ownProps["aria-describedby"],
+  ]
+    .filter(Boolean)
+    .join(" ")
+
+  return {
+    ...receivedProps,
+    ...definedOwnProps,
+    "aria-describedby":
+      describedBy === "" ? undefined : describedBy,
+    // Last, because it is the only merge that has to beat
+    // `definedOwnProps` — it is composing what that spread would
+    // otherwise have thrown away.
+    ...mergeSlotWiring(
+      receivedProps as Record<string, unknown>,
+      definedOwnProps,
+    ),
+  }
+}