@uniflowed/ui 0.0.0-alpha.10

package/internal/focus.js

@@ -0,0 +1,64 @@
+// @flow
+//
+// What a reader can reach, in the order they reach it.
+//
+// One list, asked for by two components that want opposite things from it.
+// `Dialog.Body` uses it to keep focus *in*: the first and last entries are
+// where `Tab` and `Shift+Tab` wrap. `Popover.Body` uses it to put focus in
+// once and then leaves it alone, because tabbing out of a popover is how a
+// reader leaves one. The list has to be the same list for those two to be
+// describable as different policies over the same fact rather than as two
+// components that disagree about what focusable means.
+//
+// # The selector is the browser's rule, written down
+//
+// A disabled control is out because the browser will not focus one, and
+// `tabindex="-1"` is out because it means "focusable by script, not by Tab" —
+// which is what every roving tab stop in this package uses, so a menu inside a
+// dialog would otherwise report thirty items as focus stops and the trap would
+// wrap between two of them instead of at the dialog's edges.
+//
+// The three ancestor checks are the ones a selector cannot make. `hidden`,
+// `inert` and `aria-hidden="true"` each hide a whole subtree, and reading them
+// off the element alone returned a button inside `<div aria-hidden="true">` as
+// a focus stop — after which the trap moved focus to a control no screen
+// reader exposes and the reader was somewhere they could not be told about.
+//
+// # Why this is `internal/` and not a subpath
+//
+// The same reason `merge-props.js` gives. A public `focusable()` is a
+// general-purpose DOM utility, and a second, weaker copy of one is how two
+// parts of a package come to disagree about which elements exist. What is
+// shipped here is narrower: the definition this package's focus behaviour is
+// written against.
+
+/**
+ * The elements a browser will move focus to with `Tab`.
+ *
+ * Exported as the selector as well as through `focusable`, because one
+ * question is asked about a single element rather than about a subtree: a
+ * tooltip's trigger has to *be* one of these or the tooltip is one only a mouse
+ * can reach, and `element.matches(FOCUS_STOPS)` is that question.
+ */
+export const FOCUS_STOPS: string =
+  'a[href], button:not([disabled]), input:not([disabled]), select:not([disabled]), textarea:not([disabled]), [tabindex]:not([tabindex="-1"])';
+
+/**
+ * The focus stops inside an element, in document order.
+ *
+ * Document order rather than mount order, for the reason
+ * `internal/roving-focus.js` gives about items: the two stop agreeing the first
+ * time something is rendered conditionally, and the reader's `Tab` follows the
+ * document.
+ */
+export function focusable(root: HTMLElement): Array<HTMLElement> {
+  return Array.from(root.querySelectorAll(FOCUS_STOPS)).filter(
+    (element: $FlowFixMe) =>
+      // All three hide a whole subtree, so all three are asked of the
+      // ancestors; see the module header for what reading them off the element
+      // alone let through.
+      element.closest("[hidden]") == null &&
+      element.closest("[inert]") == null &&
+      element.closest('[aria-hidden="true"]') == null,
+  );
+}

package/internal/form-value.js

@@ -0,0 +1,83 @@
+// @flow
+//
+// What a `<form>` submits for a control the browser has never heard of.
+//
+// Every widget in this package is a `button` or a `div` wearing an ARIA role,
+// which is what makes it styleable and what makes it invisible to form
+// submission: `new FormData(form)` collects the form's *listed* elements, and a
+// `<div role="listbox">` is not one. So a Select inside a form submitted
+// nothing at all, and a Combobox submitted `Combobox.Input`'s value — which is
+// the label the reader sees and not the value the application meant. A country
+// picker posted "United Kingdom" where the server was waiting for `GB`.
+//
+// The fix is one hidden `<input>` carrying the real value, rendered only when
+// the caller asked for one by giving a `name`. No `name`, no control: a Select
+// used to drive a filter has nothing to submit, and a form field the caller
+// never named is not one this package should invent.
+//
+// # Why a hidden input and not a hidden `<select>`
+//
+// Rendering a real, visually hidden `<select>` is the other answer, and it buys
+// two things: the browser autofills it, and `required` gets native constraint
+// validation. Both were tried and neither survives contact with the
+// accessibility tree.
+//
+// A `<select>` is focusable, so it is announced. A reader who tabs into the
+// widget hears the styled combobox and then a second, invisible combobox with
+// the same options — the duplicate-announcement bug that makes people describe
+// a component library as "noisy". Taking it out of the tree means
+// `aria-hidden="true"`, and `aria-hidden` on a focusable element is itself the
+// violation: it hides the element from a screen reader while leaving it in the
+// tab order, so the reader lands on something their software says is not there.
+// `tabindex="-1"` plus `aria-hidden` closes that hole and gives up the tab
+// order, which is the autofill affordance the native control was for.
+//
+// And native validation cannot work here either. The browser reports a
+// constraint failure by focusing the invalid control and drawing a bubble at
+// it; on a control with no box, Chrome logs "An invalid form control with
+// name='country' is not focusable" and refuses to submit the form at all, with
+// nothing shown to the reader. A headless select's `required` therefore belongs
+// to `@uniflowed/form` and `@uniflowed/validator`, which is where uf already
+// put every other rule, and `Field.Error` is where the message goes.
+//
+// An `<input type="hidden">` is none of those things: never focusable, never in
+// the accessibility tree, never validated, and always submitted. What it costs
+// is autofill, which is a real loss and is written down rather than hidden —
+// a browser will not fill a hidden input the way it fills `<select
+// name="country">`.
+//
+// # This is not how `@uniflowed/form` reads a value
+//
+// Worth stating because the two look like they overlap and do not.
+// `@uniflowed/form` holds values in its own store and calls `preventDefault()`
+// on submit, so it never builds a `FormData` and never sees this element. A
+// Select bound to that library is bound through `useController` — `field.value`
+// into `value`, `field.onChange` into `onValueChange` — and needs no `name`
+// here at all. This element is for the other kind of form: a plain `<form
+// action={…}>`, a Server Action, or anything else that submits the document.
+//
+// # Why this is `internal/` and not a subpath
+//
+// It is one sentence about what this package promises a form, and the failure
+// mode of writing it twice is that Select and Combobox disagree about what a
+// disabled control submits. Exported, it would be a `<HiddenInput>` a consumer
+// could reach for in a component that had not thought about any of the above.
+
+"use client";
+
+/**
+ * The control a form actually reads.
+ *
+ * `value` is the widget's value, not its label. `null` renders an empty string
+ * rather than omitting the control, so a form that submits a Select the reader
+ * left alone still carries the field — a key missing from the payload and a key
+ * present and empty are different questions to a server, and "the reader saw
+ * this field and chose nothing" is the second one.
+ *
+ * `disabled` is passed through rather than interpreted: a disabled control is
+ * omitted from the submission by the browser, which is the behaviour a native
+ * `<select disabled>` has and the one a caller who disabled the widget expects.
+ */
+export component FormValue(name: string, value: string | null, disabled?: boolean = false) {
+  return <input disabled={disabled} name={name} type="hidden" value={value ?? ""} />;
+}

package/internal/hover-intent.js

@@ -0,0 +1,259 @@
+// @flow
+//
+// What WCAG requires of anything that appears because a pointer or focus
+// arrived, which is a tooltip and a hover card and nothing else in this
+// package.
+//
+// SC 1.4.13, *Content on Hover or Focus*, is three clauses, and a hand-written
+// tooltip fails all three. They are not a matter of taste and they are not
+// separable, so they live in one module:
+//
+//   * **Dismissible** — `Escape` removes it without moving the pointer. The
+//     content never holds focus, so the key never reaches it: the listener has
+//     to be on the document, which is `useDismissOnEscape` below.
+//   * **Hoverable** — the pointer can travel from the trigger onto the content
+//     without it vanishing on the way. That is why leaving schedules a close
+//     rather than performing one, and why arriving anywhere cancels it. A
+//     component that closes on `pointerleave` snatches the content away from a
+//     reader who was moving towards it — including every reader who magnifies
+//     the screen, for whom the trip is long.
+//   * **Persistent** — it stays until it is dismissed or the pointer and focus
+//     have both left. A timer that closes it on its own is out.
+//
+// The opening delay is not one of the three clauses; it is what makes the
+// component bearable. A pointer crossing a toolbar enters six triggers on its
+// way somewhere else, and a tooltip that opened on each would be six
+// interruptions. **A delay belongs to the pointer and not to focus**: a reader
+// who tabbed to a control has already said what they want, and making them wait
+// for it is a delay with nothing to prevent.
+//
+// # The clock is a ref, and `useTimeout` is deliberately not used
+//
+// `@uniflowed/hooks/timing` has the hook this looks like it wants, and its
+// contract is not this one: `useTimeout(body, millis)` sets its timer in an
+// effect keyed on `millis`, so asking again for the *same* delay does not
+// restart it. Every interesting sequence here asks twice — enter, leave,
+// enter — and with an open delay equal to the close delay the second request
+// would inherit the first request's deadline and fire early. What is wanted is
+// "restart the clock", which is a command rather than a state, so it is written
+// as one.
+//
+// # Why this is `internal/` and not a subpath
+//
+// It is not a `useHoverIntent` for anybody to build a tooltip with; it is the
+// half of `tooltip.js` and `hover-card.js` that has to be the same in both. A
+// consumer given a copy could build the component that closes on
+// `pointerleave`, which is the failure this exists to prevent.
+
+import { useEffect, useMemo, useRef } from "@uniflowed/react";
+import { useStableCallback } from "@uniflowed/hooks/lifecycle";
+
+import { FOCUS_STOPS } from "./focus.js";
+
+/** How long a pointer must rest on a trigger before its tooltip opens. */
+export const DEFAULT_OPEN_DELAY: number = 700;
+
+/**
+ * How long the content stays after the pointer leaves.
+ *
+ * This is the hoverable clause's whole implementation: the gap between a
+ * trigger and its overlay takes a moment to cross, and a reader who is crossing
+ * it has not left.
+ */
+export const DEFAULT_CLOSE_DELAY: number = 300;
+
+/**
+ * How long after one tooltip closes the next one opens with no delay.
+ *
+ * A reader who has waited out the delay once has established that they are
+ * reading tooltips; the second icon in a toolbar should answer immediately.
+ */
+export const DEFAULT_SKIP_DELAY: number = 300;
+
+/** Opening and closing, on a clock that can be restarted or called off. */
+export type HoverIntent = {|
+  /** Open after `millis`, or in this tick when that is nought. */
+  readonly openAfter: (millis: number) => void,
+  /** Close after `millis`, or in this tick when that is nought. */
+  readonly closeAfter: (millis: number) => void,
+  /** Forget whatever was scheduled. Arriving anywhere calls this first. */
+  readonly cancel: () => void,
+|};
+
+/**
+ * A group of tooltips that share one clock.
+ *
+ * `Tooltip.Provider` holds it; `Tooltip.Root` asks it what delay to use. A
+ * tooltip outside a provider never sees one and uses its own delay, which is
+ * the behaviour a tooltip on its own has always had.
+ */
+export type DelayGroup = {|
+  /** `own`, or nought while the group is inside its skip window. */
+  readonly delayFor: (own: number) => number,
+  /** Told that a tooltip in the group has opened. */
+  readonly opened: () => void,
+  /** Told that one has closed, which is what starts the window. */
+  readonly closed: () => void,
+|};
+
+/**
+ * A pending open or close, restartable, and cancelled when the component goes.
+ *
+ * `setOpen` is called with the answer rather than with a toggle, so a schedule
+ * that is overtaken by a second one does not leave the component holding the
+ * first one's opinion.
+ */
+export hook useHoverIntent(setOpen: (open: boolean) => void): HoverIntent {
+  const timer = useRef<TimeoutID | null>(null);
+  const change = useStableCallback(setOpen);
+
+  const cancel = useStableCallback(() => {
+    if (timer.current != null) {
+      clearTimeout(timer.current);
+      timer.current = null;
+    }
+  });
+
+  const schedule = useStableCallback((open: boolean, millis: number) => {
+    cancel();
+    if (millis <= 0) {
+      // In this tick, not in a zero-millisecond timeout. A tooltip that opens
+      // on focus, and the second tooltip in a toolbar, both have to be open by
+      // the time the event handler returns — a test that has to advance a clock
+      // to see them is describing a wait the reader would also have had.
+      change(open);
+      return;
+    }
+    timer.current = setTimeout(() => {
+      timer.current = null;
+      change(open);
+    }, millis);
+  });
+
+  // The component can be taken away while a tooltip is waiting to open, and a
+  // timer that outlives it sets state on something that is gone.
+  useEffect(() => cancel, [cancel]);
+
+  return useMemo(
+    () => ({
+      cancel,
+      closeAfter: (millis: number) => schedule(false, millis),
+      openAfter: (millis: number) => schedule(true, millis),
+    }),
+    [cancel, schedule],
+  );
+}
+
+/**
+ * The shared clock behind `Tooltip.Provider`.
+ *
+ * Refs rather than state, and that is the whole design: nothing here is
+ * rendered. A group that held "are we skipping" in state would re-render every
+ * tooltip in a toolbar twice for each one the pointer passed over, to change
+ * nothing anybody can see.
+ *
+ * The window is open while a tooltip in the group is showing — moving along a
+ * toolbar with one already open is the case that must not stutter — and for
+ * `skipDelay` after the last one closes.
+ */
+export hook useDelayGroup(skipDelay: number): DelayGroup {
+  const skipping = useRef(false);
+  const timer = useRef<TimeoutID | null>(null);
+
+  const stop = useStableCallback(() => {
+    if (timer.current != null) {
+      clearTimeout(timer.current);
+      timer.current = null;
+    }
+  });
+
+  useEffect(() => stop, [stop]);
+
+  return useMemo(
+    () => ({
+      closed: () => {
+        stop();
+        if (skipDelay <= 0) {
+          skipping.current = false;
+          return;
+        }
+        skipping.current = true;
+        timer.current = setTimeout(() => {
+          timer.current = null;
+          skipping.current = false;
+        }, skipDelay);
+      },
+      delayFor: (own: number) => (skipping.current ? 0 : own),
+      opened: () => {
+        // While one is open the group is answering instantly, and the window
+        // does not start counting down until it closes.
+        stop();
+        skipping.current = true;
+      },
+    }),
+    [skipDelay, stop],
+  );
+}
+
+/**
+ * Close on `Escape`, from wherever focus happens to be.
+ *
+ * On the document, because the content shown on hover holds no focus and a
+ * handler on it would never be reached — which is exactly why the hand-written
+ * version fails the dismissible clause rather than implementing it wrongly.
+ *
+ * Capture, and `stopPropagation`, so one `Escape` is one dismissal: a tooltip
+ * inside a dialog answers the key itself rather than leaving the reader with a
+ * dialog that closed because a tooltip was showing.
+ */
+export hook useDismissOnEscape(
+  open: boolean,
+  ref: { current: HTMLElement | null },
+  onDismiss: () => void,
+): void {
+  const dismiss = useStableCallback(onDismiss);
+
+  useEffect(() => {
+    const document = ref.current?.ownerDocument;
+    if (!open || document == null) {
+      return;
+    }
+    const onKeyDown = (event: $FlowFixMe) => {
+      if (event.key !== "Escape") {
+        return;
+      }
+      event.stopPropagation();
+      dismiss();
+    };
+    document.addEventListener("keydown", onKeyDown, true);
+    return () => document.removeEventListener("keydown", onKeyDown, true);
+  }, [open, ref, dismiss]);
+}
+
+/**
+ * Refuse a trigger the keyboard cannot reach.
+ *
+ * A tooltip on a `<span>` is a tooltip only a mouse can find, and it looks
+ * perfect: the markup is right, the styles are right, and a reader who never
+ * touches a mouse is told nothing at all. It is the failure this package exists
+ * to make loud, so it is an error rather than a warning — the same answer
+ * `useDialog` gives to a part outside its root.
+ *
+ * Checked in an effect because it is a question about an element, and the
+ * element does not exist until one has been committed.
+ */
+export hook useFocusableTrigger(ref: { current: HTMLElement | null }, part: string): void {
+  useEffect(() => {
+    const element = ref.current;
+    if (element == null || element.matches(FOCUS_STOPS)) {
+      return;
+    }
+    throw new Error(
+      `${part} must be something the keyboard can reach: it was rendered onto ` +
+        `<${element.tagName.toLowerCase()}>, which is not focusable, so the ` +
+        `content would only ever appear for a pointer. Render a button or a ` +
+        `link, or give the element a tabindex of 0. A disabled control is not ` +
+        `focusable either: use aria-disabled and keep it in the tab order.`,
+    );
+  }, [ref, part]);
+}

package/internal/merge-props.js

@@ -0,0 +1,201 @@
+// @flow
+//
+// One rule about prop order, stated once.
+//
+// `<div {...rest} role="dialog">` and `<div role="dialog" {...rest}>` are
+// different components. The second lets a caller pass `role="button"` and get
+// it; the first does not. That sounds like a matter of taste until you notice
+// what else arrives in `rest`:
+//
+//   * A caller `ref` replaced the ref the dialog uses to find its focus stops,
+//     so `bodyRef.current` stayed null, the Tab handler returned early, and the
+//     focus trap was *silently off* while the dialog still announced
+//     `aria-modal="true"`.
+//   * A caller `onClick` replaced a tab's selection handler, so clicking a tab
+//     did nothing.
+//   * A caller `onKeyDown` replaced the dialog's, so Escape stopped closing it.
+//
+// None of those fail loudly. So the rule is: the caller's props go on first and
+// the component's own semantics go on last, and for the two kinds of prop where
+// a caller legitimately wants *both* — event handlers and refs — they are
+// composed rather than one replacing the other.
+//
+// # Why this is `internal/` and not a subpath
+//
+// It is not a "props utils" module and there is nothing else in it. It is the
+// one policy every part of this package applies, extracted so that a new
+// primitive cannot quietly apply a different one. Exporting it would invite a
+// consumer to build a part that spreads `rest` last, which is the failure this
+// exists to prevent — so it stays unreachable from outside the package.
+
+/**
+ * Props on their way onto an element: what a caller hands a part, and what
+ * `Field.Control` hands back for a caller to spread.
+ *
+ * `key` is named out of the indexer rather than left to it, and that one
+ * property is the whole subtlety of this type. React takes `key` off the
+ * attributes before a component is called, so a part's props never contain
+ * one — but an indexer does not know that, and `{ readonly [string]: mixed }`
+ * answers `mixed` for every name, `key` included. React's `key` is
+ * `string | number`, so every intrinsic this package rendered was rejected for
+ * a property that cannot be there:
+ *
+ *     error[incompatible-type]: Cannot create button element because in
+ *     property key: Either unknown is incompatible with string. Or unknown is
+ *     incompatible with number.
+ *
+ * thirty-two times, one per element, which was 32 of `@uniflowed/ui`'s 73 type
+ * errors. `key?: empty` states what React already guarantees, and the errors
+ * are the checker agreeing.
+ *
+ * # Two answers that look better than they are
+ *
+ * **`readonly key?: string | number`** — React's own type for the property —
+ * also silences the error, and is a lie in the shape of a fix. It says a
+ * caller may pass a `key` here; a part would then spread it onto its element,
+ * which is the "spreading a key into JSX" mistake React 19 added a warning
+ * for. `empty` is the same repair and a true sentence. It reads oddly for
+ * about a second and then reads as exactly what it is: there is no value you
+ * can pass under this name.
+ *
+ * **`React.PropsOf<"button">`** — the props of the element actually being
+ * rendered, which is what this type would like to say — cannot be written
+ * here. uf does not merge Flow's `jsx.js` environment, deliberately and for
+ * reasons `crates/uf_check/src/upstream/environments.rs` gives, so
+ * `$JSXIntrinsics` is the bare-bones table in `lib/react.js`, every
+ * intrinsic's `props` is `any`, and `React.PropsOf` itself reads as an
+ * any-typed value. Nothing about an element is checked here except its `key`:
+ * `<button className={5} nonsenseAttr={{}} />` is not an error today. A named
+ * type per element would therefore not be React's contract but a hand-written
+ * copy of `jsx.js` living in a UI package, drifting from the DOM on its own
+ * schedule — and it would still need an indexer for `data-*` and `aria-*`,
+ * which is where this started. So it stays one `Rest`, and the day
+ * `$JSXIntrinsics` is real is the day this becomes `React.PropsOf` and the
+ * parts say which element they render.
+ */
+export type Rest = { readonly key?: empty, readonly [string]: mixed };
+
+/**
+ * A caller's props on their way to another *part of this package*, rather than
+ * onto an intrinsic element.
+ *
+ * `Rest` names `key` out of its indexer and types it `empty`, which is a true
+ * sentence and is what stopped thirty-two intrinsics being rejected for a
+ * property that cannot be there. It has a second consequence, and it only shows
+ * up the first time one part of this package renders another —
+ * `ToggleGroup.Root` rendering a `RadioGroup.Root`, which is how `single` mode
+ * avoids being a second copy of the radio group. Creating
+ * `<RadioGroup.Root {...rest} />` has Flow check the props object against that
+ * component's own `...rest: Rest`, `key` included, and the indexer answers
+ * `mixed` for it rather than the named `empty`:
+ *
+ *     error[incompatible-type]: Cannot create RadioGroupRoot element because in
+ *     property key: unknown is incompatible with empty.
+ *
+ * So a part is spreadable onto a `<div>` and not onto a sibling part. That is a
+ * hole in the type rather than a fact about the props, and this is the one
+ * place it is papered over — a named function rather than an `as $FlowFixMe` at
+ * the call site, so there is somewhere to say what is and is not lost.
+ *
+ * What is lost is nothing that was ever checked. Every element this package
+ * renders has `any`-typed props today, for the reason `Rest` gives above: uf
+ * does not merge Flow's `jsx.js` environment, so `$JSXIntrinsics` is the
+ * bare-bones table in `lib/react.js` and `key` is the only property of an
+ * element anything verifies. On the day that changes and `Rest` becomes
+ * `React.PropsOf`, this function is what gets deleted.
+ */
+export function forwarded(rest: Rest): $FlowFixMe {
+  return rest;
+}
+
+/**
+ * Call the caller's handler and then the component's.
+ *
+ * The caller's runs first so it can inspect the event before the component acts
+ * on it, and the component's runs unless the caller stopped the event —
+ * `defaultPrevented` is the caller's way of saying "I handled this", which is
+ * the same contract the DOM uses.
+ */
+export function composeHandlers<TEvent extends { readonly defaultPrevented?: boolean }>(
+  theirs: mixed,
+  ours: (event: TEvent) => mixed,
+): (event: TEvent) => mixed {
+  if (typeof theirs !== "function") {
+    return ours;
+  }
+  return (event: TEvent) => {
+    (theirs as $FlowFixMe)(event);
+    if (event.defaultPrevented !== true) {
+      ours(event);
+    }
+  };
+}
+
+/** Set both refs, whichever kinds they are. */
+export function composeRefs<T>(
+  theirs: mixed,
+  ours: (value: T | null) => mixed,
+): (value: T | null) => void {
+  return (value: T | null) => {
+    ours(value);
+    if (typeof theirs === "function") {
+      (theirs as $FlowFixMe)(value);
+    } else if (theirs != null && typeof theirs === "object") {
+      (theirs as $FlowFixMe).current = value;
+    }
+  };
+}
+
+/**
+ * Two sets of props, the component's on top.
+ *
+ * The same rule as everywhere else in this package, applied where the element
+ * is the *caller's* rather than the component's: `Tooltip.Trigger` and
+ * `HoverCard.Trigger` hand their attributes to a render function so a caller
+ * can put them on a link or a menu item of their own, and the attributes that
+ * make the trigger work — the `aria-describedby` naming the content, the ref
+ * the content is measured against — have to survive whatever the caller passed
+ * alongside them.
+ *
+ * A spread would say this in one line and cannot be written: Flow declines to
+ * compute a type for `{ ...base, name: value }` when `base` has an indexer,
+ * because the indexer may overwrite the named key in a way it cannot track.
+ * The loop is that spread, with `key` dropped for the reason `withoutComposed`
+ * gives.
+ */
+export function withProps(base: Rest, ours: Rest): Rest {
+  const merged: { key?: empty, [string]: mixed } = {};
+  for (const name of Object.keys(base)) {
+    if (name !== "key") {
+      merged[name] = base[name];
+    }
+  }
+  for (const name of Object.keys(ours)) {
+    if (name !== "key") {
+      merged[name] = ours[name];
+    }
+  }
+  return merged;
+}
+
+/**
+ * A caller's props with the handlers and ref removed.
+ *
+ * They are pulled out because they have to be composed rather than spread, and
+ * leaving them in would put the caller's copy back on top of the composed one.
+ */
+export function withoutComposed(rest: Rest, names: $ReadOnlyArray<string>): Rest {
+  const kept: { key?: empty, [string]: mixed } = {};
+  for (const name of Object.keys(rest)) {
+    // `key` is dropped whatever the caller asked to compose, because it is the
+    // one name the indexer does not speak for: writing `rest[name]` under it
+    // would put a `mixed` back where `Rest` promises nothing can be, and Flow
+    // says so. Nothing is lost — React removed the `key` long before this ran,
+    // so this is the type-level statement made at runtime rather than a filter
+    // that ever has work to do.
+    if (name !== "key" && !names.includes(name)) {
+      kept[name] = rest[name];
+    }
+  }
+  return kept;
+}