React Aria Components

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.<p>Couple questions&#x2F;feedbacks if you’re still in the comments, Devon!<p>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.<p>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.<p>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?<p>Thanks so much for your (and the team’s) work on this! And on Parcel and the million other projects you’re building.

Libraries like this are what keep me using React. They’re (imo) table stakes for building any serious project. I really want to use Svelte and Solid more, but the choices for building complex widgets like dropdowns are either “forget about accessibility” or “sink a bunch of time into implementing it yourself”. And let’s face it — most self-implemented widgets are accessibility nightmares.<p>What I really wish is that there were something like this built on web components, so I could use it with <i>any</i> framework.

I understand that this release is marked alpha, nonetheless it&#x27;s pretty funny that opening the dropdown in the first example snippet on the page disables scrolling for the whole page. While it isn&#x27;t trivial, custom dropdowns that work regardless of container overflow are a solved problem, just pick one of the common solutions and use it.

Interesting. I’ve loved using react-aria on past projects even with the amount of glue code you needed to write sometimes. Its not even that it was so much typing, but devs instinctively tried to abstract away reused code (“DRY!”) but would then inevitably run into issues and risk creating monstrosities… I’m thinking specifically of anything that used popovers…<p>I do like the idea that you can use these components as a starting point and drop down to first principles with react-aria hooks if it suits the use case.

Having managed and led design systems teams, I really don&#x27;t understand why more of them don&#x27;t build off of kits like these. So much money is wasted in teams saying they need to build components from scratch.

Amazing. Been building a custom system on Aria while looking at the spectrum code for learning, familiarity with their architecture, and to avoid their style system as we are using tailwind..<p>I&#x27;m excited to try these out and possibly switch over and fill in the gaps. Lots of headless systems are locked into a particular styling system but this looks super flexible and will work perfect with Tailwind. Love the callback for classname that supplies states.<p>Hope they keep the slot props concept from spectrum.<p>Edit: Slot props are in! Can&#x27;t explain how much I like the Spectrum projects.

See also Radix UI <a href="https:&#x2F;&#x2F;www.radix-ui.com" rel="nofollow">https:&#x2F;&#x2F;www.radix-ui.com</a> for a similar library of unstyled components that focus on handling the interactions for you.

The `Link` component is ridiculous: “Links can be created in HTML with the &lt;a&gt; element with an href attribute. However, if the link does not have an href, and is handled client side with JavaScript instead, it will not be exposed to assistive technology properly”…<p>Sure, sure, but if your link doesn’t have an href, it’s because you don’t want a link, you want an unstyled button!

We’ve been looking to port to this. We used Reach UI but that seems to be a dying project.<p>It’s really nice to be able to get aria gains without giving up creative control of the visuals.

I used this on a project recently and I regret it honestly. It just made unnecessarily complicated. All the docs depend on the sibling library react-stately also, so you&#x27;ll definitely want that also if you&#x27;re using react-aria.<p>I wonder if anyone here has used react-aria and also headless-ui and have any notes about their comparison.

Will this be adding a Box component hopefully?

Is this for AEM frontends?

So, for someone who couldn’t care less about UI but focuses on UX all the time; does this help me? It looks like the same awful as everything else frontend to me. Why is it interesting? Honest question?