devongovett
commented
3 years ago Hey, thanks for the feedback! React Aria is certainly low level. Our goal when releasing it was that it could accommodate the widest possible number of use cases. This includes the ability to fully customize the appearance, DOM structure, behavior, etc. We aim to let you have just as much control as if you were building the component from scratch with the raw DOM APIs as you might have before, but also provide a lot of behavior and a11y for you. Our hope was that higher level libraries like Headless UI would be built on top of React Aria. It's only possible to do this one way: the lower level hooks have to come first.
We did look at component and render-props based APIs when designing React Aria. In fact, we started thinking about this problem long before Hooks even existed. However, we never found the right way to do this that offered enough customization potential. Our goal was to build something that we could build React Spectrum (our design system) off of, and I don't think we could have done that without lower level access in some areas.
A few considerations:
- The components are mainly designed to be used as part of a larger design system. Headless UI is definitely simpler to use when you only use one component, but you may find yourself duplicating some things in a larger project. For example, in the React Aria code you showed above, the ListBox and Popover components can be reused for other things, like standalone lists, and menus. This can be hard for us to show on the documentation site for components that compose several pieces together like this, because you need all pieces first before you can put them together. Perhaps there's more we can do to improve this.
- Custom styling often requires extra DOM elements, or access to internal state. For example, a Tabs component with an animating line to indicate the selection requires an extra element and access to the DOM nodes for each tab to measure their sizes. Or perhaps you want to enable virtual scrolling for long lists, but still enable keyboard navigation even when all of the elements aren't rendered. Coupling components to a pre-defined DOM structure and relying on context definitely has limitations.
- Another goal is to share as much as possible across platforms. For example, the react-native-aria project is reusing our React Stately hooks to build equivalent versions for React Native. This type of sharing wouldn't have been possible with monolithic components.
- Customizing the behavior sometimes requires overriding properties returned by React Aria. For example, if you wanted to override some keyboard behavior for a specific case, you could override the
onKeyDownprop returned from a hook and call it conditionally from within your own implementation. Doing this with a component API that renders the DOM elements for you would be tricky. - There's a tradeoff between functionality and bundle size. Some components might have a lot of functionality that might not be useful across all products. For example, tables could have column resizing/reordering, drag and drop, multi-selection, etc. and not all of this may always be needed. We could include all of that in a single component with props to turn things on or off, but the tradeoff is that you're always paying the bundle size cost for code that's not actually used. Hooks provide a clean way to share small pieces of functionality that can be composed together within a single component, with the downside being, as you said, some glue code.
That being said, I do think there is a lot we can do to improve here without compromising on these goals. We've started at the lowest level layer possible, and are slowing working our way up the stack to provide higher level abstractions. Here are some ideas we have been thinking about:
- Combine some hooks that are very commonly used together. For example, buttons almost always need a focus style. We could combine the call to
useFocusRingintouseButtonand return anisFocusVisiblestate so you don't need to do that yourself.useOverlaycould have a focus scope built in for focus trapping.useSelectcould potentially haveuseButtonbuiltin, etc. The tradeoff is that if you're using the native:focus-visible, a different focus trapping library, or something else you get a bit of code you don't use, however, for some things this may be worth it. Figuring out where to draw that line is an interesting challenge. - Expose more states from the hooks that could be used for styling. We've started doing this already – the
isSelected/isFocused/etc. values returned fromuseOptionwere recently added. This avoids you needing to compute this yourself. We plan to continue adding more of these across the hooks. - Reduce the amount of things you need to pass between hooks, e.g. between parents and children. We can often attach multiple things to the
stateobject that you pass down rather than needing to pass a bunch of other options to child hooks. - Create higher level hooks that combine more things together. This is related to the first one, but in some cases, rather than merging everything into one hook and causing larger bundles for everyone, we could keep the lower level hooks and also provide some higher level wrappers for common combinations.
Overall, the goal should be to reduce the number of different hooks you need to call for common cases, while retaining flexibility to drop down to lower level APIs where needed.
We don't currently have plans to offer an official component-based wrapper around our hooks, mainly for lack of time, but we would encourage and assist the community in such an effort. Personally, I would love to see multiple libraries with different takes on such an API built on top of React Aria, e.g. integrating with or optimizing for specific styling methodologies (e.g. tailwind, css-in-js, etc.). If you or anyone else is interested in working on such a library, we'd be happy to assist in any way we can. 😄
ianstormtaylor
sandren
DaniGuardiola
This library is awesome for the breath it provides for components and interactions and accessibility. Everything is clearly very well considered. And the goal of it being completely customizable is admirable and why I'd use it.
But as a user, the majority of my time using it is spent in very frustrating to debug "glue code" between the many hooks. It may not feel confusing as maintainers because you know the ins and outs of every hook, but let me tell you as a user, this is an extremely confusing library.
A big part of this is because of the decision to only provide hooks as the main API. The existing hooks are great for low-level use cases where some hyper-specific customization is required. But 90% of use cases don't need this.
I think this library would greatly benefit from taking an approach similar to Headless UI, which is based around components. With smart use of internal context to connect things together they are able to eliminate all of the tedious glue code, allowing you to focus purely on the components, state, and events. It's wonderfully simple to reason about. (And the existing hooks API could still be available for the 10% of cases that need extreme customization.)
For context, take a look at how implementing a Listbox differs between React ARIA's current API, and how HeadlessUI does it...
React ARIA
```tsx import React from "react"; import { useSelect, HiddenSelect, mergeProps, useFocusRing, useButton, useListBox, useOption, useOverlay, DismissButton, FocusScope } from "react-aria"; import type { AriaListBoxOptions } from "@react-aria/listbox"; import type { AriaSelectProps } from "@react-types/select"; import type { Node } from "@react-types/shared"; import { ListState, Item, useSelectState } from "react-stately"; const animals = [ { id: "red panda", name: "Red Panda" }, { id: "cat", name: "Cat" }, { id: "dog", name: "Dog" }, { id: "aardvark", name: "Aardvark" }, { id: "kangaroo", name: "Kangaroo" }, { id: "snake", name: "Snake" } ]; export function ReactAria() { return ( ); } function Select{[...state.collection].map((item) => ( ))}
); } function Option(props: { item: NodeHeadlessUI
```tsx import React, { useState } from "react"; import { Listbox } from "@headlessui/react"; const animals = [ { id: "red panda", name: "Red Panda" }, { id: "cat", name: "Cat" }, { id: "dog", name: "Dog" }, { id: "aardvark", name: "Aardvark" }, { id: "kangaroo", name: "Kangaroo" }, { id: "snake", name: "Snake" } ]; export function HeadlessUi() { const [selectedAnimal, setSelectedAnimal] = useState< typeof animals[number] | null >(null); return (The HeadlessUI code is much easier to reason about because all of the glue code is handled under the covers by the library using context. Whereas the React ARIA code is full of hooks and refs and state that needs to be connected together just right to get things to work.
Edit: Unfortunately I wasn't super clear, but I'm advocating for both hooks and components APIs. Obviously the hooks are low-level and useful for edge cases. But I think adding components alongside them would be nicer to use for 90% of cases.