Radix UI

[agnlez]

Discussion started by @mbarrenechea

Radix UI provides many components out of the box we need in our daily work. It would replace many of our components, like Avatar, Select, RadioGroup, Modal... Meaning less maintenance on our side for these components.

I think it is also a good chance to really scaffold the project at design-level: it would provide a way to really quick way to kick off building pages without touching basic components (further than colors/size settings) and standardize the behavior: we can compromise to develop something really quick following Radix standards, out of that, it would require additional efforts and so more hours/days on our end.

Thoughts? Concerns?

About Radix UI

[mbarrenechea]

The key of this ui library is simple, it's a ui library.

The thing I really like from this library reminds me a lot the libraries I like the most: Tailwind, react query and visx. They implement low-primitives, that means that is fully customizable. It's true that we will need to maintain some of the components we are using right now, like the map or the legend (not sure about it). But apart from these, I don't see the necessity of dealing with Accordions, Selects, Checkbox, etc...

Other really cool stuff is that we can work with them using tailwind, they are accesible, server side rendering.

The only downside I see now is that they don't support multiselect yet. For that we can use Listbox from HeadlessUI for the moment.

Figma UI kit
https://ui.shadcn.com/figma

Here you have some interesting links about why we should move to radix ui:

• https://github.com/shadcn/ui (Bunch of components made with tailwind)
• https://www.youtube.com/watch?v=p8CsotWUas0 (Animations with framer motion)
• https://www.radix-ui.com/docs/primitives/overview/accessibility (this one is for @clementprdhomme )

[davidsingal]

I agree to replace our UI components with a UI framework maintained by the community. They will be better, accessible, and after checking the library is even better than HeadlessUI. Anyway, we should let know the designers.

[clementprdhomme]

The components look good to me. I think a few of them will save us a good amount of work.

Most seem to be correctly accessible. I found a few issues with my screen reader, Orca, which may not be a reference but I'll write them down anyway:

• The checkbox' label is not read on the shadcn/ui example but it is on the Radix UI one
• The select and textarea examples don't have labels. This is not a problem of the components themselves but I'd expect them to provide accessible examples.
• The input's “With Text” example is not fully accessible either, again not because of the component itself. An aria-describedby attribute is missing to link the input to the description.
• The dialog and alert components use an h2 title for some reason instead of an h1

[agnlez]

After some discussion, we all agree on moving forward on using RadixUI as our main library whenever possible and reducing the amount of code (and dependencies) to maintain on our side. Therefore, an issue will be created according to this to clean the replaceable components with RadixUI ones and point to use them whenever possible.

@clementprdhomme I understand your accessibility concerns but I think they are still probably more accessible than ours right now, so, despite the points you mention above (hopefully they will be fixed in future updates), let's proceed and see how it develops.