@chassis-ui/react 0.1.3 → 0.3.0

package/src/hooks/useDismissibleTransition.ts

@@ -1,126 +0,0 @@
-import { ForwardedRef, RefObject, useCallback, useEffect, useId, useRef, useState } from 'react'
-
-import { useForkedRef } from './useForkedRef'
-
-export interface UseDismissibleTransitionOptions {
-  /**
-   * Callback fired once the exit transition completes and the component is fully hidden.
-   */
-  onClose?: () => void
-  /**
-   * Callback fired when the component starts to show.
-   */
-  onShow?: () => void
-  ref: ForwardedRef<HTMLDivElement>
-  /**
-   * Toggle the visibility of the component.
-   */
-  visible?: boolean
-}
-
-export interface UseDismissibleTransitionTransitionProps {
-  appear: true
-  in: boolean
-  nodeRef: RefObject<HTMLDivElement | null>
-  onEnter: () => void
-  onEntered: () => void
-  onExit: () => void
-  onExited: () => void
-  unmountOnExit: true
-}
-
-export interface UseDismissibleTransitionResult {
-  /**
-   * Requests the component be closed — sets the internal visible state to `false`, which kicks
-   * off the exit transition; `onClose` fires once it finishes. Stable across re-renders (see the
-   * hook's own doc comment for why that matters).
-   */
-  close: () => void
-  /**
-   * Whether the entrance transition has actually finished — `false` while still fading/sliding
-   * in, even though `visible` is already `true`. Gate anything that should only start once the
-   * component is fully, visibly present (e.g. an autohide timer) on this rather than `visible`
-   * alone.
-   */
-  entered: boolean
-  forkedRef: ReturnType<typeof useForkedRef<HTMLDivElement>>
-  getTransitionClass: (state: string) => string | undefined
-  textId: string
-  titleId: string
-  /**
-   * Spread directly onto `<Transition>`. Each caller still supplies its own `timeout` (and any
-   * extra props, e.g. `mountOnEnter`) on top of this.
-   */
-  transitionProps: UseDismissibleTransitionTransitionProps
-  /**
-   * The internal, transition-driving visible state — distinct from the `visible` prop, since a
-   * `close()` call (or the exit transition itself) needs to flip this independently of whatever
-   * the caller is currently passing in.
-   */
-  visible: boolean
-}
-
-// Shared dismiss/transition machinery for `Toast` and `Notification` — both otherwise duplicated
-// this near-verbatim: visible-state + prop-sync effect, a forked ref, `getTransitionClass`,
-// `titleId`/`textId` via `useId()`, and the `Transition` entry/exit callback wiring.
-//
-// `close` is memoized once here with `useCallback` (empty deps — it only ever calls
-// `setVisible(false)`, whose setter identity is itself stable) specifically so it has a stable
-// identity across re-renders. Previously each component built its own unmemoized
-// `() => setVisible(false)` inline and passed it straight into `useAutoDismiss`, whose scheduling
-// effect depends on that closure's identity — since `Toaster`/`NotificationStack` re-render every
-// mounted item whenever the shared queue changes (`ToastQueue.add()`/`.close()` notify all
-// subscribers synchronously), that meant adding or dismissing any one toast/notification silently
-// restarted every other visible one's autohide countdown, with no code change needed to trigger
-// it beyond normal multi-item usage.
-//
-// `entered` similarly gates "has the entrance transition actually finished" uniformly for both —
-// `Toast` already had this (gating on `visible` alone would start the autohide timer the instant
-// `visible` flips true, while still fading/sliding in); `Notification` didn't, so this extraction
-// gives it the same fix for free.
-export function useDismissibleTransition({
-  onClose,
-  onShow,
-  ref,
-  visible = false
-}: UseDismissibleTransitionOptions): UseDismissibleTransitionResult {
-  const [_visible, setVisible] = useState(visible)
-  const [entered, setEntered] = useState(false)
-  const nodeRef = useRef<HTMLDivElement>(null)
-  const forkedRef = useForkedRef(ref, nodeRef)
-  const titleId = useId()
-  const textId = useId()
-
-  useEffect(() => {
-    setVisible(visible)
-  }, [visible])
-
-  const close = useCallback(() => setVisible(false), [])
-
-  const getTransitionClass = (state: string) =>
-    state === 'entering' || state === 'exiting'
-      ? 'show showing'
-      : state === 'entered'
-        ? 'show'
-        : undefined
-
-  return {
-    close,
-    entered,
-    forkedRef,
-    getTransitionClass,
-    textId,
-    titleId,
-    transitionProps: {
-      appear: true,
-      in: _visible,
-      nodeRef,
-      onEnter: () => onShow?.(),
-      onEntered: () => setEntered(true),
-      onExit: () => setEntered(false),
-      onExited: () => onClose?.(),
-      unmountOnExit: true
-    },
-    visible: _visible
-  }
-}

package/src/hooks/useDrawer.ts

@@ -1,9 +0,0 @@
-import { useContext } from 'react'
-import { DrawerContext, DrawerContextProps } from '../components/drawer/Drawer'
-
-export type UseDrawerResult = DrawerContextProps
-
-// Reach the enclosing `Drawer`'s close handler from anywhere in its composed markup — e.g. to
-// close it from a plain `Button` placed in a `DrawerFooter`. Only meaningful inside a `Drawer`;
-// outside one it returns a no-op `close`.
-export const useDrawer = (): UseDrawerResult => useContext(DrawerContext)

package/src/hooks/useFloatingOverlay.ts

@@ -1,125 +0,0 @@
-import { CSSProperties, HTMLAttributes, RefObject, useEffect, useRef, useState } from 'react'
-
-export interface UseFloatingOverlayOptions {
-  /**
-   * Imperatively closes the overlay — called when `visible` syncs to `false` and when the
-   * containing `<dialog>` fires its native `close` event. Pass a stable callback (e.g. the
-   * trigger state's own `close`) where possible; an inline arrow is fine too, since only its
-   * latest value is ever invoked.
-   */
-  close: () => void
-  /**
-   * Whether the overlay is currently open — drives `onShow`/`onHide` and portal-container
-   * resolution.
-   */
-  isOpen: boolean
-  /**
-   * Imperatively opens the overlay — called when `visible` syncs to `true`.
-   */
-  open: () => void
-  onHide?: () => void
-  onShow?: () => void
-  /**
-   * Ref to the element that triggers the overlay, used to resolve which `<dialog>` (if any) it
-   * lives inside.
-   */
-  triggerRef: RefObject<HTMLElement | null>
-  /**
-   * Controlled visibility prop from the consuming component; `undefined` means uncontrolled.
-   */
-  visible?: boolean
-}
-
-/**
- * Shared portal-container/visibility wiring for `Popover` and `Tooltip`: resolves the `<dialog>`
- * a trigger lives inside (if any), syncs an uncontrolled-by-default `visible` prop to the
- * trigger state, fires `onShow`/`onHide`, and resets on the containing dialog's native `close`
- * event. Positioning-specific concerns (placement, arrow, escape/outside-click dismissal) stay
- * in each component — only this ~80% overlap is shared.
- */
-export function useFloatingOverlay({
-  close,
-  isOpen,
-  open,
-  onHide,
-  onShow,
-  triggerRef,
-  visible
-}: UseFloatingOverlayOptions) {
-  const [portalContainer, setPortalContainer] = useState<Element | null>(null)
-
-  // Overlays inside an open `<dialog>` are appended to that dialog instead of `document.body`,
-  // so they render in its top layer and close with it automatically.
-  const resolvePortalContainer = () => triggerRef.current?.closest('dialog[open]') ?? document.body
-
-  // Sync-on-change, not strictly controlled — matches `Menu`'s `visible` semantics.
-  useEffect(() => {
-    if (visible === undefined) return
-    setPortalContainer(resolvePortalContainer())
-    if (visible) open()
-    else close()
-  }, [visible])
-
-  // `onShow`/`onHide` report *transitions*, so neither fires for the initial commit — mounting
-  // closed is not a hide. Without this guard the `else` branch ran on mount and every
-  // `<Popover onHide>`/`<Tooltip onHide>` on the page reported a close that never happened,
-  // before `onShow` had ever fired once. The portal container still resolves on mount, since
-  // an overlay mounted already-open needs one immediately.
-  const mountedRef = useRef(false)
-
-  useEffect(() => {
-    const isInitialCommit = !mountedRef.current
-    mountedRef.current = true
-
-    if (isOpen) {
-      setPortalContainer(resolvePortalContainer())
-      if (!isInitialCommit) onShow?.()
-    } else if (!isInitialCommit) {
-      onHide?.()
-    }
-  }, [isOpen])
-
-  // `close` is read through a ref so this effect only re-subscribes when `isOpen`/
-  // `portalContainer` actually change, regardless of whether the caller passes a stable
-  // callback or a fresh inline arrow each render.
-  const closeRef = useRef(close)
-  closeRef.current = close
-
-  // A dialog fires a native `close` event on ESC, backdrop click, or `.close()`, so resetting
-  // on it keeps a reopened dialog from showing a stale, already-open overlay.
-  useEffect(() => {
-    const dialog = portalContainer?.closest('dialog')
-    if (!isOpen || !dialog) return
-
-    const handleClose = () => closeRef.current()
-    dialog.addEventListener('close', handleClose)
-    return () => dialog.removeEventListener('close', handleClose)
-  }, [isOpen, portalContainer])
-
-  return portalContainer
-}
-
-// `useOverlayPosition`'s `arrowProps.style` sets a single cross-axis offset (`top` for a
-// left/right overlay, `left` for a top/bottom one) to the trigger's center point, not the arrow
-// element's top-left corner — so it must be recentered by half the arrow's own size on that
-// axis. Chassis-css's JS plugin never has this problem since Floating UI's `arrow` middleware
-// returns a top-left-corner coordinate directly; react-aria's is center-based. Unlike the
-// chassis-css JS plugin, react-aria also never sets `position: absolute` on the arrow element
-// itself, so without it the offset has no effect and the arrow renders in normal document flow.
-export function getOverlayArrowStyle(arrowProps: HTMLAttributes<HTMLDivElement>): CSSProperties {
-  return {
-    position: 'absolute',
-    ...arrowProps.style,
-    transform: arrowProps.style?.top !== undefined ? 'translateY(-50%)' : 'translateX(-50%)'
-  }
-}
-
-export function getOverlayTransitionClass(transitionState: string): string {
-  return transitionState === 'entering'
-    ? 'fade'
-    : transitionState === 'entered'
-      ? 'fade show'
-      : transitionState === 'exiting'
-        ? 'fade'
-        : 'fade'
-}

package/src/hooks/useForkedRef.ts

@@ -1,50 +0,0 @@
-// code borrowed from https://github.com/reach/reach-ui
-// problem described https://github.com/facebook/react/issues/13029
-
-import { useMemo } from 'react'
-
-export type AssignableRef<ValueType> =
-  | {
-      bivarianceHack(instance: ValueType | null): void
-    }['bivarianceHack']
-  | React.MutableRefObject<ValueType | null>
-
-// eslint-disable-next-line @typescript-eslint/no-explicit-any
-export function useForkedRef<RefValueType = any>(
-  ...refs: (AssignableRef<RefValueType> | null | undefined)[]
-) {
-  return useMemo(() => {
-    if (refs.every((ref) => ref == null)) {
-      return null
-    }
-    // eslint-disable-next-line @typescript-eslint/no-explicit-any
-    return (node: any) => {
-      refs.forEach((ref) => {
-        assignRef(ref, node)
-      })
-    }
-  }, refs)
-}
-
-// eslint-disable-next-line @typescript-eslint/no-explicit-any
-export function assignRef<RefValueType = any>(
-  ref: AssignableRef<RefValueType> | null | undefined,
-  // eslint-disable-next-line @typescript-eslint/no-explicit-any
-  value: any
-) {
-  if (ref == null) return
-  if (isFunction(ref)) {
-    ref(value)
-  } else {
-    try {
-      ref.current = value
-    } catch (error) {
-      throw new Error(`Cannot assign value "${value}" to ref "${ref}"`, { cause: error })
-    }
-  }
-}
-
-// eslint-disable-next-line @typescript-eslint/no-explicit-any, @typescript-eslint/no-unsafe-function-type
-export function isFunction(value: any): value is Function {
-  return !!(value && {}.toString.call(value) == '[object Function]')
-}

package/src/hooks/useFormField.ts

@@ -1,89 +0,0 @@
-import { ReactNode, useId } from 'react'
-
-export interface UseFormFieldOptions {
-  /**
-   * A caller-supplied `aria-describedby` to merge in alongside the generated help/feedback ids
-   * (e.g. `rest['aria-describedby']`).
-   */
-  ariaDescribedBy?: string
-  /**
-   * A caller-supplied `aria-labelledby` to merge in alongside `labelId` (e.g.
-   * `rest['aria-labelledby']`). Relevant for the `role="group"` shape and for any single-input
-   * component backed by a react-aria hook — see `labelledBy`.
-   */
-  ariaLabelledBy?: string
-  help?: ReactNode
-  id?: string
-  invalid?: boolean
-  invalidFeedback?: ReactNode
-  label?: ReactNode
-  valid?: boolean
-  validFeedback?: ReactNode
-}
-
-export interface UseFormFieldResult {
-  /**
-   * Merged `aria-describedby` value (help id + feedback id, if shown + `ariaDescribedBy`), or
-   * `undefined` when none apply. Safe to spread straight onto the real control:
-   * `aria-describedby={describedBy}`.
-   */
-  describedBy?: string
-  feedbackId: string
-  helpId: string
-  /**
-   * Id for the one real focusable control — pair with `<FormLabel htmlFor={inputId}>` (via
-   * `ids.input`). Ignore this and use `labelId`/`labelledBy` instead for a `role="group"` wrapper
-   * with no single input to target — see FORMS.md's "`htmlFor` vs `aria-labelledby`" section.
-   */
-  inputId: string
-  /**
-   * This field's own label id, for a control to reference via its own `aria-labelledby` (via
-   * `ids.label`) instead of `htmlFor`.
-   */
-  labelId: string
-  /**
-   * Merged `aria-labelledby` value (`labelId`, only when `label` is set + `ariaLabelledBy`), or
-   * `undefined` when neither applies. Feed this into the underlying react-aria hook's own
-   * `aria-labelledby` (in addition to any `htmlFor`-based association) so its own dev-mode
-   * "no accessible label" warning knows about a visible `label` it can't otherwise see.
-   */
-  labelledBy?: string
-}
-
-// Shared id-generation and aria-describedby/aria-labelledby merge logic behind every
-// renderFormField-based component (see FORMS.md's "The two engines" section). Every id is
-// generated with React's own useId(), not react-aria's — see FORMS.md for why that's deliberate.
-//
-// If you spread the result of a react-aria hook via mergeProps(hookProps, rest) instead of
-// directly onto the control, re-apply `describedBy`/`labelledBy` as explicit props *after* that
-// spread — mergeProps lets the later argument win, so rest's raw (un-merged) aria-describedby/
-// aria-labelledby can silently overwrite these otherwise. See FORMS.md gotcha #4.
-export const useFormField = ({
-  ariaDescribedBy,
-  ariaLabelledBy,
-  help,
-  id,
-  invalid,
-  invalidFeedback,
-  label,
-  valid,
-  validFeedback
-}: UseFormFieldOptions): UseFormFieldResult => {
-  const generatedId = useId()
-  const inputId = id ?? generatedId
-  const labelId = `${generatedId}-label`
-  const helpId = `${generatedId}-help`
-  const feedbackId = `${generatedId}-feedback`
-
-  const showInvalidFeedback = invalid && invalidFeedback
-  const showValidFeedback = valid && validFeedback
-
-  const describedBy =
-    [help && helpId, (showInvalidFeedback || showValidFeedback) && feedbackId, ariaDescribedBy]
-      .filter(Boolean)
-      .join(' ') || undefined
-
-  const labelledBy = [label && labelId, ariaLabelledBy].filter(Boolean).join(' ') || undefined
-
-  return { describedBy, feedbackId, helpId, inputId, labelId, labelledBy }
-}

package/src/hooks/useIsomorphicLayoutEffect.ts

@@ -1,9 +0,0 @@
-import { useEffect, useLayoutEffect } from 'react'
-
-// `useLayoutEffect` logs a console warning ("does nothing on the server") whenever it's called
-// during SSR, even though no effect — layout or otherwise — ever actually runs server-side;
-// React only cares that the hook itself was invoked under `renderToString`/
-// `renderToPipeableStream`. Swapping to `useEffect` in that environment silences the warning with
-// no behavior change, since neither hook runs server-side anyway — this only picks which one
-// no-ops there.
-export const useIsomorphicLayoutEffect = typeof window === 'undefined' ? useEffect : useLayoutEffect

package/src/hooks/useModal.ts

@@ -1,9 +0,0 @@
-import { useContext } from 'react'
-import { ModalContext, ModalContextProps } from '../components/modal/Modal'
-
-export type UseModalResult = ModalContextProps
-
-// Reach the enclosing `Modal`'s close handler from anywhere in its composed markup — e.g. to
-// close it from a plain `Button` placed in a `ModalFooter`. Only meaningful inside a `Modal`;
-// outside one it returns a no-op `close`.
-export const useModal = (): UseModalResult => useContext(ModalContext)

package/src/hooks/useNotification.ts

@@ -1,10 +0,0 @@
-import { useContext } from 'react'
-import { NotificationContext, NotificationContextProps } from '../components/notification/context'
-
-export type UseNotificationResult = NotificationContextProps
-
-// Reach the enclosing `Notification`'s dismiss handler from anywhere in its composed markup —
-// e.g. to close it from a plain `Button` placed alongside other `actions`, instead of the
-// built-in `dismissible` close button. Only meaningful inside a `Notification`; outside one it
-// returns a no-op `close`.
-export const useNotification = (): UseNotificationResult => useContext(NotificationContext)

package/src/hooks/useOverlayPlacement.ts

@@ -1,93 +0,0 @@
-import { CSSProperties, HTMLAttributes, RefObject } from 'react'
-import { mergeProps, useOverlay, useOverlayPosition } from 'react-aria'
-import { OverlayTriggerState } from 'react-stately'
-
-import { resolveDataPlacement, toAriaPlacement } from '../utils/overlayPlacement'
-
-interface UseOverlayPlacementProps {
-  overlayRef: RefObject<HTMLElement | null>
-  state: OverlayTriggerState
-  triggerRef: RefObject<HTMLElement | null>
-}
-
-interface UseOverlayPlacementResult {
-  overlayStyle: CSSProperties
-  placementAttr: string
-  // Re-typed as plain HTML attributes for the same `rollup-plugin-dts` portability reason as
-  // before (see git history) — react-aria's own return type pulls in a `FocusableElement`
-  // reference the bundled `.d.ts` can't always resolve a portable name for.
-  overlayDismissProps: HTMLAttributes<HTMLElement>
-}
-
-// Shared by `DatePicker` and `DateRangePicker` — both position their calendar overlay the same
-// way (`bottom-start`, 2px offset, closing on Escape, on any click outside it, or when focus leaves
-// the trigger group). Lives in `hooks/` rather than `components/datepicker/` like every other hook
-// in this library, regardless of how many components use it — see `useFormField` for the same
-// treatment despite having many more callers.
-//
-// Built directly on `useOverlay` + `useOverlayPosition` rather than the higher-level `usePopover`
-// combo hook. `usePopover` computes its own internal `onClose` for `useOverlayPosition` from
-// `isNonModal` (`isNonModal && !isSubmenu ? state.close : null`, neither overridable by a caller),
-// and `isNonModal: true` — needed so the calendar doesn't lock page scroll or aria-hide the rest of
-// the page, since it was never meant to be modal — unconditionally arms `useOverlayPosition`'s
-// close-on-any-window-scroll listener (`useCloseOnScroll`, keyed off `onClose !== null`) as a side
-// effect. That's wrong here: the calendar should reposition with its trigger when the page scrolls,
-// not disappear. Calling the two lower-level hooks directly, with `onClose: null` passed to
-// `useOverlayPosition` alone, gets the positioning and Escape/blur dismissal this calendar needs
-// without arming that listener — the same fix already applied to `Autocomplete`/`Combobox`/
-// `Menu`/`MenuSubmenu`/`Popover`, none of which use `usePopover` either, all for this same reason.
-export const useOverlayPlacement = ({
-  overlayRef,
-  state,
-  triggerRef
-}: UseOverlayPlacementProps): UseOverlayPlacementResult => {
-  // The trigger's own toggle button lives inside `triggerRef`, not `overlayRef` — without this,
-  // focus moving there when the button is pressed would count as an "outside" interaction and
-  // close the overlay, which the button's own `onPress` then immediately reopens on click.
-  const shouldCloseOnInteractOutside = (element: Element) => !triggerRef.current?.contains(element)
-
-  // Escape key + outside-interaction dismissal — the two pieces of `usePopover`'s bundled behavior
-  // this calendar still needs. `isDismissable: true` — *not* `usePopover`'s own default of `false`
-  // whenever `isNonModal` is true — is required to actually get outside-*click* dismissal:
-  // `useOverlay`'s `shouldCloseOnBlur` only closes on a focus-based blur, and explicitly bails when
-  // the click target isn't focusable (`relatedTarget` is `null`, i.e. focus lands on `document.body`,
-  // as it does for an ordinary click on plain page content) — its own source comments that this case
-  // is intentionally left to the separate pointerdown-outside listener `useOverlay` only wires up
-  // when `isDismissable` is true. Leaving it at the `usePopover`-matching default therefore silently
-  // drops the single most common way users try to dismiss a popover.
-  const { overlayProps } = useOverlay(
-    {
-      isDismissable: true,
-      isOpen: state.isOpen,
-      onClose: state.close,
-      shouldCloseOnBlur: true,
-      shouldCloseOnInteractOutside
-    },
-    overlayRef
-  )
-
-  const { overlayProps: positionProps, placement: resolvedPlacement } = useOverlayPosition({
-    isOpen: state.isOpen,
-    offset: 2,
-    // Opts out of `useOverlayPosition`'s own close-on-any-window-scroll listener — see this hook's
-    // own comment above. Leaving this `undefined` would NOT disable it: `useCloseOnScroll` only
-    // early-returns on `onClose === null`, not merely falsy.
-    onClose: null,
-    overlayRef,
-    placement: toAriaPlacement('bottom-start'),
-    targetRef: triggerRef
-  })
-
-  const { style: overlayPositionStyle, ...overlayDismissProps } = mergeProps(
-    overlayProps,
-    positionProps
-  )
-  const overlayStyle: CSSProperties = {
-    position: overlayPositionStyle?.position as CSSProperties['position'],
-    top: overlayPositionStyle?.top,
-    left: overlayPositionStyle?.left
-  }
-  const placementAttr = resolveDataPlacement('bottom-start', resolvedPlacement)
-
-  return { overlayStyle, placementAttr, overlayDismissProps }
-}

package/src/hooks/usePagination.ts

@@ -1,89 +0,0 @@
-import { MouseEvent, RefObject, useEffect, useRef } from 'react'
-
-import { focusRedirect } from '../utils/focusRedirect'
-
-export interface UsePaginationOptions {
-  /**
-   * Whether the Previous control is currently disabled.
-   */
-  prevDisabled: boolean
-  /**
-   * Whether the Next control is currently disabled.
-   */
-  nextDisabled: boolean
-  /**
-   * Called when Previous is clicked, before the state change that may disable it.
-   */
-  onPrev: () => void
-  /**
-   * Called when Next is clicked, before the state change that may disable it.
-   */
-  onNext: () => void
-}
-
-export interface UsePaginationResult<T extends HTMLElement = HTMLButtonElement> {
-  // `RefObject<T | null>`, not `RefObject<T>`: these come from `useRef<T>(null)`, so `.current`
-  // really is null before mount (and whenever the control isn't rendered — a hand-composed
-  // pagination may omit Prev/Next entirely). Declaring the non-null form let a consumer write
-  // `prevRef.current.focus()` with no type error and crash at runtime.
-  prevRef: RefObject<T | null>
-  nextRef: RefObject<T | null>
-  handlePrevClick: (event: MouseEvent<T>) => void
-  handleNextClick: (event: MouseEvent<T>) => void
-}
-
-interface Pending {
-  from: 'prev' | 'next'
-  // A `click` fired by real pointer activation has `detail >= 1`; one fired by keyboard
-  // activation (Enter/Space on a focused button) has `detail === 0`.
-  viaPointer: boolean
-}
-
-// Native `disabled` buttons are blurred by the browser the instant they're disabled. Clicking a
-// Prev/Next control into the first/last page disables that very control, silently dropping focus
-// to `<body>`. Wire `handlePrevClick`/`handleNextClick` up as each control's `onClick` — they call
-// `onPrev`/`onNext` and redirect focus to the still-enabled sibling in one step, so callers don't
-// hand-wrap their own click handler around a separate mark-then-focus call.
-// Works for `Pagination`'s built-in smart mode and for hand-composed Prev/Next controls alike —
-// pass the element type of whatever you're attaching the refs to (`PaginationItem` defaults to
-// an `HTMLButtonElement`, but renders an `HTMLAnchorElement` when given `href` or `component`).
-export function usePagination<T extends HTMLElement = HTMLButtonElement>({
-  prevDisabled,
-  nextDisabled,
-  onPrev,
-  onNext
-}: UsePaginationOptions): UsePaginationResult<T> {
-  const prevRef = useRef<T>(null)
-  const nextRef = useRef<T>(null)
-  const pending = useRef<Pending | null>(null)
-
-  // Deliberately no dependency array: this must run after every render, not just ones where
-  // prevDisabled/nextDisabled change value. A Prev/Next click that doesn't cross a boundary
-  // (e.g. moving between two enabled middle pages) leaves both booleans unchanged, so a
-  // dependency-gated effect would skip and leave `pending` stale — a later, unrelated render
-  // that does flip one of the booleans (e.g. jumping straight to the first/last page via a
-  // page-number click) would then wrongly consume that stale mark and redirect focus.
-  useEffect(() => {
-    const from = pending.current
-    pending.current = null
-    if (!from) return
-    if (from.from === 'prev' && prevDisabled) {
-      focusRedirect(nextRef.current, from.viaPointer)
-    } else if (from.from === 'next' && nextDisabled) {
-      focusRedirect(prevRef.current, from.viaPointer)
-    }
-  })
-
-  return {
-    prevRef,
-    nextRef,
-    handlePrevClick: (event) => {
-      pending.current = { from: 'prev', viaPointer: event.detail !== 0 }
-      onPrev()
-    },
-    handleNextClick: (event) => {
-      pending.current = { from: 'next', viaPointer: event.detail !== 0 }
-      onNext()
-    }
-  }
-}

package/src/hooks/useToast.ts

@@ -1,9 +0,0 @@
-import { useContext } from 'react'
-import { ToastContext, ToastContextProps } from '../components/toast/context'
-
-export type UseToastResult = ToastContextProps
-
-// Reach the enclosing `Toast`'s dismiss handler from anywhere in its composed markup — e.g. to
-// close it from a plain `Button` placed in a `ToastFooter`, instead of a dedicated close
-// component. Only meaningful inside a `Toast`; outside one it returns a no-op `close`.
-export const useToast = (): UseToastResult => useContext(ToastContext)

package/src/hooks/useToastRegionQueue.ts

@@ -1,27 +0,0 @@
-import { ForwardedRef, useRef } from 'react'
-import { ToastRegionAria, useToastRegion } from 'react-aria'
-import { ToastQueue, ToastState, useToastQueue } from 'react-stately'
-
-import { useForkedRef } from './useForkedRef'
-
-export interface UseToastRegionQueueResult<T> {
-  forkedRef: ReturnType<typeof useForkedRef<HTMLDivElement>>
-  regionProps: ToastRegionAria['regionProps']
-  state: ToastState<T>
-}
-
-// Shared setup for `Toaster`/`NotificationStack` — both otherwise duplicated this near-verbatim:
-// subscribe to a `ToastQueue` singleton, wire up react-aria's toast-region accessibility
-// plumbing, and fork the caller's ref onto the same node the region hook needs. Differs only in
-// which queue is passed.
-export function useToastRegionQueue<T>(
-  queue: ToastQueue<T>,
-  ref: ForwardedRef<HTMLDivElement>
-): UseToastRegionQueueResult<T> {
-  const state = useToastQueue(queue)
-  const regionRef = useRef<HTMLDivElement>(null)
-  const { regionProps } = useToastRegion({}, state, regionRef)
-  const forkedRef = useForkedRef(ref, regionRef)
-
-  return { forkedRef, regionProps, state }
-}