[awhitty]

Oho! So excited about this. I’ve used a hybrid of Radix UI and React Aria on previous projects. Radix had a much nicer DX out of the box with pre-wired components, but my team was always apprehensive about the long-term support for Radix post-acquisition. Really excited to see React Aria adopting a similar component-based interface.

Couple questions/feedbacks if you’re still in the comments, Devon!

1. Radix implements an asChild prop to help merge the library components down into other components that might already have their own styling or behaviors. Did y’all consider supporting this sort of polymorphic approach? Or is there another way to merge components? The main spots where I’ve used it are buttons and dropdown triggers, so it might not be broadly applicable.

2. Is it easier to extend from the React Aria types with this interface now? My previous implementations with React Aria - I’ve always been a little confused about which inputs to the hooks are useful to include in the component’s props interface and how to correctly annotate them, whether that’s recreating the types or extending from the numerous options within the react-aria package. Radix at least has some suggestions for conventions, and I feel a bit more confident following them.

3. More on the feedback side - React Aria has typically implemented similar-but-different props for the common HTML form control attributes like “disabled” and “onChange” as “isDisabled” and “onValueChange” - I really appreciate these at one level for the internal consistency throughout the library, but I’ve found these choices make it a bit more annoying to integrate React Aria with other third-party libraries meant to “just work” with the regular attributes. E.g. spreading Formik form props for a field into a form control, but having to re-map the onChange prop to onValueChange. Definitely trade offs in either direction, but I’m curious how y’all made the choice and if there are some remediations y’all have found along the way?

Thanks so much for your (and the team’s) work on this! And on Parcel and the million other projects you’re building.

[devongovett]

Thanks for the feedback!

1. We decided to start simple for the first release but it’s definitely possible to add something like asChild if the need arises. There are some tradeoffs to this though, eg it’s easier to mess up the DOM structure required for accessibility. There are some other approaches we’ll be documenting for this as well.

2. TS should be easier now. All the docs examples are now written in TS so you can see where the interfaces are imported from.

3. Yeah prop naming is a trade off. When we started, we decided to make all of the components follow a consistent naming convention. The DOM is quite limited in its functionality (eg you can only submit strings and not more complex objects) and we knew we’d need quite a bit more capability so we decided not to follow it in some areas. But we know integrating with form libraries is a pain point and we might have some documentation or helpers for that in the future.

[awhitty]

1. Understood! Yes, I agree about messing up the DOM, and I'm sure you've seen some egregious cases haha. asChild definitely enables some less deliberate choices when composing bits and pieces together and assumes some good habits around event handlers - probably not an approach that scales well for growing teams, but definitely convenient for hacking on things. Can I bum you for a link or some search terms for the "other approaches"? I'm curious about them.

2. You're spoiling us. Thank you. Re-visiting the hooks docs, I think I was just meant to use the `Aria...Props` interfaces the whole time haha. I have a feeling I overcomplicated some things in that codebase.

3. "you can only submit strings and not more complex objects" - I think this is the crux of the tradeoff. Frankly, the only thing I use Formik for when I bring it in is binding Zod schemas to form state to get validation messages in a pinch. If React Aria had a first-class schema-driven Form component or similar, I'd be a satisfied "customer".

Had another random question overnight -

4. Have y'all considered implementing anything in the realm of the "CSS Spatial Navigation" proposal? The conversation around it looks like it has gone quiet in the past few years, but I think there's definitely an opportunity for non-grid-y 2D navigation in web UIs.