API design of high-level library on top of React-Aria

[tanishqkancharla]

Hey! I've been working on creating a new high-level interface on top of React-Aria. Think something kind of like Radix UI or Headless UI but the main difference being it's easy to "drop down" into lower levels to get the behavior and accessibility props. Those libraries kinda lock you into using their components, and instead I am creating a library here that gives you control on how high or low of a level you need the behavior of your components.

One thing I have been thinking about is a proper API design of this library. Here are some notes on a potential API:

Suppose you are trying to use a Select component. You can do so at a high-level with this:

export const ... = () => {
  const {Select} = useSelect({});
  return <Select className="..."/>
}

But suppose you decide you want to manually style or position the label and the popover. You can do:

export const ... = () => {
  const {Select: {Label, Selector, Popover}, state} = useSelect({});
  return <div className="...">
    Label className="..."/>
    <Selector className="..."/>
    {state.isOpen && 
      <Popover className="..."/>
    }
  </div>
}

But suppose you decide to use custom label elements for your select. Then maybe:

export const ... = () => {
  const {Select: {Label: {labelProps, label}, Selector, Popover}, state} = useSelect({});
  return <div>
    <CustomLabelElement {...labelProps}/>
      {label}
    </CustomLabelElement>
    <Selector className="..."/>
    {state.isOpen && 
      <Popover className="..."/>
    }
  </div>
}

The idea is that you can "drop down" the levels as you need, with the high levels and the low levels available as you need them from the same hook. The high level components get their accessibility props fully injected in, so you always stay fully accessible no matter what level you decide to use.

The useSelect hook could be implemented like this:

export function useSelect<T extends object>(
  props: AriaSelectProps<T>
): SelectObjects<T> {
  // Create state based on the incoming props
  let state = useSelectState(props)

  // Get props for child elements from useSelectAria (react-aria hook)
  let ref = React.useRef(null)
  let { labelProps, triggerProps, valueProps, menuProps } = useSelectAria(
    props,
    state,
    ref
  )

  // Get props for the button based on the trigger props from useSelectAria
  let { buttonProps } = useButton(triggerProps, ref)

  let { focusProps, isFocusVisible } = useFocusRing()

  return {
    Select: // --snip-- default Select component built using the components
    state,
    isFocusVisible,
    // These are in the return format shown in the snippets above (where the default is a component, but you can access the labelProps from inside)
    Label: useLabel(labelProps),
    HiddenSelect: () => (
      <HiddenSelect
        state={state}
        triggerRef={ref}
        label={props.label}
        name={props.name}
      />
    ),
    Button: useButton(mergeProps(triggerProps, focusProps), ref),
    // Returns a component for the current value of the select
    Value: ...,
    Popover: ...,
  }
}

Here is a sandbox that kinda shows how this can be built.

https://codesandbox.io/s/bold-kepler-w01w2?file=/src/App.tsx

I know the code is ugly, etc. If everything were fleshed out, the useButton would return the Button component (instead of it being built inside the Select), and there would be usePopover and useListbox hooks being used. I also know the API doesn't match the one above perfectly: its kind of a mess to assign properties to functions in Typescript.

Is this a confusing API? Is it okay? What could be fixed, and how would you approach it?

I'd really like to get some feedback on this approach/idea, @devongovett @snowystinger

[snowystinger]

I think my first thought is that it's pretty clever.
That said it's certainly unusual to return Components from hooks, so you'd have to teach people about this new API, which is always hard.

I think the thing I'd worry about most is memo'ing all the Components you pass out so that React doesn't unmount/mount things repeatedly. I've included some bits to track mounting and unmounting for the button and label. I'd expect them to only mount once and never unmount in this particular app unless I closed the page, but that's not the case https://codesandbox.io/s/unruffled-cherry-3mtv6 I see mounting and unmounting just in response to hovering elements.

I'm not sure I have any suggestions for improving it unfortunately. Even if you tracked prop changes and only updated the memo'd component if there were prop changes, it'd still result in a new cycle of mounting.
The only way is to always return the same function and pass things via context, but then there'd be no need to return a component from the hooks.

You may find this discussion to be a useful read as well: #2450

[tanishqkancharla]

Hmm...yeah I was worried about performance. React is probably pretty confused w/ what's going on. The example I built isn't complete: ideally there would be react hooks like useLabel and useButton that give you the component (rather than them being constructed inside the Select). I'll see if I can create that and fix the issue. useCallback didn't work for me to memo the components. Maybe you can just move the components outside the Select?

I think the goal I'm looking for is just a "crumbly" API, where you can get a pre-built component that does what you want out of the box, but you can also break it down into its core behaviors as needed. I'm not sure the best way to do that in React, since it tries to "abstract" a components internals away from you. For example it would be nice if given a react component

const Button = () => {
  return <button>
    <label>{props.label}</label>
  </button>

I could do something like Button.children[0] or something to access internals. :/ Or some sort of partial evaluation of react components. But that plays so poorly with react mounting/unmounting.

I'll keep thinking about how this can be possible. I like the discourse on slots you linked: that might be helpful!

[snowystinger]

Hey! I just wanted to follow up and see where you landed with this topic. I'd love to hear what things you've tried along the way as well.

[tanishqkancharla]

Hello! Ultimately I decided to abandon the idea since there are so many hooks and I got tired 😅. I did try a few ideas though. I think the original API I suggested is kinda complex. It makes the source hard to read if there are useMemos everywhere especially. Besides, I never managed to fix the mounting/unmounting issue.

The way I thought of going eventually was just to provide multiple different hooks at different granularity levels. i.e. useSelect1 returns Select component, useSelect2 returns select props, useSelect3 returns props for buttons, etc. It loses the original spirit of the idea though, to pick and choose the granularity of different parts of the component (for example, maybe I want the stock button but a custom label).

I'll think about giving it a shot again and trying to start with components that are less involved than Select.