[joy-ui] Remove nonsensical component variants

[zanivan]

Context

Global Variants is a Joy UI feature, that aims to use global tokens to bring consistency among the components.

With this, all components would not only have the same set of variants but also pull styles from the same source file.

From the DX standpoint, it was also supposed to add predictability, meaning that you can always try, for example, variant="soft" in whatever component, and it would work.

For some components, like (obviously) the Button, it works perfectly. There’s almost a semantic usage implied to it (i.e. solid for primary action, soft for secondary, and then, outlined or plain for tertiary actions).

Problem

Not every component needs all four variants (plain, outlined, soft, solid) mostly because there’s probably no real-world scenario where they’d be used

Proposal

Remove nonsensical variants

For now, we’ll keep the global declaration of how each variant looks like but just, sort of, “turn off” the ones that don’t make sense for a certain component. For example, removing the solid and plain variants from the Linear Progress.
This will also help with:

• Considerably smaller change for current users, as far as updates go.
• Ensures there are no obvious visual regressions.

---

Supporting links

• Brainstorm at Figjam
• Joy UI Global Variants
• Thoughts on Joy UI Global Variants

---

Variants to be removed

• Autocomplete:
• Solid
• Input:
• Solid
• Radio:
• Solid
• Select:
• Solid
• Slider:
• Plain
• Outlined
• Switch:
• Plain
• TextArea:
• Solid
• List:
• Soft
• Outlined
• Solid
• Table:
• Soft
• Outlined
• Solid
• Typography:
• Soft
• Outlined
• Solid
• Circular progress:
• Plain
• Outlined
• Solid
• Linear progress:
• Plain
• Outlined
• Solid

[zanivan]

• Link: Still needed POC to see if there is another way to use HTML to highlight texts instead of using a global variant
• Tabs: I reckon the current variants doesn't make much sense since the only change is to the tab. Would it make more sense if it follows the Figma design?

[Westo48]

If global variants are removed does that mean that we wouldn't be able to use them in the future?

For example, if I wanted to use circular progression with the plain variant, then I wouldn't be able to use that since it would have been removed?

Edit since looking at the Figma brainstorming link:
It seems as though from the few that have used the Figma link there is a general consensus on a couple of items (solid radio and plain switch for instance), but then others there are some that think it is useless and others that think it is useful (plain circular progress and solid card for instance).

This brings me to my question. How is it decided which ones are useless and should be removed and which are useful and should stay?

Other than a few choice component variants, I could see where someone would want to use it somewhere, but if they get removed then they can't. In my opinion it just seems like the cons heavily outweigh the pros in removing global variants from components.

That is IF I am understanding this correctly, if I am clearly not understanding then I apologize.

[zanivan]

Hey @Westo48 thanks for the comment!

I believe you got it right. However, the Figma file is not 100% accurate—we just used it to discuss and converge on which variants should be removed. The actual variants that are intended to be removed are the ones in the issue's description.

This brings me to my question. How is it decided which ones are useless and should be removed and which are useful and should stay?

We discussed with the team and mostly based our decision on component usage and applicability.

For the Input based components, we choose to remove the solid variants, in a more opinionated design choice. For Radio, Slider, and Switch we decided to remove the variants that don't add/change much—basically, they existed just to have all four variants—or because it didn't make sense, like the plain switch without a track, for example.

When it comes down to the List, Table and Typography, the idea is to have only the plain variant, and later evolve these components offering more tools to customize—also because it will almost always be used in a parent component that has the variants available. The Table for instance, could have better ways to customize rows, cells and so on; and, for the Typography we could have a prop to be the highlight on text, instead of using a variant for it.

We decided on removing the plain and solid variants from Circular and Linear progress because it doesn't give enough feedback. The plain variant doesn't have a track, so it's hard to provide a progress feedback whilst you're unable to see the progress at all. For solid, I believe the biggest problem is because it seems to exist just for the sake of having a solid variant—it could make more sense if the colors were inverted: the track with plain white and the progress bar with the primary blue → what would make it look very similar to the soft variant falling into the same reason of Radio, Slider, and Switch variants.

cc.: @siriwatknp @danilo-leal

[Westo48]

@zanivan I appreciate the response! For context, I have been using Material UI and was planning on moving to Joy UI. When doing research into Joy UI I came across this issue and found that some of the component variants I was planning on using are going to be removed, so I figured I would get some more information. So I appreciate the information ❤️!

In your answer you mentioned this is partially for a more opinionated design choice, but on the Joy UI "Getting Started" page it states it "lightly opinionated". Is Joy UI moving to being more opinionated direction in the future?

Just to confirm in an effort to plan ahead, only the component variants listed in the issue's "Variants to be removed" section are being removed?

[zanivan]

Great to know you're keen to give it a try!

In your answer you mentioned this is partially for a more opinionated design choice, but on the Joy UI "Getting Started" page it states it "lightly opinionated". Is Joy UI moving to being more opinionated direction in the future?

Actually no, we want to keep it less opinionated as possible :)

Just to confirm in an effort to plan ahead, only the component variants listed in the issue's "Variants to be removed" section are being removed?

We intend to remove only those. However, it's not set in stone yet, so we can keep some of them if we understand it's useful for the community. About that, would you mind telling which variants were you planning to use that are on the list—and why you've picked them?

[Westo48]

Absolutely! Joy UI, from what I have seen so far, is very pretty and has MUI's ease of use (being more of a backend developer I appreciate frontend ease of use 😆).

Actually no, we want to keep it less opinionated as possible :)

I understand I am just one guy so I certainly cannot speak for the masses, but that is helpful to know!

would you mind telling which variants were you planning to use that are on the list—and why you've picked them?

Sure!! As I mentioned, I am just one guy, so I don't expect the Joy UI dev team to keep things around just for me. Having said that, the main two from the list I was planning on using were the plain circular/linear processing and soft/solid list.

The plain circular/linear processing is for an alternate loading symbol where skeleton didn't quite apply (using that as a spinner essentially) rather than an actual loader, but the plain over soft was simply a more minimalistic design choice in my opinion.

The soft/solid list was actually wasn't for the list itself, but rather some of the sub-components variants (didn't know if list variants applied to the sub components). For example, if I am showing a list with 2 categories (kinda like in the examples) it would be helpful to be able to style the ListSubHeader one way (solid) and the ListItemButtons a different way (soft). Another use case would have been navbar ListItemButtons being styled in a similar way (logout button especially being styled a different way is handy, can't tell you the number of times I have accidentally clicked my own logout button lol)

I am sure these have workaround designs and what not, but since I haven't used Joy UI I can't exactly test those out.

---

It may not seem like a big deal for just two components, but I, and I believe many of us, have seen packages and dependencies remove things and then continue to remove things that breaks everything in your app. So I was doing a bit of due diligence while researching. I don't get that feeling here at all, just got a bit jumpy when I saw the "Remove" in the title haha. Less about the components themselves, and more about the reliability side of things.

[mwskwong]

Some comments on the proposed remove variants.

1. Typography (soft and solid): there are use cases for blogs to show inline code.
   

2. Link (outline): similar to above
   

3. Linear progress (plain): can be useful for nprogress

[mnajdova]

Few thoughts:

• Table - should support outlined variant, for e.g. the Notion tables use this variant.
• List - I would keep all variants as the component can be used in many different places or in combination with many other components.
• Circular progress - I would keep all variants, none of them seems off to me, except maybe the solid one :), for e.g. plain - https://learn.microsoft.com/en-us/fluent-ui/web-components/components/progress-ring?pivots=typescript
• Linear progress - same as for the circular progress ☝️

[zanivan]

As I see, we have many use cases for some variants we plan to remove.

Plain Linear and Circular progress seem to make sense and do have real applications, what makes me wonder that instead of ditching them off, we could refine the visuals of the solid variant and keep them all—maybe, this applies for Radio as well.

I noticed that we have use cases for Typography and Link variants everywhere, so we might keep them until we come up with something better, mostly for highlighting chunks of text.

The idea from @mnajdova regarding the List and Table is understandable. However, I do believe that they will mostly be under a Sheet, Card, Stack or Box, so I don't think we really need the variants for the main component. I am keen on the inclusion of variants in children such as rows, columns, and headers (and the same applies for the List).

Plain Slider, and Switch perhaps, are the only ones that I really don't see any usage. However, I wonder if the tradeoff of removing only these—and solid from input-based components— still makes sense.

The main concern is that we'd be sacrificing the predictability of "every Joy UI component having all four variants", in order to eliminate just these few.

What are your thoughts @danilo-leal @siriwatknp?

[danilo-leal]

I gotta say I'm still attracted by another option we considered, where we make custom adjustments to the variants' design for each component instead of pursuing this route. If it's doable, it might be worth prototyping something to evaluate the technicalities of it... Otherwise, I think that remaining in this direction of "removing non-sensical variants" also makes sense, even though sometimes it might be only one for a given component.

[mnajdova]

Otherwise, I think that remaining in this direction of "removing non-sensical variants" also makes sense, even though sometimes it might be only one for a given component.

Btw, if we have only one variant for a component, we should drop the variant prop altogether :)

[danilo-leal]

For sure, yeah! I was referring more to the scenario where we remove just one (as opposed to staying with one only), though, which is where we could question whether it's worth it... but, if it prevents the component design from being seemingly wrong (or buggy), I'd think it is!

[siriwatknp]

Btw, if we have only one variant for a component, we should drop the variant prop altogether :)

I thought about that as well, but it will lose the ability to let developers extend the variant 🤔. If we remove the variant prop, it could introduce the same problem as Material UI.

[zanivan]

We've been brainstorming ways to improve the global variants, and one option we tossed around was axing the nonsensical ones. But, after some chats and feedback, we realized it wouldn't be worth the hassle for developers.

So, we're aiming to a different approach: tweaking only some variants on a case-by-case basis.

That said, we're closing this issue and opening a new one (#39363) specifically for locally tweaking these components' variants.