@chassis-ui/react 0.2.0 → 0.4.0

package/src/utils/comboboxCollection.tsx

@@ -1,152 +0,0 @@
-import React, { ComponentType, ReactElement, ReactNode } from 'react'
-import { Item, Key, Section } from 'react-stately'
-
-import { ComboboxGroupProps } from '../components/combobox/ComboboxGroup'
-import { ComboboxItem, ComboboxItemProps } from '../components/combobox/ComboboxItem'
-import { MenuItemsDef } from '../components/menu/MenuItemDef'
-import { renderMenuItemContent } from './renderMenuItemContent'
-
-// Shared between Combobox.tsx/ComboboxListBox.tsx (which build/render this collection) and
-// Autocomplete.tsx (which reuses the same entry shape — see the comment on
-// `buildEntriesFromChildren` below). Lives in `utils/` rather than `components/combobox/` because
-// it crosses that folder boundary; kept in its own file to also avoid a circular import between
-// Combobox.tsx and ComboboxListBox.tsx.
-
-export type ComboboxItemElement = ReactElement<ComboboxItemProps>
-
-export interface ComboboxGroupEntry {
-  entryType: 'group'
-  key: Key
-  label: ReactNode
-  items: ComboboxItemElement[]
-}
-
-export type ComboboxEntry = ComboboxItemElement | ComboboxGroupEntry
-
-// `useComboBoxState`/`useComboBox`'s own `SelectionMode` ('single' | 'multiple') isn't
-// re-exported from react-stately's public entry point (only `ComboBoxState` etc. are) — this is
-// a structurally-identical stand-in so `ComboboxListBox` can stay generic over it without a
-// fragile deep import.
-export type ComboboxSelectionMode = 'single' | 'multiple'
-
-export const isComboboxGroupEntry = (entry: ComboboxEntry): entry is ComboboxGroupEntry =>
-  (entry as ComboboxGroupEntry).entryType === 'group'
-
-// `Autocomplete`'s own `AutocompleteItem`/`AutocompleteGroup` are structurally identical to
-// `ComboboxItem`/`ComboboxGroup` (see AutocompleteItem.tsx/AutocompleteGroup.tsx — kept as
-// separate named types only so `Autocomplete`'s public API doesn't leak `Combobox`'s own prop
-// type), but they're different *runtime* component identities, which is what
-// `buildEntriesFromChildren` below needs to check consumer-authored `children` against. Passing
-// the pair in lets one implementation serve both families instead of two near-duplicate copies.
-export interface ComboboxCollectionComponents {
-  Group: ComponentType<ComboboxGroupProps>
-  Item: ComponentType<ComboboxItemProps>
-}
-
-// Splits `children` into a flat, ordered list of entries — bare `Item` elements and
-// `Group`-wrapped clusters of them — mirroring how `useComboBoxState`'s dynamic collection needs
-// top-level nodes: some rendered as a plain `<Item>`, some as a `<Section>` wrapping several
-// `<Item>`s (see `comboboxCollectionChildren` below).
-export const buildEntriesFromChildren = (
-  children: ReactNode,
-  { Group, Item: ItemComponent }: ComboboxCollectionComponents
-): ComboboxEntry[] => {
-  const entries: ComboboxEntry[] = []
-  React.Children.forEach(children, (child, index) => {
-    if (!React.isValidElement(child)) return
-    if (child.type === Group) {
-      const groupProps = child.props as ComboboxGroupProps
-      const items: ComboboxItemElement[] = []
-      React.Children.forEach(groupProps.children, (groupChild) => {
-        if (React.isValidElement(groupChild) && groupChild.type === ItemComponent) {
-          items.push(groupChild as ComboboxItemElement)
-        }
-      })
-      entries.push({ entryType: 'group', key: `group-${index}`, label: groupProps.label, items })
-      return
-    }
-    if (child.type === ItemComponent) {
-      entries.push(child as ComboboxItemElement)
-    }
-  })
-  return entries
-}
-
-// Same shape as `buildEntriesFromChildren`, from a flat `MenuItemsDef` instead. A `'header'`
-// entry opens a new group that all following items join until the next header (or the end of
-// the array) — matching how chassis-css itself renders grouped items (flat siblings, no
-// wrapping element per group). `'divider'` entries aren't meaningful for a listbox/option
-// collection and are skipped.
-//
-// Always builds a bare `ComboboxItem` internally regardless of which family (`Combobox` or
-// `Autocomplete`) called it: unlike `buildEntriesFromChildren`, nothing downstream re-checks
-// these elements' runtime type (they're read only via `.props.*`, never matched against a
-// component reference again), so there's no need to thread `ComboboxCollectionComponents`
-// through here too. `def.href`/`def.onClick` are intentionally not read — see the doc comments on
-// `MenuItemDef` itself for why: they're `Menu`-only fields on this shared type.
-export const buildEntriesFromItemsDef = (defs: MenuItemsDef): ComboboxEntry[] => {
-  const entries: ComboboxEntry[] = []
-  let currentGroup: ComboboxGroupEntry | null = null
-
-  defs.forEach((def) => {
-    if (def.type === 'divider') return
-    if (def.type === 'header') {
-      currentGroup = { entryType: 'group', key: def.id, label: def.label, items: [] }
-      entries.push(currentGroup)
-      return
-    }
-    const item = (
-      <ComboboxItem
-        key={def.id}
-        id={def.id}
-        disabled={def.disabled}
-        icon={def.icon}
-        description={def.description}
-        textValue={def.textValue}
-      >
-        {def.label}
-      </ComboboxItem>
-    )
-    if (currentGroup) currentGroup.items.push(item)
-    else entries.push(item)
-  })
-
-  return entries
-}
-
-export const getDisabledKeys = (entries: ComboboxEntry[]): Key[] =>
-  entries.reduce<Key[]>((keys, entry) => {
-    const items = isComboboxGroupEntry(entry) ? entry.items : [entry]
-    return keys.concat(items.filter((item) => item.props.disabled).map((item) => item.props.id))
-  }, [])
-
-// Builds the react-stately `Item` node `useComboBoxState`'s collection actually renders from one
-// entry's props — identical for `Combobox` and `Autocomplete` regardless of which authoring
-// component (`ComboboxItem`/`AutocompleteItem`) produced it, since both share the same prop shape.
-export const renderComboboxCollectionItem = (item: ComboboxItemElement) => (
-  <Item
-    key={item.props.id}
-    textValue={
-      item.props.textValue ??
-      (typeof item.props.children === 'string' ? item.props.children : undefined)
-    }
-  >
-    {renderMenuItemContent({
-      icon: item.props.icon,
-      label: item.props.children,
-      description: item.props.description
-    })}
-  </Item>
-)
-
-// `useComboBoxState`'s own `children` render prop, given one `ComboboxEntry` — a plain `Item` for
-// a bare entry, a `Section` wrapping its items for a group. Identical for `Combobox` and
-// `Autocomplete`'s state setup.
-export const comboboxCollectionChildren = (entry: ComboboxEntry) =>
-  isComboboxGroupEntry(entry) ? (
-    <Section key={entry.key} title={entry.label} items={entry.items}>
-      {renderComboboxCollectionItem}
-    </Section>
-  ) : (
-    renderComboboxCollectionItem(entry)
-  )

package/src/utils/dateRangePresets.ts

@@ -1,6 +0,0 @@
-import { DateValue, RangeValue } from 'react-aria'
-
-export interface DateRangePreset {
-  label: string
-  range: RangeValue<DateValue>
-}

package/src/utils/devWarning.ts

@@ -1,58 +0,0 @@
-// Development-only misuse warnings, in one place so every component reports misuse the same way
-// and none of it reaches a consumer's production bundle.
-//
-// Two problems this fixes over calling `console.warn` directly, which is what every call site used
-// to do:
-//
-// 1. **They fired in production.** Nothing in this package guarded on `NODE_ENV`, so every
-//    `console.warn` ran for end users of a consuming app. `process.env.NODE_ENV` is the idiom
-//    bundlers (Vite, webpack, Turbopack, Rollup) replace with a literal, so in a production build
-//    `IS_DEV` folds to `false` and no warning is ever emitted. Relying on that substitution adds
-//    no new constraint: `react-dom` — a peer dependency, so always present — already requires
-//    exactly the same replacement.
-// 2. **They repeated.** Most call sites warn during render, so a warning re-fired on every
-//    re-render, and twice per render under StrictMode's double-invoke. De-duplicating on the
-//    message means a misuse is reported once and stays readable in the console.
-//
-// What this does *not* do is strip the message strings from the bundle. Measured with esbuild
-// against the built `dist/index.js`: a `NODE_ENV=production` consumer bundle still contains them.
-// `tsdown` minifies this package's own output first (`minify: true`), collapsing each function to
-// a `IS_DEV && cond && ...` expression, and a consumer's minifier won't then inline that call to
-// discover its arguments are droppable. Building unminified would let them drop, at the cost of
-// shipping pretty-printed dist — not worth it for a few hundred gzipped bytes. The behavior that
-// mattered (nothing logged in production, nothing repeated in development) is the part that's
-// fixed; treat the strings as part of the bundle's fixed cost.
-const IS_DEV = process.env.NODE_ENV !== 'production'
-
-const warned = new Set<string>()
-
-/**
- * Resets the de-duplication set. Test-only — the suite asserts on these warnings, and without a
- * reset between tests the *second* test in a file to trigger the same message would see nothing.
- * Called from a global `beforeEach` in `test/setup.ts`.
- */
-export function resetDevWarnings(): void {
-  warned.clear()
-}
-
-/**
- * Logs `message` once via `console.warn` when `condition` is true, in development builds only.
- * Use for a recoverable misuse: the component still renders something sensible.
- */
-export function devWarning(condition: boolean, message: string): void {
-  if (!IS_DEV) return
-  if (!condition || warned.has(message)) return
-  warned.add(message)
-  console.warn(message)
-}
-
-/**
- * Logs `message` once via `console.error` when `condition` is true, in development builds only.
- * Use for a misuse that leaves the component genuinely broken (e.g. a required prop missing).
- */
-export function devError(condition: boolean, message: string): void {
-  if (!IS_DEV) return
-  if (!condition || warned.has(message)) return
-  warned.add(message)
-  console.error(message)
-}

package/src/utils/dialogTransition.ts

@@ -1,39 +0,0 @@
-// Shared transition timing for native <dialog>-based components (Modal, Drawer). Body-scroll
-// locking is handled by react-aria's usePreventScroll directly in each component.
-
-export const getTransitionDuration = (element: HTMLElement) => {
-  const { transitionDuration, transitionDelay } = window.getComputedStyle(element)
-  const duration = Number.parseFloat(transitionDuration) || 0
-  const delay = Number.parseFloat(transitionDelay) || 0
-  if (!duration && !delay) return 0
-  return (duration + delay) * 1000
-}
-
-export const executeAfterTransition = (
-  element: HTMLElement,
-  callback: () => void,
-  animated: boolean
-) => {
-  if (!animated) {
-    callback()
-    return () => undefined
-  }
-
-  let called = false
-  const done = () => {
-    if (called) return
-    called = true
-    element.removeEventListener('transitionend', handleEnd)
-    clearTimeout(timer)
-    callback()
-  }
-  const handleEnd = (event: Event) => {
-    if (event.target === element) done()
-  }
-  element.addEventListener('transitionend', handleEnd)
-  const timer = setTimeout(done, getTransitionDuration(element) + 50)
-  return () => {
-    element.removeEventListener('transitionend', handleEnd)
-    clearTimeout(timer)
-  }
-}

package/src/utils/direction.ts

@@ -1,14 +0,0 @@
-/**
- * Whether `element` renders right-to-left.
- *
- * Reads the *computed* direction rather than react-aria's `useLocale()`. The two are deliberately
- * separate signals in this library (see the Internationalization docs page): `useLocale()` follows
- * `I18nProvider`, and drives locale-dependent behavior like which calendar system to use;
- * everything about visual layout — including which physical arrow key moves "forward" through a
- * horizontally-laid-out control — follows the `dir` attribute, which is what `getComputedStyle`
- * resolves here. A page can set one without the other, and for arrow-key navigation it's the
- * rendered order the user sees that has to match.
- */
-export function isRTL(element: Element): boolean {
-  return getComputedStyle(element).direction === 'rtl'
-}

package/src/utils/focusRedirect.ts

@@ -1,23 +0,0 @@
-import { suppressFocusRing } from './suppressFocusRingGlobally'
-
-// Safari shows a `:focus-visible` ring on an element focused via script even when the
-// interaction that triggered the script was a real pointer click — unlike Chromium/Firefox,
-// which correctly suppress it in that case. Force the ring off for a pointer-triggered redirect,
-// then let normal focus-visible behavior resume the next time this element is genuinely
-// (re)focused, e.g. via Tab.
-//
-// The suppress/restore cycle itself is `suppressFocusRing`'s, not reimplemented here: it owns the
-// re-entrancy guard that keeps a second call before the element blurs from capturing the
-// already-suppressed value as the one to restore (which left the ring off for good — reachable by
-// clicking twice at the same disabled end of a `ends="stop"` carousel). `boxShadow` is suppressed
-// alongside `outline` here, but not on the global pointerdown path, because a redirect can land
-// on an element whose ring is painted that way.
-export function focusRedirect(
-  el: HTMLElement | null,
-  viaPointer: boolean,
-  focusOptions?: FocusOptions
-): void {
-  if (!el) return
-  if (viaPointer) suppressFocusRing(el, ['outline', 'boxShadow'])
-  el.focus(focusOptions)
-}

package/src/utils/iconConfig.ts

@@ -1,88 +0,0 @@
-import { ComponentType, createContext, ReactElement } from 'react'
-
-/**
- * The icons this library's own components draw, by purpose rather than by icon name — so a
- * consumer can map each one onto any icon set (see `IconProvider`'s `icons`).
- */
-export type IconKey = 'check' | 'previous' | 'next' | 'menu' | 'play' | 'pause'
-
-/**
- * An icon given to `IconProvider`'s `icons` or to a component's icon prop: a string is an icon
- * name, rendered by `IconProvider`'s `component` (or the built-in `Icon`); an element is rendered
- * as-is, with the component's own class names merged onto it.
- */
-export type IconValue = string | ReactElement
-
-/**
- * Props `IconProvider`'s `component` receives for every icon name it's asked to render.
- */
-export interface IconComponentProps {
-  /**
-   * The icon name — an `IconValue` string, or `IconProvider`'s default for that icon.
-   */
-  name: string
-  /**
-   * The class names the rendering component needs on the icon (e.g. `menu-item-check`,
-   * `directional-icon`) for chassis-css to position and flip it.
-   */
-  className?: string
-  [prop: string]: unknown
-}
-
-export interface IconConfig {
-  /**
-   * Class names added to every `Icon`, alongside its own `icon` class.
-   */
-  className?: string
-  /**
-   * Replaces the built-in `Icon` for every icon this library's components render by name — the
-   * strings in `icons` and their defaults, and a string `icon` on `Toast`/`Notification`. A
-   * component reference can't be passed from a React Server Component, so set this in a
-   * `'use client'` module.
-   */
-  component?: ComponentType<IconComponentProps>
-  /**
-   * Render `Icon` as an icon-font glyph instead of an SVG sprite reference, unless an `Icon` sets
-   * `font` itself. Needs the icon font's stylesheet loaded.
-   */
-  font?: boolean
-  /**
-   * Class-name prefix of the icon font's glyphs: an icon named `check-solid` renders as
-   * `{fontPrefix}check-solid`.
-   *
-   * @default 'cx-'
-   */
-  fontPrefix?: string
-  /**
-   * The icon to render for each of the library's own icons, by purpose. Unset ones keep their
-   * defaults (`check-solid`, `chevron-left-outline`, `chevron-right-outline`, `bars-outline`,
-   * `play-solid`, `pause-solid`).
-   */
-  icons?: Partial<Record<IconKey, IconValue>>
-  /**
-   * URL of the SVG sprite `Icon` references, e.g. `/static/icons/chassis-icons.svg`. Leave empty
-   * (the default) when the sprite is embedded in the page, so icons render as `href="#name"`.
-   * Browsers don't load an external sprite from another origin.
-   *
-   * @default ''
-   */
-  sprite?: string
-}
-
-// The chassis-icons names this library used before its icons became configurable. Both
-// previous/next consumers (Pagination, Carousel) now share the outline chevrons — Pagination used
-// the solid ones.
-export const DEFAULT_ICONS: Record<IconKey, string> = {
-  check: 'check-solid',
-  previous: 'chevron-left-outline',
-  next: 'chevron-right-outline',
-  menu: 'bars-outline',
-  play: 'play-solid',
-  pause: 'pause-solid'
-}
-
-export const DEFAULT_FONT_PREFIX = 'cx-'
-
-// Lives in `utils/` rather than `components/icon/` because it's read outside that folder too —
-// by `IconSlot` (`./iconSlot.tsx`), which every icon-drawing component renders through.
-export const IconContext = createContext<IconConfig>({})

package/src/utils/iconSlot.tsx

@@ -1,41 +0,0 @@
-import React, { cloneElement, ReactElement } from 'react'
-import { mergeProps } from 'react-aria'
-
-import { Icon } from '../components/icon/Icon'
-import { useIconConfig } from '../hooks/useIconConfig'
-import { DEFAULT_ICONS, IconKey, IconValue } from './iconConfig'
-
-// Every icon this library's own components draw goes through here, never through `<Icon>`
-// directly, so a consumer can swap in their own icons (`IconProvider`'s `icons`/`component`, or a
-// component's own icon prop). The rendering component passes the class names chassis-css hooks
-// onto (`menu-item-check` positions the check, `navbar-toggler-icon` sizes and colors it,
-// `carousel-icon-play`/`-pause` are toggled by state, `directional-icon` flips in RTL); those are
-// merged onto whatever icon ends up rendered, so a custom icon lands in the same place a built-in
-// one would. `aria-hidden` defaults on: each of these icons sits beside its own visible or
-// visually-hidden label.
-//
-// A custom *element* deliberately doesn't get the `icon` class itself: chassis-css's `.icon` sets
-// `fill`, which would paint over an outline icon set's `fill="none"` (Lucide, Heroicons outline,
-// ...). It keeps its own size and color — `currentColor` icons still follow the control's text.
-type IconRenderProps = { className?: string } & Record<string, unknown>
-
-export function ResolvedIcon({ value, ...props }: IconRenderProps & { value: IconValue }) {
-  const { component: Component } = useIconConfig()
-  const iconProps = { 'aria-hidden': true, ...props }
-
-  if (typeof value !== 'string') {
-    const element = value as ReactElement<Record<string, unknown>>
-    return cloneElement(element, mergeProps(iconProps, element.props))
-  }
-  if (Component) return <Component name={value} {...iconProps} />
-  return <Icon name={value} {...iconProps} />
-}
-
-export function IconSlot({
-  icon,
-  override,
-  ...props
-}: IconRenderProps & { icon: IconKey; override?: IconValue }) {
-  const { icons } = useIconConfig()
-  return <ResolvedIcon value={override ?? icons?.[icon] ?? DEFAULT_ICONS[icon]} {...props} />
-}

package/src/utils/isWholeUnitDisabled.ts

@@ -1,17 +0,0 @@
-import { CalendarState, RangeCalendarState } from 'react-stately'
-import { CalendarDate, toCalendarDate } from '@internationalized/date'
-
-// Shared by `CalendarMonthGrid` and `CalendarYearGrid` — a month/year button is disabled when
-// every day it covers falls outside `minValue`/`maxValue`, not just when its first day does (e.g.
-// a `maxValue` of March 15th still leaves March itself partly selectable, so March's button stays
-// enabled; April's doesn't). `unitEnd` is the last day of the button's own month/year.
-export const isWholeUnitDisabled = (
-  state: CalendarState<'single' | 'multiple'> | RangeCalendarState,
-  unitStart: CalendarDate,
-  unitEnd: CalendarDate
-): boolean => {
-  if (state.isDisabled) return true
-  if (state.maxValue && unitStart.compare(toCalendarDate(state.maxValue)) > 0) return true
-  if (state.minValue && unitEnd.compare(toCalendarDate(state.minValue)) < 0) return true
-  return false
-}

package/src/utils/mergeIsDateUnavailable.ts

@@ -1,15 +0,0 @@
-import { DateValue } from 'react-stately'
-
-// `date.toString()` on a `CalendarDate` (the only `DateValue` variant `Calendar`/`DatePicker`
-// ever produce — both are date-only, no time segments) yields the same ISO 8601 `YYYY-MM-DD`
-// string already used elsewhere for form submission (see `DatePicker`'s hidden input), so
-// `unavailableDates` entries are expected in that same format.
-export const mergeIsDateUnavailable = (
-  unavailableDates: string[] | undefined,
-  isDateUnavailable: ((date: DateValue) => boolean) | undefined
-): ((date: DateValue) => boolean) | undefined => {
-  if (!unavailableDates?.length && !isDateUnavailable) return undefined
-
-  const set = unavailableDates?.length ? new Set(unavailableDates) : null
-  return (date) => Boolean(set?.has(date.toString())) || Boolean(isDateUnavailable?.(date))
-}

package/src/utils/overlayPlacement.ts

@@ -1,93 +0,0 @@
-import type { CSSProperties } from 'react'
-import type { Placement as AriaPlacement, PlacementAxis } from 'react-aria'
-
-// Chassis CSS's floating components (`.menu`, `.tooltip`, `.popover`) read a `data-cx-placement`
-// attribute in this hyphenated, compound form (`"bottom-end"`, `"top-start"`, ...) to pick the
-// right transform-origin for the open/close animation. React Aria's `useOverlayPosition` speaks a
-// different, space-separated placement vocabulary (`"bottom end"`) and only reports back the
-// resolved main axis after flipping, not the full compound value — this module bridges the two.
-export type Placement =
-  | 'top'
-  | 'top-start'
-  | 'top-end'
-  | 'bottom'
-  | 'bottom-start'
-  | 'bottom-end'
-  | 'left'
-  | 'left-start'
-  | 'left-end'
-  | 'right'
-  | 'right-start'
-  | 'right-end'
-
-const ARIA_PLACEMENT: Record<Placement, AriaPlacement> = {
-  top: 'top',
-  'top-start': 'top start',
-  'top-end': 'top end',
-  bottom: 'bottom',
-  'bottom-start': 'bottom start',
-  'bottom-end': 'bottom end',
-  left: 'left',
-  'left-start': 'left top',
-  'left-end': 'left bottom',
-  right: 'right',
-  'right-start': 'right top',
-  'right-end': 'right bottom'
-}
-
-// Translates chassis-react's public `placement` prop values into the strings
-// `useOverlayPosition` expects.
-export const toAriaPlacement = (placement: Placement): AriaPlacement => ARIA_PLACEMENT[placement]
-
-// `useOverlayPosition`'s own `shouldFlip` only ever swaps the main axis (top<->bottom or
-// left<->right) — it never changes the requested cross-axis alignment — so the resolved compound
-// value is always the requested cross-axis suffix reattached to the (possibly flipped) main axis
-// `useOverlayPosition` reports back.
-export const resolveDataPlacement = (
-  requested: Placement,
-  resolvedMain: PlacementAxis | null
-): string => {
-  if (!resolvedMain || resolvedMain === 'center') return requested
-  const cross = requested.split('-')[1]
-  return cross ? `${resolvedMain}-${cross}` : resolvedMain
-}
-
-// Shared between `Menu`/`MenuSubmenu` and `Combobox`/`Autocomplete`, whose floating panels all
-// position via `useOverlayPosition` the same way: only `position`/`top`/`left` are taken from the
-// hook's computed style (`zIndex`/`maxHeight` stay owned by chassis-css's own `--zindex`/
-// `--max-height` tokens, see `_menu.scss`), and `data-cx-placement` needs the resolved main axis
-// reattached to the originally-requested cross-axis alignment. Lives here (rather than
-// `components/menu/`) for the same reason `renderMenuItemContent` does — `Combobox.tsx`/
-// `Autocomplete.tsx` need it too, and importing across that folder boundary from three call sites
-// is worse than housing it where none of the four has to reach into a sibling's folder.
-export interface MenuOverlayPositioning {
-  menuStyle: CSSProperties
-  placementAttr: string
-}
-
-export const resolveMenuOverlayPositioning = (
-  overlayStyle: CSSProperties | undefined,
-  requestedPlacement: Placement,
-  resolvedPlacement: PlacementAxis | null
-): MenuOverlayPositioning => ({
-  menuStyle: {
-    position: overlayStyle?.position,
-    top: overlayStyle?.top,
-    left: overlayStyle?.left
-  },
-  placementAttr: resolveDataPlacement(requestedPlacement, resolvedPlacement)
-})
-
-// chassis-css's `.combobox + .menu` sibling-selector rule (`_combobox.scss`) sets
-// `--menu-max-height`/`--menu-overflow-y` from `$combobox-menu-max-height`/
-// `$combobox-menu-overflow-y` (320px/auto by default) — but only while the panel is an adjacent
-// DOM sibling of `.combobox`. `Autocomplete`/`Combobox` portal their panel to `document.body` (or
-// an enclosing open `<dialog>`, via `useFloatingOverlay`), breaking that adjacency, so both inline
-// this as a fallback matching the shipped Sass defaults instead of the generic, uncapped `.menu`
-// fallback (`max-height: none`). A consumer who customized either Sass variable needs to
-// re-override `--menu-max-height`/`--menu-overflow-y` on `.menu` directly, since the
-// sibling-selector auto-application can no longer reach a portaled panel.
-export const COMBOBOX_MENU_OVERLAY_STYLE: CSSProperties = {
-  '--menu-max-height': '320px',
-  '--menu-overflow-y': 'auto'
-} as CSSProperties

package/src/utils/pointerInteraction.ts

@@ -1,21 +0,0 @@
-// Tracks, per-element, whether its most recent activation came from a real pointer click rather
-// than a keyboard one (a `click` fired by pointer activation has `detail >= 1`; one fired by
-// keyboard activation, e.g. Enter/Space on a focused button, has `detail === 0`) — for callers
-// that need that information later, asynchronously, once React has committed the state update the
-// click triggered (see `Carousel.tsx`'s disabled-end focus redirect, which needs it to decide
-// whether `focusRedirect` should suppress Safari's script-focus-after-pointer-click ring). A
-// `WeakSet` rather than a DOM attribute so it doesn't leak into markup/snapshots, and consuming it
-// clears the entry so a later, unrelated keyboard activation on the same element isn't
-// misattributed as pointer-triggered.
-const pointerClicks = new WeakSet<HTMLElement>()
-
-export function markPointerClick(el: HTMLElement): void {
-  pointerClicks.add(el)
-}
-
-export function consumePointerClick(el: HTMLElement | null): boolean {
-  if (!el) return false
-  const wasPointer = pointerClicks.has(el)
-  pointerClicks.delete(el)
-  return wasPointer
-}