18 ms·

React Aria: A headless UI component library

224 points by xyzzyrz 5y ago

r0d 5y ago
What would I use a headless UI on top of my css styling when Chakra UI already follows WAI-ARIA standards for every component and it gives me all the freedom of customizing my css inline?
- chungwu 5y ago
  For some components, like a button, overriding some css may be all you need. But other components can be more "opinionated" - for example, for a Slider component, do you want to label your thumb value? Does it go on the side of the slider or on top? Maybe even embedded into the slider track itself? Is it only visible when you're dragging or always there? What if there are multiple thumbs? Etc. Some libraries will offer a ton of props to customize different parts of a component - and for some use cases, that is enough. But sometimes it is just easier to structure and style the component however you want, with custom behavior sprinkled in, and then letting a library like react-aria take care of the rest.
deltaci 5y ago
can someone explain in layman terms what is headless UI?
- conorwade 5y ago
  It give you the behaviours needed to implement a UI component, but it doesn’t give you any styling.
- dsego 5y ago
  I think you are supposed to do the rendering, it just gives you the behaviors. https://www.merrickchristensen.com/articles/headless-user-interface-components/ https://www.merrickchristensen.com/articles/headless-user-in...
- jokull 5y ago
  "Bring your own UI". You get the behavior from the library but they are completely unstyled or without the component layer where the styles live. Other libraries include Radix and HeadlessUI. Here's a presentation from one of the Radix library authors about how to build dropdowns in React, it serves as a good explainer about what goes into a headless UI library component. https://www.youtube.com/watch?v=lY-RQjWeweo https://www.youtube.com/watch?v=lY-RQjWeweo
  - spyke112 5y ago
    Why not just use default html elements?
    - fnordsensei 5y ago
      Some common, but complex, UI components are hard to get right, especially when it comes to accessibility. Combo boxes in particular come to mind.
      - devongovett 5y ago
        Yeah ComboBox is one of the most difficult. We wrote a post about the work that went into ours. https://react-spectrum.adobe.com/blog/building-a-combobox.html https://react-spectrum.adobe.com/blog/building-a-combobox.ht...
    - ojkelly 5y ago
      There’s a lot of UI elements that are not in the set of html elements. Sometimes you need different behaviours. I think it’s still best to build on the native elements first though.
    - deergomoo 5y ago
      They’re pretty lacking. <select> is a great example: no searching/filtering, no ability to have styled/multiline text in <option>s, nor anything that’s not plain text (so no SVG iconography for example). People constantly have to reinvent the wheel to offer fairly basic functionality, so it’s good that there are libraries to handle the behaviour and accessibility side well while supporting whatever visual styles you want to make.
- nsonha 5y ago
  It's not a thing, this is just a term made up on the spot by the author of this article to describe a component library that has no built-in style. "What does it even do then" you ask. It implements basic accessibility patterns so you only deal with high level UI elements and not have to worry about having the correct `role-` or `aria-` attributes. That and composite elements such as tabs or modals Why no style? Most product teams have a design system and they actually overwrite the style of component libraries anyway. So better to have component libraries without style, less bloat.
  - thirdvect0r 5y ago
    HeadlessUI[1] has been around for over a year, it's not a term this author made up [1] https://headlessui.dev/ https://headlessui.dev/
    - tshaddox 5y ago
      HeadlessUI is one of the newcomers, with a lot of name recognition due to its affiliation with the wildly popular library Tailwind. The term has been around much longer. The first commit of the awesome list was over 3 years ago, and I suspect the term was already fairly established at that point: https://github.com/jxom/awesome-react-headless-components/commit/ba4dd2025aa97e6085b5c2829ef872fd0effcd66 https://github.com/jxom/awesome-react-headless-components/co...
  - andrewingram 5y ago
    I mean, at some point someone made up the term, but it's been floating around for years to describe this exact concept.
- zettadam 5y ago
  'headless' means you bring your own html structure, the library provides interaction and state exposed by props or hooks. As such, I am not sure Headless UI is headless since they only let you bring your own CSS. At that point, it's a lot easier to create your own set of components that you have full control over than to include another NPM dependency.
skohan 5y ago
It's a nice idea. I've recently been working with React more, and one of the things which can be frustrating is that it's often hard to find the right level of composability if you want to combine ready-made components. I.e. if you are looking for something like a spreadsheet as a component, maybe you find one with the correct behaviors, but it handles animations in a way you don't like. Or maybe you have to pick something non-optimal because it comes with the drag-and-drop handling you want. Or you have to build completely from scratch if you want to achieve exactly what you want. In other words, it would be nice to have slices of UI behavior defined more orthogonally in a way which can be more freely layered, and it seems like this is a step in that direction.
- fastball 5y ago
  Like this? https://github.com/tannerlinsley/react-table/ https://github.com/tannerlinsley/react-table/
- dTal 5y ago
  From the developer perspective, I can certainly relate. From the user perspective, yet another widget with subtly different behaviour is very annoying. I'd much rather you add drag and drop handling to the existing widget so that everyone benefits and UIs remain consistent.
  - skohan 5y ago
    Yeah I get this argument for native apps, but does it really make sense in the context of a React app? If I'm combining components from different authors, what's more important to the user is consistency between components in my application, not consistency for an individual component across different unrelated sites.
    - dTal 5y ago
      In the age of SPAs and Electron, can we really distinguish between "React apps" and "native apps"? The user doesn't care about the technical details - they just want a consistent UI throughout their computing experience. <rant> Hell, back in the 2000s, even web apps used native widgets, and we shamed websites that implemented their own UIs in Flash because they were bloated and inaccessible. Now we do it in Javascript and it's considered okay, even though all the same objections apply. And with Electron apps we've managed to combine all the worst aspects of web apps and native apps - they're slow, non-native and not cross-platform, and don't have text search, and still have to be installed. </rant>
Eduard 5y ago
Where is carousel?
geniium 5y ago
Seeing that Adobe logo made me leave the site instantly.
endisneigh 5y ago
The never ending battle between customizability and uniqueness. If there were a standard library (adopted by all browsers) similar to the default look of iOS and Android apps, but in return you couldn't customize the look, would y'all go with that?
- gherkinnn 5y ago
  Just that it won't look the same across different browsers and platforms. They will also work differently, have slightly different options, and not every element will be available everywhere anyway. Give me the primitives any day.
  - endisneigh 5y ago
    The hypothetical is explicitly that if it did look and behave the same as well as having the same elements.
    - gherkinnn 5y ago
      If browser vendors today can't even decide on uniform search boxes, that's a hypothetical too far away to entertain.
- aitchnyu 5y ago
  I hope its appreciated. My mum used a Windows laptop and the apps were like a toystore. I got her a Macbook and the same apps looked uniform and they obeyed the accessibility settings perfectly.
- tshaddox 5y ago
  I suspect many people would use that for the functionality that it provided, but web standards are always going to move slower than individual developers and UI trends, and that’s good! Imagine if we had to wait for web standards to develop a road map element.
namelosw 5y ago
Headless UI is a great idea. As someone who was wrestling with different kinds of data tables, calendars, and rich text editors for a while, using headless UI libraries feels like a breeze.
deadcoder0904 5y ago
Cool to see more competition to Headless UI [0] by the Tailwind guys [0]: https://headlessui.dev/ https://headlessui.dev/
- nsonha 5y ago
  This came before it I think, and even before that I know ReachUI and Reakit
- onion2k 5y ago
  There's also https://www.radix-ui.com/ https://www.radix-ui.com/ which is excellent.
- zettadam 5y ago
  In what way is Headless UI 'headless'?
  - vereis 5y ago
    It doesn't come with any styling OOTB. The idea is that you're just building a frontend (all the markup, styling etc) around some provided state management
    - zettadam 5y ago
      `react-table` is headless. I am forced to create my own html structure and am in control of the markup from the start. `headless-ui` provides those components which doesn't give me full control over markup, does it?
      - illumanaughty 5y ago
        It gives you complete control over your markup and styling. Headless UI is designed to handle everything except what the components look like.
        zettadam 5y ago
tannhaeuser 5y ago
Isn't the point of an UI to have an ... UI after all? The only ones that I can see being headless here are customers buying in to headless UIs, headless CMSs quackery.
- krembanan 5y ago
  Not at all, accessibility is important. Try building a fully accessible dropdown from scratch in React? This is what these libraries solve. An example from Radix UI: https://youtu.be/pcMYcjtWwVI https://youtu.be/pcMYcjtWwVI
- robertlagrant 5y ago
  > headless CMSs quackery Headless CMSes are useful as well once you exit the realm of blogs and WYSIWYG website builders.
ramboldio 5y ago
It seems really useful. But the fact that this is useful feels like a code smell in the web platform. It would be cool to go back to HTML=schematics and CSS=styling. Maybe CSS needs to become more capable tool to place divs more easily?
- Cthulhu_ 5y ago
  > Maybe CSS needs to become more capable tool to place divs more easily? What's the issue now then? Flexbox is straightforward enough.
alexaholic 5y ago
I was under the impression Adobe was investing heavily into Web Components. I gather that didn't work out well?
- eatonphil 5y ago
  Companies of that size always have many disparate efforts going on.
- Existenceblinks 5y ago
  Isn't it being used in the new browser based Photoshop?
- bnjm 5y ago
  I would love to hear from one of the Adobe team members about this. Are there separate React teams and WC teams? What’s that dynamic like? It feels like Photoshop on the web has been framed as ‘powered by web components’, rather than WCs being a minor detail. This post mentions “islands of React code” as if React is a legacy thing they have to put up with https://web.dev/ps-on-the-web/ https://web.dev/ps-on-the-web/
  - devongovett 5y ago
    I work on React Aria. Adobe is a big company and there are many teams using different technologies. In general, some very new parts of creative cloud chose to use web components, but the majority of teams are using React, and I don't foresee that changing anytime soon. It's definitely not a company wide shift if you got that impression from the Photoshop article. Ideally we'd collaborate more, but... big company silos.
    - bnjm 5y ago
      Thanks for the response and great work on React Aria. That makes sense. To be honest the impression probably came more from tweets about the article than the article itself https://mobile.twitter.com/search?q=https%3A%2F%2Fweb.dev%2Fps-on-the-web%2F&src=typed_query&f=top https://mobile.twitter.com/search?q=https%3A%2F%2Fweb.dev%2F... I can see the appeal of web components when your interop issues are as large Adobe’s must be. On the other hand if huge portions of your apps are canvas / wasm then web components’ DOM-centric component model might feel awkward or constraining
konradkpl 5y ago
React Aria is a great project! We used it to meet WCAG 2.1 level AA requirements in our chat widget. It's even hard to assess how many days of work we have saved thanks to this solution. We've covered a bit of our experience in multiple posts, e.g. with handling keyboard navigation: https://developers.livechat.com/updates/livechat-accessibility-keyboard-navigation/ https://developers.livechat.com/updates/livechat-accessibili...).
- raxxorrax 5y ago
  It is nice that Aria itself gets some attention, since Aria is quite unknown by many people despite its age. It isn't only blind or otherwise disabled people that would profit from controls and content being decently tagged and classified, even if that is the scope of it. It is however quite extensive as you can see by the role definitions: https://www.w3.org/TR/wai-aria-1.1/img/rdf_model.png https://www.w3.org/TR/wai-aria-1.1/img/rdf_model.png Don't know if that is still best practice, screen readers probably are way smarter today.
naasking 5y ago
I haven't gotten into react yet, but am looking at a new project where it might be useful. Out of curiosity, are there drop-in compatible replacements for the standard React libraries, like maybe Preact?
- jonplackett 5y ago
  My advice - start with Next.js. Only got started with React myself a year ago (and love it) and to be gone it’s I though, I’ll just stick to nice simple react I bet I don’t need the other stuff. And then, I gradually realised why people use all this other stuff. Next.js solves so many problems!
  - naasking 5y ago
    Not interested in the server-side stuff as I don't use JS/Node on the backend. I see that Next.js is a Node framework, so unless there's a cut down client-side only version that's useful, not sure it'll fit the bill. I was looking at Alpine.js but it's pretty minimal, so I want something more full-featured to compare to. These headless UIs look useful, and some have React and Vue versions.
    - Vinnl 5y ago
      Next.js has `next export` which generates a client-side only bundle. It's really neat, as it saves you a lot of manual setting up and maintenance of configuration files, assuming your app fits in the boundaries of Next.js's use cases - which most do.
    - micahbule 5y ago
      While it's true that it's a Node framework, NextJS can totally function like a client-side React framework. NextJS just bakes a lot of basic and common functionality such as routing, built-in support for CSS modules, as well as optimizations (it's not premature if it's baked in already). The server-side mostly just takes place if you utilize the following: - Built-in API - Server-side Rendering
    - _fat_santa 5y ago
felizuno 5y ago
First and foremost I like hooks libraries and think there should be more of them. That said when looking at their examples this appears to require exactly the same code you would need anyways, but with the additional boilerplate required by the library. Is the goal to add intellisense for people who don't already know how to write accessible front ends? Is the goal to enable me to use a div as a button via hook instead of writing semantic HTML? Not trying to be rude but honestly not seeing the value add outside maybe the FocusScope's restoreFocus and there is no way that works 100% as expected in the wild. IMO the community is much better served by tools that help you identify accessibility gaps during the design phase, experience your application in other usage paradigms, or audit third party packages for accessibility before taking them as dependencies. If you work with designers who love hover triggered tooltips with forms with more tooltips inside them this library cannot fix the fact that you're making a terrible experience. If you want to npm install React-ported Kendo components because you "remember they worked well with jQuery" this library will not make them accessible. Turn voiceover on, turn your screen off, eat your own dog food. What's worse "accessibility helper libraries" like this often get used as an excuse to say "of course we made this accessible look at all the helpers in the code" but the team never actually audits to see what the experience is like (hint: your Lighthouse accessibility score does not indicate WCAG compliance), and surprise surprise they've incorrectly implemented the helpers in a way that actually degrades the experience. Then they pay my agency a lot of money to hurry up and do it the right way before the NFB lawsuit drops.
- chungwu 5y ago
  react-aria is about more than just putting the aria-attributes in the right place. It also takes care of interactivity, keyboard accessibility, focus management, and smoothing over some crazy differences between browsers. Sure, it's all code that you can write yourself, but it's complicated and subtle to get right, and it's how we end up with all these half broken components on the web. Here's a good example of deep thinking and investigative work that goes into react-aria: https://react-spectrum.adobe.com/blog/building-a-combobox.html https://react-spectrum.adobe.com/blog/building-a-combobox.ht...
chungwu 5y ago
react-aria is awesome. You structure your DOM and css however you want, and react-aria provides hooks that return props to spread onto your elements to make them come alive. These same hooks also give you visibility into and control of the component state, so you can also easily blend in your own custom logic for the component. It is about as flexible as a headless ui library can get. But it's also lower level and so harder to use than, say, radix primitives. I work on Plasmic (plasmic.app), a visual builder for React. With react-aria, we're able to let our users build, say, a Select component visually however they want, and then we just use the hooks to spread the right props to the right elements, and It Just Works. See https://youtu.be/mPHS2zg2a8Y https://youtu.be/mPHS2zg2a8Y Headless UI is an exciting space. There's only so far you can go with re-skinning material ui or antd, and no one should be building their own from scratch. These headless libraries give you all the interactivity and accessibility you need for your components, but still give you total freedom over how they look. It is the way!
wly_cdgr 5y ago
Man, this must be such tedious hell to test
- devongovett 5y ago
  Haha yes it is. We have to do a ton of manual testing to ensure consistency and compatibility across many devices, browsers, and screen readers. Some of my tweets showing how we do this: - https://twitter.com/devongovett/status/1318600389462126592 https://twitter.com/devongovett/status/1318600389462126592 - https://twitter.com/devongovett/status/1270410802395111424 https://twitter.com/devongovett/status/1270410802395111424 - https://twitter.com/devongovett/status/1318676759080968193 https://twitter.com/devongovett/status/1318676759080968193
steve76 5y ago
Every component now needs a ref. Isn't that a problem?
aarpmcgee 5y ago
I've been using react-aria on a personal project, as well as building a UI library at work based on TailwindCSS+React Aria. I generally really like the combination. The maintainers are super responsive+helpful on Github and really know how to engage constructively with criticism. I really appreciate what they're doing. The combination of TailwindCSS+React Aria provides one with a pretty great template/scaffolding for building out a fully featured component library. The only downside that I've found is that their typescript support can be a little weird in my experience, but their approach is nonetheless well considered imo. edit: https://github.com/adobe/react-spectrum/pull/1761#issuecomment-910841975 https://github.com/adobe/react-spectrum/pull/1761#issuecomme... is a decent summary of what I'm referring.

224 points by xyzzyrz 5y ago

r0d 5y ago

What would I use a headless UI on top of my css styling when Chakra UI already follows WAI-ARIA standards for every component and it gives me all the freedom of customizing my css inline?

chungwu 5y ago
For some components, like a button, overriding some css may be all you need. But other components can be more "opinionated" - for example, for a Slider component, do you want to label your thumb value? Does it go on the side of the slider or on top? Maybe even embedded into the slider track itself? Is it only visible when you're dragging or always there? What if there are multiple thumbs? Etc. Some libraries will offer a ton of props to customize different parts of a component - and for some use cases, that is enough. But sometimes it is just easier to structure and style the component however you want, with custom behavior sprinkled in, and then letting a library like react-aria take care of the rest.

deltaci 5y ago

can someone explain in layman terms what is headless UI?

conorwade 5y ago
It give you the behaviours needed to implement a UI component, but it doesn’t give you any styling.
dsego 5y ago
I think you are supposed to do the rendering, it just gives you the behaviors. https://www.merrickchristensen.com/articles/headless-user-interface-components/ https://www.merrickchristensen.com/articles/headless-user-in...
jokull 5y ago
"Bring your own UI". You get the behavior from the library but they are completely unstyled or without the component layer where the styles live. Other libraries include Radix and HeadlessUI. Here's a presentation from one of the Radix library authors about how to build dropdowns in React, it serves as a good explainer about what goes into a headless UI library component. https://www.youtube.com/watch?v=lY-RQjWeweo https://www.youtube.com/watch?v=lY-RQjWeweo
- spyke112 5y ago
  Why not just use default html elements?
  - fnordsensei 5y ago
    Some common, but complex, UI components are hard to get right, especially when it comes to accessibility. Combo boxes in particular come to mind.
    - devongovett 5y ago
      Yeah ComboBox is one of the most difficult. We wrote a post about the work that went into ours. https://react-spectrum.adobe.com/blog/building-a-combobox.html https://react-spectrum.adobe.com/blog/building-a-combobox.ht...
  - ojkelly 5y ago
    There’s a lot of UI elements that are not in the set of html elements. Sometimes you need different behaviours. I think it’s still best to build on the native elements first though.
  - deergomoo 5y ago
    They’re pretty lacking. <select> is a great example: no searching/filtering, no ability to have styled/multiline text in <option>s, nor anything that’s not plain text (so no SVG iconography for example). People constantly have to reinvent the wheel to offer fairly basic functionality, so it’s good that there are libraries to handle the behaviour and accessibility side well while supporting whatever visual styles you want to make.
nsonha 5y ago
It's not a thing, this is just a term made up on the spot by the author of this article to describe a component library that has no built-in style. "What does it even do then" you ask. It implements basic accessibility patterns so you only deal with high level UI elements and not have to worry about having the correct `role-` or `aria-` attributes. That and composite elements such as tabs or modals Why no style? Most product teams have a design system and they actually overwrite the style of component libraries anyway. So better to have component libraries without style, less bloat.
- thirdvect0r 5y ago
  HeadlessUI[1] has been around for over a year, it's not a term this author made up [1] https://headlessui.dev/ https://headlessui.dev/
  - tshaddox 5y ago
    HeadlessUI is one of the newcomers, with a lot of name recognition due to its affiliation with the wildly popular library Tailwind. The term has been around much longer. The first commit of the awesome list was over 3 years ago, and I suspect the term was already fairly established at that point: https://github.com/jxom/awesome-react-headless-components/commit/ba4dd2025aa97e6085b5c2829ef872fd0effcd66 https://github.com/jxom/awesome-react-headless-components/co...
- andrewingram 5y ago
  I mean, at some point someone made up the term, but it's been floating around for years to describe this exact concept.
zettadam 5y ago
'headless' means you bring your own html structure, the library provides interaction and state exposed by props or hooks. As such, I am not sure Headless UI is headless since they only let you bring your own CSS. At that point, it's a lot easier to create your own set of components that you have full control over than to include another NPM dependency.

skohan 5y ago

It's a nice idea. I've recently been working with React more, and one of the things which can be frustrating is that it's often hard to find the right level of composability if you want to combine ready-made components. I.e. if you are looking for something like a spreadsheet as a component, maybe you find one with the correct behaviors, but it handles animations in a way you don't like. Or maybe you have to pick something non-optimal because it comes with the drag-and-drop handling you want. Or you have to build completely from scratch if you want to achieve exactly what you want. In other words, it would be nice to have slices of UI behavior defined more orthogonally in a way which can be more freely layered, and it seems like this is a step in that direction.

fastball 5y ago
Like this? https://github.com/tannerlinsley/react-table/ https://github.com/tannerlinsley/react-table/
dTal 5y ago
From the developer perspective, I can certainly relate. From the user perspective, yet another widget with subtly different behaviour is very annoying. I'd much rather you add drag and drop handling to the existing widget so that everyone benefits and UIs remain consistent.
- skohan 5y ago
  Yeah I get this argument for native apps, but does it really make sense in the context of a React app? If I'm combining components from different authors, what's more important to the user is consistency between components in my application, not consistency for an individual component across different unrelated sites.
  - dTal 5y ago
    In the age of SPAs and Electron, can we really distinguish between "React apps" and "native apps"? The user doesn't care about the technical details - they just want a consistent UI throughout their computing experience. <rant> Hell, back in the 2000s, even web apps used native widgets, and we shamed websites that implemented their own UIs in Flash because they were bloated and inaccessible. Now we do it in Javascript and it's considered okay, even though all the same objections apply. And with Electron apps we've managed to combine all the worst aspects of web apps and native apps - they're slow, non-native and not cross-platform, and don't have text search, and still have to be installed. </rant>

Eduard 5y ago

Where is carousel?

geniium 5y ago

Seeing that Adobe logo made me leave the site instantly.

endisneigh 5y ago

The never ending battle between customizability and uniqueness. If there were a standard library (adopted by all browsers) similar to the default look of iOS and Android apps, but in return you couldn't customize the look, would y'all go with that?

gherkinnn 5y ago
Just that it won't look the same across different browsers and platforms. They will also work differently, have slightly different options, and not every element will be available everywhere anyway. Give me the primitives any day.
- endisneigh 5y ago
  The hypothetical is explicitly that if it did look and behave the same as well as having the same elements.
  - gherkinnn 5y ago
    If browser vendors today can't even decide on uniform search boxes, that's a hypothetical too far away to entertain.
aitchnyu 5y ago
I hope its appreciated. My mum used a Windows laptop and the apps were like a toystore. I got her a Macbook and the same apps looked uniform and they obeyed the accessibility settings perfectly.
tshaddox 5y ago
I suspect many people would use that for the functionality that it provided, but web standards are always going to move slower than individual developers and UI trends, and that’s good! Imagine if we had to wait for web standards to develop a road map element.

namelosw 5y ago

Headless UI is a great idea. As someone who was wrestling with different kinds of data tables, calendars, and rich text editors for a while, using headless UI libraries feels like a breeze.

deadcoder0904 5y ago

Cool to see more competition to Headless UI [0] by the Tailwind guys [0]: https://headlessui.dev/ https://headlessui.dev/

nsonha 5y ago
This came before it I think, and even before that I know ReachUI and Reakit
onion2k 5y ago
There's also https://www.radix-ui.com/ https://www.radix-ui.com/ which is excellent.
zettadam 5y ago
In what way is Headless UI 'headless'?
- vereis 5y ago
  It doesn't come with any styling OOTB. The idea is that you're just building a frontend (all the markup, styling etc) around some provided state management
  - zettadam 5y ago
    `react-table` is headless. I am forced to create my own html structure and am in control of the markup from the start. `headless-ui` provides those components which doesn't give me full control over markup, does it?
    - illumanaughty 5y ago
      It gives you complete control over your markup and styling. Headless UI is designed to handle everything except what the components look like.
      - zettadam 5y ago

tannhaeuser 5y ago

Isn't the point of an UI to have an ... UI after all? The only ones that I can see being headless here are customers buying in to headless UIs, headless CMSs quackery.

krembanan 5y ago
Not at all, accessibility is important. Try building a fully accessible dropdown from scratch in React? This is what these libraries solve. An example from Radix UI: https://youtu.be/pcMYcjtWwVI https://youtu.be/pcMYcjtWwVI
robertlagrant 5y ago
> headless CMSs quackery Headless CMSes are useful as well once you exit the realm of blogs and WYSIWYG website builders.

ramboldio 5y ago

It seems really useful. But the fact that this is useful feels like a code smell in the web platform. It would be cool to go back to HTML=schematics and CSS=styling. Maybe CSS needs to become more capable tool to place divs more easily?

Cthulhu_ 5y ago
> Maybe CSS needs to become more capable tool to place divs more easily? What's the issue now then? Flexbox is straightforward enough.

alexaholic 5y ago

I was under the impression Adobe was investing heavily into Web Components. I gather that didn't work out well?

eatonphil 5y ago
Companies of that size always have many disparate efforts going on.
Existenceblinks 5y ago
Isn't it being used in the new browser based Photoshop?
bnjm 5y ago
I would love to hear from one of the Adobe team members about this. Are there separate React teams and WC teams? What’s that dynamic like? It feels like Photoshop on the web has been framed as ‘powered by web components’, rather than WCs being a minor detail. This post mentions “islands of React code” as if React is a legacy thing they have to put up with https://web.dev/ps-on-the-web/ https://web.dev/ps-on-the-web/
- devongovett 5y ago
  I work on React Aria. Adobe is a big company and there are many teams using different technologies. In general, some very new parts of creative cloud chose to use web components, but the majority of teams are using React, and I don't foresee that changing anytime soon. It's definitely not a company wide shift if you got that impression from the Photoshop article. Ideally we'd collaborate more, but... big company silos.
  - bnjm 5y ago
    Thanks for the response and great work on React Aria. That makes sense. To be honest the impression probably came more from tweets about the article than the article itself https://mobile.twitter.com/search?q=https%3A%2F%2Fweb.dev%2Fps-on-the-web%2F&src=typed_query&f=top https://mobile.twitter.com/search?q=https%3A%2F%2Fweb.dev%2F... I can see the appeal of web components when your interop issues are as large Adobe’s must be. On the other hand if huge portions of your apps are canvas / wasm then web components’ DOM-centric component model might feel awkward or constraining

konradkpl 5y ago

React Aria is a great project! We used it to meet WCAG 2.1 level AA requirements in our chat widget. It's even hard to assess how many days of work we have saved thanks to this solution. We've covered a bit of our experience in multiple posts, e.g. with handling keyboard navigation: https://developers.livechat.com/updates/livechat-accessibility-keyboard-navigation/ https://developers.livechat.com/updates/livechat-accessibili...).

raxxorrax 5y ago
It is nice that Aria itself gets some attention, since Aria is quite unknown by many people despite its age. It isn't only blind or otherwise disabled people that would profit from controls and content being decently tagged and classified, even if that is the scope of it. It is however quite extensive as you can see by the role definitions: https://www.w3.org/TR/wai-aria-1.1/img/rdf_model.png https://www.w3.org/TR/wai-aria-1.1/img/rdf_model.png Don't know if that is still best practice, screen readers probably are way smarter today.

naasking 5y ago

I haven't gotten into react yet, but am looking at a new project where it might be useful. Out of curiosity, are there drop-in compatible replacements for the standard React libraries, like maybe Preact?

jonplackett 5y ago
My advice - start with Next.js. Only got started with React myself a year ago (and love it) and to be gone it’s I though, I’ll just stick to nice simple react I bet I don’t need the other stuff. And then, I gradually realised why people use all this other stuff. Next.js solves so many problems!
- naasking 5y ago
  Not interested in the server-side stuff as I don't use JS/Node on the backend. I see that Next.js is a Node framework, so unless there's a cut down client-side only version that's useful, not sure it'll fit the bill. I was looking at Alpine.js but it's pretty minimal, so I want something more full-featured to compare to. These headless UIs look useful, and some have React and Vue versions.
  - Vinnl 5y ago
    Next.js has `next export` which generates a client-side only bundle. It's really neat, as it saves you a lot of manual setting up and maintenance of configuration files, assuming your app fits in the boundaries of Next.js's use cases - which most do.
  - micahbule 5y ago
    While it's true that it's a Node framework, NextJS can totally function like a client-side React framework. NextJS just bakes a lot of basic and common functionality such as routing, built-in support for CSS modules, as well as optimizations (it's not premature if it's baked in already). The server-side mostly just takes place if you utilize the following: - Built-in API - Server-side Rendering
  - _fat_santa 5y ago

felizuno 5y ago

First and foremost I like hooks libraries and think there should be more of them. That said when looking at their examples this appears to require exactly the same code you would need anyways, but with the additional boilerplate required by the library. Is the goal to add intellisense for people who don't already know how to write accessible front ends? Is the goal to enable me to use a div as a button via hook instead of writing semantic HTML? Not trying to be rude but honestly not seeing the value add outside maybe the FocusScope's restoreFocus and there is no way that works 100% as expected in the wild. IMO the community is much better served by tools that help you identify accessibility gaps during the design phase, experience your application in other usage paradigms, or audit third party packages for accessibility before taking them as dependencies. If you work with designers who love hover triggered tooltips with forms with more tooltips inside them this library cannot fix the fact that you're making a terrible experience. If you want to npm install React-ported Kendo components because you "remember they worked well with jQuery" this library will not make them accessible. Turn voiceover on, turn your screen off, eat your own dog food. What's worse "accessibility helper libraries" like this often get used as an excuse to say "of course we made this accessible look at all the helpers in the code" but the team never actually audits to see what the experience is like (hint: your Lighthouse accessibility score does not indicate WCAG compliance), and surprise surprise they've incorrectly implemented the helpers in a way that actually degrades the experience. Then they pay my agency a lot of money to hurry up and do it the right way before the NFB lawsuit drops.

chungwu 5y ago
react-aria is about more than just putting the aria-attributes in the right place. It also takes care of interactivity, keyboard accessibility, focus management, and smoothing over some crazy differences between browsers. Sure, it's all code that you can write yourself, but it's complicated and subtle to get right, and it's how we end up with all these half broken components on the web. Here's a good example of deep thinking and investigative work that goes into react-aria: https://react-spectrum.adobe.com/blog/building-a-combobox.html https://react-spectrum.adobe.com/blog/building-a-combobox.ht...

chungwu 5y ago

react-aria is awesome. You structure your DOM and css however you want, and react-aria provides hooks that return props to spread onto your elements to make them come alive. These same hooks also give you visibility into and control of the component state, so you can also easily blend in your own custom logic for the component. It is about as flexible as a headless ui library can get. But it's also lower level and so harder to use than, say, radix primitives. I work on Plasmic (plasmic.app), a visual builder for React. With react-aria, we're able to let our users build, say, a Select component visually however they want, and then we just use the hooks to spread the right props to the right elements, and It Just Works. See https://youtu.be/mPHS2zg2a8Y https://youtu.be/mPHS2zg2a8Y Headless UI is an exciting space. There's only so far you can go with re-skinning material ui or antd, and no one should be building their own from scratch. These headless libraries give you all the interactivity and accessibility you need for your components, but still give you total freedom over how they look. It is the way!

wly_cdgr 5y ago

Man, this must be such tedious hell to test

devongovett 5y ago
Haha yes it is. We have to do a ton of manual testing to ensure consistency and compatibility across many devices, browsers, and screen readers. Some of my tweets showing how we do this: - https://twitter.com/devongovett/status/1318600389462126592 https://twitter.com/devongovett/status/1318600389462126592 - https://twitter.com/devongovett/status/1270410802395111424 https://twitter.com/devongovett/status/1270410802395111424 - https://twitter.com/devongovett/status/1318676759080968193 https://twitter.com/devongovett/status/1318676759080968193

steve76 5y ago

Every component now needs a ref. Isn't that a problem?

aarpmcgee 5y ago

I've been using react-aria on a personal project, as well as building a UI library at work based on TailwindCSS+React Aria. I generally really like the combination. The maintainers are super responsive+helpful on Github and really know how to engage constructively with criticism. I really appreciate what they're doing. The combination of TailwindCSS+React Aria provides one with a pretty great template/scaffolding for building out a fully featured component library. The only downside that I've found is that their typescript support can be a little weird in my experience, but their approach is nonetheless well considered imo. edit: https://github.com/adobe/react-spectrum/pull/1761#issuecomment-910841975 https://github.com/adobe/react-spectrum/pull/1761#issuecomme... is a decent summary of what I'm referring.