8 ms·

React Aria Components

135 points by itsuka 3y ago

Rapzid 3y ago
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.. I'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. Hope they keep the slot props concept from spectrum. Edit: Slot props are in! Can't explain how much I like the Spectrum projects.
- steve_adams_86 3y ago
  What are slot props?
- hamerld 3y ago
  I'm basically doing the same thing as you but I'm also looking through Mantine's source code to complement it. I haven't really grasped what slot are used for tho, can you share a tldr?
  - Rapzid 3y ago
    It's a set of conventions and utils allowing a parent component to mix properties into slot-aware children so they can be styled and configured to fit within the parent context. https://react-spectrum.adobe.com/react-spectrum/layout.html#slots https://react-spectrum.adobe.com/react-spectrum/layout.html#... Too bad React doesn't have Vue slots built-in, but this is nice for streamlining component APIs. Works well with Tailwind classes.
Etheryte 3y ago
I understand that this release is marked alpha, nonetheless it's pretty funny that opening the dropdown in the first example snippet on the page disables scrolling for the whole page. While it isn't trivial, custom dropdowns that work regardless of container overflow are a solved problem, just pick one of the common solutions and use it.
- chrismorgan 3y ago
  For more information on the actual issue this comment mentions: The page applies `overflow: hidden` to the root element, which isn’t a very good solution to the “you shouldn’t be able to scroll the document while a dropdown is open” problem. It tries to counteract the scrollbar shift problem this causes by applying corresponding padding to the root element (which is still yuck, because the scrollbar still visually disappears, which it shouldn’t), but the page uses `position: fixed` for the header and right ToC sidebar, which bypasses the document padding. End result, opening a dropdown shifts parts of the document, which is bad. I’m not sure if there’s a proper solution that makes it behave how a <select> does on desktop platforms; historically there wasn’t, and every historical workaround causes worse problems than it solves, in my opinion. Also in my opinion, the problem was never particularly important; the only part that was even vaguely notable was scroll chaining, and you can now just specify `overscroll-behavior: contain` on the dropdown popup to categorically fix that. (Browser support: 7½ months in Safari, 5–6 years elsewhere.) Very recently, browsers have been getting better support for modal concepts, driven by the <dialog> element and the corresponding concept of a top layer, as the spec calls it. I haven’t played with it, but I suspect that this might finally be the actual solution to the problem of stopping scrolling underneath.
  - Etheryte 3y ago
    The most common solution used today is Popper, which essentially takes the relevant element out of the DOM and makes it a fixed element with transforms on body (or any element of your choice) instead. It's used by many large projects such as react-select etc. This is an approach that wouldn't have worked well in the days of old due to delays in updating the UI, but modern browsers are very capable with it and there are no discernible issues with alignment. I agree however that native elements are way better wherever that's a valid option since they also have corresponding native elements on mobile devices etc.
    - chrismorgan 3y ago
      I think you might have misunderstood the situation. Popper supports putting popper elements somewhere else in the DOM, but that’s not their general recommendation (https://popper.js.org/docs/v2/performance/#attaching-elements-to-the-dom https://popper.js.org/docs/v2/performance/#attaching-element...). React Aria puts its popups in such a separate place in the DOM like you’re saying. But the part I and the parent were remarking upon is what you do about scrolling. Popper’s (default) answer is “recalculate the preferred position [and size, I think?] on every scroll event”. This is perfectly fine, and sometimes preferable. React Aria’s answer is “position once and then prevent scrolling”. This matches all platforms’ conventions for these sorts of elements, it’s just that the way they’ve implemented it has problems, problems that may be unavoidable at present.
anonzzzies 3y ago
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?
- deleted 3y ago
  [deleted]
- madeofpalk 3y ago
  I feel like the first paragraph - What is React Aria Components? - explains it pretty well. It's a set of unstyled components components for common UI patterns, with accessibility, internationalization, interactions, and behavior built in, allowing you to focus on your unique design and styling rather than re-building these challenging aspects. If you don't like doing UI/styling, this probably isn't for you as these components require you to style them yourself.
- _heimdall 3y ago
  Especially if your most interested in UX, it's be worth going down the rabbit hole of web accessibility. Building sis that work as expected for visitors with visual and physical impairments isn't particularly ready and often skipped entirely, especially in react. I've never used this particular library, but if it's does what it says on the box it should make it easier to have accessible components out of the box so the developer is only focused on making it look good.
- itsuka 3y ago
  This blog post explains why developing accessible components (that work well across devices) is not an easy task: https://react-spectrum.adobe.com/blog/building-a-button-part-1.html https://react-spectrum.adobe.com/blog/building-a-button-part... There are so many UX pitfalls that I prefer to delegate the task of fixing them to a library, while still retaining control over how I want to style them.
- saiojd 3y ago
  I have to ask: when posting a question like this, what kind of response are you hoping to get?
madeofpalk 3y ago
See also Radix UI https://www.radix-ui.com https://www.radix-ui.com for a similar library of unstyled components that focus on handling the interactions for you.
doytch 3y ago
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… 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.
jakelazaroff 3y ago
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. What I really wish is that there were something like this built on web components, so I could use it with any framework.
- beebeepka 3y ago
  I am the opposite. Developing these components is like the most trivial task when starting a new project. Then again, I am not a React guy and usually frown at these prebuilt libraries as they tend to be opinionated and unpleasant to change for the use case at hand. I don't know. Maybe I just don't like "ecosystems"
  - forgotusername6 3y ago
    You write your own component library when you start a new project?
    - beebeepka 3y ago
      It's better than dealing with vuetify and such. Writing this stuff is the easiest thing in a new project. Am I out of touch? What do you do when you have tons of custom functionality and styles? I spent about an year in a huge react only shop and I swear these guys were spending most of their time debugging other people's crappy components. Most of them had your reaction when we talked
      - geraldwhen 3y ago
        It’s a hundred times easier to build <shitty button the designers want with 6 states> from scratch than style an existing component from a component library. I would only use a component library for the things that are hard, like dialogs and multi select weird option lists etc.
kadomony 3y ago
Having managed and led design systems teams, I really don't understand why more of them don't build off of kits like these. So much money is wasted in teams saying they need to build components from scratch.
pjmlp 3y ago
Is this for AEM frontends?
- CPLNTN 3y ago
  It’s suitable for any React codebase, and it’s based on an existing library of React hooks for managing accessibility, which was also created by them.
  - pjmlp 3y ago
    I see, thanks.
Brendinooo 3y ago
We’ve been looking to port to this. We used Reach UI but that seems to be a dying project. It’s really nice to be able to get aria gains without giving up creative control of the visuals.
awhitty 3y ago
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 3y ago
  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.
nomdep 3y ago
The `Link` component is ridiculous: “Links can be created in HTML with the <a> 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”… 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!
lloydatkinson 3y ago
Will this be adding a Box component hopefully?
pull_my_finger 3y ago
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'll definitely want that also if you're using react-aria. I wonder if anyone here has used react-aria and also headless-ui and have any notes about their comparison.

135 points by itsuka 3y ago

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.. I'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. Hope they keep the slot props concept from spectrum. Edit: Slot props are in! Can't explain how much I like the Spectrum projects.

steve_adams_86 3y ago
What are slot props?
hamerld 3y ago
I'm basically doing the same thing as you but I'm also looking through Mantine's source code to complement it. I haven't really grasped what slot are used for tho, can you share a tldr?
- Rapzid 3y ago
  It's a set of conventions and utils allowing a parent component to mix properties into slot-aware children so they can be styled and configured to fit within the parent context. https://react-spectrum.adobe.com/react-spectrum/layout.html#slots https://react-spectrum.adobe.com/react-spectrum/layout.html#... Too bad React doesn't have Vue slots built-in, but this is nice for streamlining component APIs. Works well with Tailwind classes.

Etheryte 3y ago

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

chrismorgan 3y ago
For more information on the actual issue this comment mentions: The page applies `overflow: hidden` to the root element, which isn’t a very good solution to the “you shouldn’t be able to scroll the document while a dropdown is open” problem. It tries to counteract the scrollbar shift problem this causes by applying corresponding padding to the root element (which is still yuck, because the scrollbar still visually disappears, which it shouldn’t), but the page uses `position: fixed` for the header and right ToC sidebar, which bypasses the document padding. End result, opening a dropdown shifts parts of the document, which is bad. I’m not sure if there’s a proper solution that makes it behave how a <select> does on desktop platforms; historically there wasn’t, and every historical workaround causes worse problems than it solves, in my opinion. Also in my opinion, the problem was never particularly important; the only part that was even vaguely notable was scroll chaining, and you can now just specify `overscroll-behavior: contain` on the dropdown popup to categorically fix that. (Browser support: 7½ months in Safari, 5–6 years elsewhere.) Very recently, browsers have been getting better support for modal concepts, driven by the <dialog> element and the corresponding concept of a top layer, as the spec calls it. I haven’t played with it, but I suspect that this might finally be the actual solution to the problem of stopping scrolling underneath.
- Etheryte 3y ago
  The most common solution used today is Popper, which essentially takes the relevant element out of the DOM and makes it a fixed element with transforms on body (or any element of your choice) instead. It's used by many large projects such as react-select etc. This is an approach that wouldn't have worked well in the days of old due to delays in updating the UI, but modern browsers are very capable with it and there are no discernible issues with alignment. I agree however that native elements are way better wherever that's a valid option since they also have corresponding native elements on mobile devices etc.
  - chrismorgan 3y ago
    I think you might have misunderstood the situation. Popper supports putting popper elements somewhere else in the DOM, but that’s not their general recommendation (https://popper.js.org/docs/v2/performance/#attaching-elements-to-the-dom https://popper.js.org/docs/v2/performance/#attaching-element...). React Aria puts its popups in such a separate place in the DOM like you’re saying. But the part I and the parent were remarking upon is what you do about scrolling. Popper’s (default) answer is “recalculate the preferred position [and size, I think?] on every scroll event”. This is perfectly fine, and sometimes preferable. React Aria’s answer is “position once and then prevent scrolling”. This matches all platforms’ conventions for these sorts of elements, it’s just that the way they’ve implemented it has problems, problems that may be unavoidable at present.

anonzzzies 3y ago

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?

deleted 3y ago
[deleted]
madeofpalk 3y ago
I feel like the first paragraph - What is React Aria Components? - explains it pretty well. It's a set of unstyled components components for common UI patterns, with accessibility, internationalization, interactions, and behavior built in, allowing you to focus on your unique design and styling rather than re-building these challenging aspects. If you don't like doing UI/styling, this probably isn't for you as these components require you to style them yourself.
_heimdall 3y ago
Especially if your most interested in UX, it's be worth going down the rabbit hole of web accessibility. Building sis that work as expected for visitors with visual and physical impairments isn't particularly ready and often skipped entirely, especially in react. I've never used this particular library, but if it's does what it says on the box it should make it easier to have accessible components out of the box so the developer is only focused on making it look good.
itsuka 3y ago
This blog post explains why developing accessible components (that work well across devices) is not an easy task: https://react-spectrum.adobe.com/blog/building-a-button-part-1.html https://react-spectrum.adobe.com/blog/building-a-button-part... There are so many UX pitfalls that I prefer to delegate the task of fixing them to a library, while still retaining control over how I want to style them.
saiojd 3y ago
I have to ask: when posting a question like this, what kind of response are you hoping to get?

madeofpalk 3y ago

See also Radix UI https://www.radix-ui.com https://www.radix-ui.com for a similar library of unstyled components that focus on handling the interactions for you.

doytch 3y ago

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… 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.

jakelazaroff 3y ago

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. What I really wish is that there were something like this built on web components, so I could use it with any framework.

beebeepka 3y ago
I am the opposite. Developing these components is like the most trivial task when starting a new project. Then again, I am not a React guy and usually frown at these prebuilt libraries as they tend to be opinionated and unpleasant to change for the use case at hand. I don't know. Maybe I just don't like "ecosystems"
- forgotusername6 3y ago
  You write your own component library when you start a new project?
  - beebeepka 3y ago
    It's better than dealing with vuetify and such. Writing this stuff is the easiest thing in a new project. Am I out of touch? What do you do when you have tons of custom functionality and styles? I spent about an year in a huge react only shop and I swear these guys were spending most of their time debugging other people's crappy components. Most of them had your reaction when we talked
    - geraldwhen 3y ago
      It’s a hundred times easier to build <shitty button the designers want with 6 states> from scratch than style an existing component from a component library. I would only use a component library for the things that are hard, like dialogs and multi select weird option lists etc.

kadomony 3y ago

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

pjmlp 3y ago

Is this for AEM frontends?

CPLNTN 3y ago
It’s suitable for any React codebase, and it’s based on an existing library of React hooks for managing accessibility, which was also created by them.
- pjmlp 3y ago
  I see, thanks.

Brendinooo 3y ago

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

awhitty 3y ago

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 3y ago
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.

nomdep 3y ago

The `Link` component is ridiculous: “Links can be created in HTML with the <a> 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”… 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!

lloydatkinson 3y ago

Will this be adding a Box component hopefully?

pull_my_finger 3y ago

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'll definitely want that also if you're using react-aria. I wonder if anyone here has used react-aria and also headless-ui and have any notes about their comparison.