[HN Gopher] React Aria: A headless UI component library
___________________________________________________________________
React Aria: A headless UI component library
Author : xyzzyrz
Score : 204 points
Date : 2021-11-05 07:52 UTC (15 hours ago)
(HTM) web link (react-spectrum.adobe.com)
(TXT) w3m dump (react-spectrum.adobe.com)
| Eduard wrote:
| Where is carousel?
| tannhaeuser wrote:
| 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.
| robertlagrant wrote:
| > headless CMSs quackery
|
| Headless CMSes are useful as well once you exit the realm of
| blogs and WYSIWYG website builders.
| krembanan wrote:
| 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
| alexaholic wrote:
| I was under the impression Adobe was investing heavily into Web
| Components. I gather that didn't work out well?
| bnjm wrote:
| 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/
| devongovett wrote:
| 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 wrote:
| 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%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
| eatonphil wrote:
| Companies of that size always have many disparate efforts going
| on.
| Existenceblinks wrote:
| Isn't it being used in the new browser based Photoshop?
| geniium wrote:
| Seeing that Adobe logo made me leave the site instantly.
| konradkpl wrote:
| 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-accessibili...).
| raxxorrax wrote:
| 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
|
| Don't know if that is still best practice, screen readers
| probably are way smarter today.
| namelosw wrote:
| 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.
| deltaci wrote:
| can someone explain in layman terms what is headless UI?
| zettadam wrote:
| '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.
| conorwade wrote:
| It give you the behaviours needed to implement a UI component,
| but it doesn't give you any styling.
| dsego wrote:
| I think you are supposed to do the rendering, it just gives you
| the behaviors.
|
| https://www.merrickchristensen.com/articles/headless-user-in...
| jokull wrote:
| "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
| spyke112 wrote:
| Why not just use default html elements?
| fnordsensei wrote:
| 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 wrote:
| 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.ht...
| ojkelly wrote:
| 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 wrote:
| 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.
| jorams wrote:
| I feel like a big problem here is that the Getting
| Started starts with a bunch of code that just... outputs
| a bare button. Starting with something like a combobox
| would show much more value.
| nsonha wrote:
| 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.
| andrewingram wrote:
| I mean, at some point _someone_ made up the term, but it 's
| been floating around for years to describe this exact
| concept.
| thirdvect0r wrote:
| HeadlessUI[1] has been around for over a year, it's not a
| term this author made up
|
| [1] https://headlessui.dev/
| tshaddox wrote:
| 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/co...
| naasking wrote:
| 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?
| _fat_santa wrote:
| Preact is a drop in replacement as long as you use the "compat"
| package. If you use a framework like Gatsby or NextJS, they
| both have a plugin that lets you drop in preact (positive that
| Gatsby has this, pretty sure that NextJS has the same)
| jonplackett wrote:
| 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 wrote:
| 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 wrote:
| 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.
| _fat_santa wrote:
| > 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.
|
| NextJS (and Gatsby) occupy this space between a static site
| and a site that is sever rendered. While the site itself is
| static, during the build process is when all the "server
| side" stuff happens.
| micahbule wrote:
| 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
| jonplackett wrote:
| don't be so fast to dismiss needing 'server side stuff'
|
| one pitfall of react that it fixed for me was escaping the
| single page gracefully.
|
| for example, if you want to have any other /pages that can
| be shared properly on facebook / get index on a search
| engine, then you NEED to render that on the server (can be
| statically generated with next.js so you still don't need a
| server)
|
| doing routing with pure react is a complete headache and
| mess of code, plus it will not get indexed properly / look
| right on a search engine.
|
| if you start with next.js, you lose none of the react
| functionality, add very little overhead, and can actually
| make a functioning website a lot more easily.
|
| like i said, i rejected it to begin with too - but it is
| super useful and super easy to use. don't make my mistakes
| all over again!
| skohan wrote:
| 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 wrote:
| Like this?
|
| https://github.com/tannerlinsley/react-table/
| dTal wrote:
| 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 wrote:
| 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 wrote:
| 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>
| rbobby wrote:
| Wait... electron isn't cross-platform?
| dTal wrote:
| In theory, but the developer still has to build it for
| each platform separately. Often they don't bother. It's
| not hard to find Windows-only Electron apps. This stands
| in contrast to webpages, which "just work" everywhere.
| beebeepka wrote:
| I was unable to create a Mac and Windows builds on Linux
| hist. Super annoying. Pretty sure it was just me, though.
| Can't imagine people have different build machines for
| each platform There has to be a better way
| chiefalchemist wrote:
| I'd say they're both important. Yes, you want consistency
| within the UX. Of course.
|
| But the users' expectations are set by their cumulative
| (read: across all apps) broader experience. If a high
| percentage of your users have a certain expectation for
| Interaction X and the app is not that (tho' consistent
| within the application) those users will likely be
| disappointed.
|
| Of course some components + UX are truly unique. Perhaps
| the crux of your killer app / killer feature.
| Unfortunately, this is not as often as most ppl think; thus
| too much time is wasted making unique those things which
| are better off frictionless and forgettable.
| wly_cdgr wrote:
| Man, this must be such tedious hell to test
| devongovett wrote:
| 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/1270410802395111424 -
| https://twitter.com/devongovett/status/1318676759080968193
| r0d wrote:
| 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 wrote:
| 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.
| felizuno wrote:
| 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 wrote:
| 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.ht...
| aarpmcgee wrote:
| 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#issuecomme...
| is a decent summary of what I'm referring.
| chungwu wrote:
| 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
|
| 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!
| ramboldio wrote:
| 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_ wrote:
| > Maybe CSS needs to become more capable tool to place divs
| more easily?
|
| What's the issue now then? Flexbox is straightforward enough.
| endisneigh wrote:
| 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?
| tshaddox wrote:
| 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.
| aitchnyu wrote:
| 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.
| gherkinnn wrote:
| 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 wrote:
| The hypothetical is explicitly that if it did look and behave
| the same as well as having the same elements.
| gherkinnn wrote:
| If browser vendors today can't even decide on uniform
| search boxes, that's a hypothetical too far away to
| entertain.
| deadcoder0904 wrote:
| Cool to see more competition to Headless UI [0] by the Tailwind
| guys
|
| [0]: https://headlessui.dev/
| zettadam wrote:
| In what way is Headless UI 'headless'?
| vereis wrote:
| 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 wrote:
| `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 wrote:
| It gives you complete control over your markup and
| styling. Headless UI is designed to handle everything
| except what the components look like.
| zettadam wrote:
| <Component as="some html tag"> is not full control :)
| armandososa wrote:
| Styleless would be a more apt name.
| nsonha wrote:
| This came before it I think, and even before that I know
| ReachUI and Reakit
| onion2k wrote:
| There's also https://www.radix-ui.com/ which is excellent.
| steve76 wrote:
| Every component now needs a ref. Isn't that a problem?
___________________________________________________________________
(page generated 2021-11-05 23:01 UTC)