@chassis-ui/react 0.1.3 → 0.3.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/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
-}

package/src/utils/polymorphic.ts

@@ -1,53 +0,0 @@
-import {
-  ComponentPropsWithoutRef,
-  ComponentPropsWithRef,
-  ElementType,
-  ForwardRefRenderFunction,
-  forwardRef,
-  Ref
-} from 'react'
-
-// Ref type inferred from a polymorphic component's currently-selected `component` element type.
-export type PolymorphicRef<C extends ElementType> = ComponentPropsWithRef<C>['ref']
-
-/**
- * Ref type for a polymorphic component that can also pick its element from a prop *other* than
- * `component` — `Button`, `Chip`, `Avatar`, `NavbarBrand` and `PaginationItem` all render an
- * `<a>` when given `href`, and `PaginationItem` a `<span>` when `active`, none of which moves `C`
- * off its default. A plain `PolymorphicRef<C>` describes only the `component` branch, so a caller
- * holding a ref for the element that actually gets rendered (`<Button href="/x" ref={anchorRef}>`)
- * got a spurious type error while the runtime happily populated it.
- *
- * `Ref` over the *union* rather than a union of `Ref`s is what makes a
- * `createRef<HTMLButtonElement | HTMLAnchorElement>()` assignable here: `RefObject` is invariant
- * in its type argument, so `RefObject<A | B>` satisfies `Ref<A | B>` but neither `Ref<A>` nor
- * `Ref<B>` on its own.
- */
-export type PolymorphicRefWithFallback<C extends ElementType, Fallback extends HTMLElement> =
-  PolymorphicRef<C> | Ref<Fallback>
-
-/**
- * Props for a polymorphic component: `OwnProps` (which must declare `component?: C`) plus
- * whatever props `C` itself accepts, minus any name already claimed by `OwnProps` so the two
- * don't conflict. Lets consumers swap `component` for e.g. a framework's `Image` and get full
- * type-checking/autocomplete for that component's own props at the call site.
- */
-export type PolymorphicComponentProps<C extends ElementType, OwnProps extends object> = OwnProps &
-  Omit<ComponentPropsWithoutRef<C>, keyof OwnProps>
-
-/**
- * Wraps a polymorphic component's render function in `forwardRef` and stamps `displayName` — the
- * two-step wiring every polymorphic component in this library repeats identically. `T` is the
- * fully generic component type (e.g. `ButtonComponent`) that `forwardRef`'s own return type can't
- * express, since `forwardRef` only accepts a non-generic render function — the caller still casts
- * the render function to a concrete `Element`-typed instance before passing it in here.
- */
-export function createPolymorphicComponent<T>(
-  // eslint-disable-next-line @typescript-eslint/no-explicit-any
-  render: ForwardRefRenderFunction<Element, any>,
-  displayName: string
-): T {
-  const Component = forwardRef(render) as unknown as T & { displayName?: string }
-  Component.displayName = displayName
-  return Component
-}

package/src/utils/renderMenuItemContent.tsx

@@ -1,62 +0,0 @@
-import React, { ReactNode } from 'react'
-
-import { Icon } from '../components/icon/Icon'
-
-export interface MenuItemContentDef {
-  /**
-   * Icon rendered at the item's leading edge (`.menu-item-icon`).
-   */
-  icon?: ReactNode
-  /**
-   * Label content.
-   */
-  label: ReactNode
-  /**
-   * Secondary line of text rendered below the label (`.menu-item-description`).
-   */
-  description?: ReactNode
-  /**
-   * Renders a `.menu-item-check` at the trailing edge when true.
-   */
-  selected?: boolean
-  /**
-   * Icon name for the selected-state check. Defaults to chassis-css's own doc example.
-   */
-  checkIcon?: string
-}
-
-// Chassis-css defines identical markup for rich item content in both Menu and Combobox items
-// (and, by extension, Autocomplete) — `.menu-item-icon` / `.menu-item-content` (label +
-// `.menu-item-description`) / `.menu-item-check`. Shared here so every consumer produces
-// byte-identical DOM instead of three near-duplicate implementations. Lives in `utils/` rather
-// than `components/menu/` because it crosses that folder boundary — Combobox.tsx and
-// Autocomplete.tsx both import it too. Renders bare `label` when there's nothing else to show,
-// keeping simple items' markup as minimal as chassis-css's own simplest example.
-export const renderMenuItemContent = ({
-  icon,
-  label,
-  description,
-  selected,
-  checkIcon = 'check-solid'
-}: MenuItemContentDef): ReactNode => {
-  if (icon == null && description == null && !selected) return label
-
-  return (
-    <>
-      {icon != null && (
-        <span className="menu-item-icon" aria-hidden="true">
-          {icon}
-        </span>
-      )}
-      {description != null ? (
-        <span className="menu-item-content">
-          <span>{label}</span>
-          <small className="menu-item-description">{description}</small>
-        </span>
-      ) : (
-        label
-      )}
-      {selected && <Icon name={checkIcon} className="menu-item-check" />}
-    </>
-  )
-}

package/src/utils/setVisibleRangeStart.ts

@@ -1,64 +0,0 @@
-import { flushSync } from 'react-dom'
-import { CalendarState, RangeCalendarState } from 'react-stately'
-import { CalendarDate } from '@internationalized/date'
-
-// Moves a (possibly multi-month) calendar's visible range so it starts at `desiredStart` — used by
-// `CalendarMonthYearPicker` to jump straight to a picked month/year, in any visible block.
-//
-// `state.setFocusedDate` is the only way to move `visibleRange` from outside react-stately, but it
-// doesn't just set `visibleRange.start` to wherever focus goes: react-stately keeps the visible
-// range as separate internal state, only repositioning it when the newly focused date falls
-// entirely *before* the current range (realigning so the range *ends* at that date's month) or
-// entirely *after* it (realigning so it *starts* there) — a focused date that lands inside the
-// current range moves focus without paging the range at all. That means a single `setFocusedDate`
-// call can only land exactly on an arbitrary `desiredStart` when it's at least a full
-// `visibleDuration` away from the current range. Anything closer — the common case here, since
-// adjacent blocks in a multi-month calendar are only one month apart — either no-ops (desired
-// start still inside the current range) or overshoots by up to a full `visibleDuration` (desired
-// start just outside it, but not far enough for the realignment to land exactly).
-//
-// Worked around with two `setFocusedDate` hops when a single one can't reach exactly: first past
-// `desiredStart` by one extra `visibleDuration` in the same direction (always far enough to land
-// exactly, by the same rule), flushed synchronously so `visibleRange` actually updates before the
-// second call runs, then back onto `desiredStart` itself — which, relative to that intermediate
-// range, is now exactly one `visibleDuration` away and so lands exactly too.
-export const setVisibleRangeStart = (
-  state: CalendarState<'single' | 'multiple'> | RangeCalendarState,
-  desiredStart: CalendarDate
-): void => {
-  const { start: currentStart, end: currentEnd } = state.visibleRange
-  if (desiredStart.compare(currentStart) === 0) return
-
-  const durationMonths = state.visibleDuration.months || 1
-  const isForward = desiredStart.compare(currentStart) > 0
-
-  const reachableInOneHop = isForward
-    ? desiredStart.compare(currentEnd) > 0
-    : desiredStart.add({ months: durationMonths - 1 }).compare(currentStart) < 0
-
-  if (reachableInOneHop) {
-    state.setFocusedDate(focusedDateForStart(desiredStart, isForward, durationMonths))
-    return
-  }
-
-  const overshootStart = isForward
-    ? desiredStart.add({ months: durationMonths })
-    : desiredStart.subtract({ months: durationMonths })
-
-  flushSync(() => {
-    state.setFocusedDate(focusedDateForStart(overshootStart, isForward, durationMonths))
-  })
-  // Relative to the now-updated range, `desiredStart` sits exactly one `visibleDuration` back the
-  // way we came — always far enough for a single hop to land exactly.
-  state.setFocusedDate(focusedDateForStart(desiredStart, !isForward, durationMonths))
-}
-
-// react-stately's forward-paging realignment anchors the new range to whatever month
-// `focusedDate` itself falls in; its backward-paging one anchors it `visibleDuration - 1` months
-// *before* `focusedDate`'s month instead — so landing on a specific desired start takes a
-// different `focusedDate` depending on which of the two is going to fire.
-const focusedDateForStart = (
-  desiredStart: CalendarDate,
-  isForward: boolean,
-  durationMonths: number
-): CalendarDate => (isForward ? desiredStart : desiredStart.add({ months: durationMonths - 1 }))

package/src/utils/spacingClassName.ts

@@ -1,14 +0,0 @@
-import { Spacing } from '../types'
-
-// A spacing prop (`gap`/`rowGap`/`gutter`/...) is typed `Spacing | 0`, but `0` is meaningful
-// (chassis-css's `gap-0` etc. exist) while `undefined`/`false`-ish values mean "not set" — a
-// plain truthy check would drop `0`, so every caller needs this same `typeof` guard instead.
-// Shared by `Flex`, `Stack`, `Row`, and `CardBody`'s own `layoutClassNames`/`_className` builders,
-// which otherwise duplicated it once per spacing prop (`gap`, `rowGap`, `columnGap`, `gutter`,
-// `gutterX`, `gutterY`, ...).
-export const spacingClassName = (
-  base: string,
-  value: Spacing | 0 | undefined,
-  prefix = ''
-): string | null =>
-  typeof value === 'string' || typeof value === 'number' ? `${prefix}${base}-${value}` : null