@uniflowed/ui 0.0.0-alpha.2 → 0.0.0-alpha.37

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/menu-tree.js

@@ -0,0 +1,228 @@
+// @flow
+//
+// What every menu in this package is a menu *of*.
+//
+// `menu.js` was one module because there was one menu. shadcn ships four
+// components on this behaviour — a dropdown menu, a context menu, a menubar and
+// the checkable items all three of them share — and the three that are not the
+// dropdown differ from it in exactly two places: what opens the menu, and where
+// the menu goes. Everything between those two — the tree of open levels, what
+// `Escape` closes, what "choosing an item" dismisses, which selector finds an
+// item and which finds its owner — is one set of rules, and this is it.
+//
+// Written down here rather than exported from `menu.js` for the reason every
+// other module in `internal/` gives: these are relationships the components
+// build, not a menu-building kit. `MENU_SELECTOR` is only true because
+// `Menu.Body` renders `role="menu"`; handed to a consumer it would be a
+// selector that happens to work.
+//
+// # A menu is a chain, not a flag
+//
+// A submenu is a menu whose parent is another menu, and almost every rule that
+// distinguishes the two is a statement about that chain:
+//
+//   * `Escape` closes *one* level, so it needs to know which one it is in.
+//   * Choosing an item closes the whole chain, because leaving the parent menu
+//     open after a command has run is a state no native menu has been in.
+//   * Only the outermost level listens for a press outside, because a submenu
+//     closes with the tree and two listeners would each answer one press.
+//
+// So the chain is the shape the context carries, and `parent` is what a level
+// is given rather than something it works out.
+//
+// # Where a menu goes, when it is not against its trigger
+//
+// A context menu opens at the pointer, which is a *point* and not an element.
+// `MenuAnchorContext` is how a level says so: a rectangle that replaces the
+// trigger's own measurement inside `internal/anchor.js`, and nothing else — the
+// trigger element is still what the writing direction is read from and what
+// focus goes back to. A level with no provider above it measures its trigger,
+// which is every menu that hangs off a button.
+
+"use client";
+
+import * as React from "@uniflowed/react";
+import {
+  createContext,
+  useContext,
+  useEffect,
+  useId,
+  useMemo,
+  useRef,
+  useState,
+} from "@uniflowed/react";
+
+import type { Rect } from "./anchor.js";
+import type { Direction } from "./roving-focus.js";
+import { useControlled } from "./controlled-state.js";
+
+/**
+ * Anything that plays the part of a menu item, including the two checkable
+ * kinds. The keyboard has to move between all of them, so the selector names
+ * all of them rather than only the plain command.
+ */
+export const ITEM_SELECTOR: string =
+  '[role="menuitem"], [role="menuitemcheckbox"], [role="menuitemradio"]';
+
+/** What owns an item: the nearest menu, so a submenu keeps its own. */
+export const MENU_SELECTOR: string = '[role="menu"]';
+
+/**
+ * Which arrow key opens a submenu, and which closes it.
+ *
+ * The WAI-ARIA menu pattern puts a submenu on the *inline end*, so it opens to
+ * the right of a left-to-right menu and to the left of a right-to-left one, and
+ * the key that opens it is the one pointing at it. Written out as
+ * `ArrowRight` to open and `ArrowLeft` to close, an RTL reader pressed the key
+ * aimed at the submenu and closed the menu they were standing in — which is
+ * worse than nothing happening, because it loses their place.
+ */
+export function submenuKeys(direction: Direction): {|
+  readonly open: string,
+  readonly close: string,
+|} {
+  return direction === "rtl"
+    ? { open: "ArrowLeft", close: "ArrowRight" }
+    : { open: "ArrowRight", close: "ArrowLeft" };
+}
+
+export type MenuState = {|
+  readonly base: string,
+  readonly open: boolean,
+  readonly setOpen: (open: boolean) => void,
+  /** What opened this menu, and what focus goes back to when it closes. */
+  readonly triggerRef: { current: HTMLElement | null },
+  /**
+   * Which end the menu should open onto, written by whatever opened it.
+   *
+   * A ref rather than state because it is an instruction for the next commit,
+   * not a value anything renders: `ArrowUp` on a closed menu opens it *and*
+   * lands on the last item, and re-rendering the trigger to say so would be a
+   * render whose only purpose is to carry a message to an effect.
+   */
+  readonly pendingFocus: { current: "first" | "last" | null },
+  /** The menu this one hangs off, or null for the outermost. */
+  readonly parent: MenuState | null,
+  /**
+   * Whether a trigger is rendered *and* is something worth naming the menu
+   * after, so the body only claims a name that exists.
+   *
+   * A menu opened by `defaultOpen` in a page that never renders a trigger is a
+   * real arrangement, and an `aria-labelledby` pointing at the id that trigger
+   * *would* have had makes a screen reader announce nothing at all. A context
+   * menu's trigger is arbitrary content rather than a label, and registers
+   * itself as a trigger without registering itself as a name.
+   */
+  readonly triggered: boolean,
+  readonly registerTrigger: (present: boolean) => void,
+|};
+
+export const MenuContext: React.Context<MenuState | null> = createContext(null);
+
+/**
+ * The roving tab stop of one open menu.
+ *
+ * Provided by `Menu.Body` rather than by the root, because a submenu is a
+ * second list with a tab stop of its own: nesting the provider is what stops
+ * the parent menu and the submenu from fighting over which item is `tabindex=0`.
+ */
+export type MenuListState = {|
+  readonly activeId: string | null,
+  readonly setActiveId: (id: string | null) => void,
+|};
+
+export const MenuListContext: React.Context<MenuListState | null> = createContext(null);
+
+/**
+ * A box a menu body is placed against instead of its trigger's own.
+ *
+ * `null`, and no provider at all, both mean "measure the trigger". See the
+ * module header, and `AnchorRequest.anchorRect` for what it replaces.
+ */
+export const MenuAnchorContext: React.Context<Rect | null> = createContext(null);
+
+export hook useMenu(part: string): MenuState {
+  const state = useContext(MenuContext);
+  if (state == null) {
+    throw new Error(`${part} must be rendered inside a Menu.Root`);
+  }
+  return state;
+}
+
+/**
+ * Tell the menu that something worth naming it after is in the document.
+ *
+ * `Menu.Body` names its trigger with `aria-labelledby`, and it may only do that
+ * while there is one to name — a menu opened by `defaultOpen` in a page with no
+ * trigger would otherwise point at an id nothing has, and a screen reader given
+ * a dangling `aria-labelledby` announces nothing at all rather than falling back
+ * to the element's own content.
+ */
+export hook useTriggerRegistration(menu: MenuState): void {
+  const register = menu.registerTrigger;
+  useEffect(() => {
+    register(true);
+    return () => register(false);
+  }, [register]);
+}
+
+/** Every menu from `menu` outwards, innermost first. */
+export function ancestry(menu: MenuState): Array<MenuState> {
+  const chain = [];
+  let at: MenuState | null = menu;
+  while (at != null) {
+    chain.push(at);
+    at = at.parent;
+  }
+  return chain;
+}
+
+/**
+ * Close this menu and every menu it hangs off.
+ *
+ * Choosing an item in a submenu dismisses the whole thing — leaving the parent
+ * menu open after a command has run is a state no native menu has ever been in,
+ * and it leaves the reader looking at a menu whose action already happened.
+ */
+export function closeTree(menu: MenuState): void {
+  for (const each of ancestry(menu)) {
+    each.setOpen(false);
+  }
+}
+
+/**
+ * One level of the menu tree.
+ *
+ * Shared by `Menu.Root`, `Menu.Sub`, `ContextMenu.Root` and `Menubar.Menu`,
+ * which differ only in what they hand it: a submenu knows its parent, and a
+ * menubar's menu is opened and closed by the bar rather than by itself.
+ */
+export component MenuLevel(
+  children: React.Node,
+  parent: MenuState | null,
+  defaultOpen: boolean,
+  open?: boolean,
+  onOpenChange?: (open: boolean) => void,
+) {
+  const base = useId();
+  const [isOpen, setOpen] = useControlled(open, defaultOpen, onOpenChange);
+  const triggerRef = useRef<HTMLElement | null>(null);
+  const pendingFocus = useRef<"first" | "last" | null>(null);
+  const [triggered, setTriggered] = useState(false);
+
+  const state = useMemo(
+    () => ({
+      base,
+      open: isOpen,
+      setOpen,
+      triggerRef,
+      pendingFocus,
+      parent,
+      triggered,
+      registerTrigger: setTriggered,
+    }),
+    [base, isOpen, setOpen, parent, triggered],
+  );
+
+  return <MenuContext.Provider value={state}>{children}</MenuContext.Provider>;
+}