[Feat]: Allow consumers to define custom variants when extending components

[loredanaspataru]

Code of conduct

• I agree to follow this project's code of conduct.

Impacted component(s)

sp-button, sp-toast, sp-badge

Description of the requested feature

For some components, our application's design system introduces new variants that are not defined in Spectrum. It would be nice to define these new variants and use the same API to extend SWC's button, for example, adding the needed styles for our system. Right now, if I try to introduce a new variant it won't be accepted as valid, and one of two things will happen:

• the variant attribute is removed completely (sp-toast)
• the variant is reset to a default value (sp-button)

Mockups or screenshots

No response

Implementation notes or ideas

Right now, the check for valid variants is done inside the variant setter. One possible solution could be to move the check outside the setter in a protected method that can be overwritten in a class extension. This would be a minimal change that should not impact current users.

If we want to also maintain type safety for these new values we could leverage TS generics and allow variant to be of type ButtonVariants or the provided type T.

[Westbrook]

@loredanaspataru as we work towards an API that works for everyone here, can you help us confirm the actual level of flexibility we'd be looking for in a pattern like this? For instance, I'll look at Toast, because it's the least complex:

Toast currently accepts the following variants: 'negative' | 'positive' | 'info' | 'error' | 'warning' | ''. With error and warning technically being deprecated. Will this expansion look to support a 7th+ variant, e.g. 'new' | 'negative' | 'positive' | 'info' | 'error' | 'warning' | '' or is it looking to make an alteration across all of the variants? Or maybe both style of changes?

Badge has a similar level of complexity.

Button customizes on a number of axis already, so variants, statics, and treatments intersect for the expansion your designs are discussing will be great to see.

Together this will help clarify paths forward for this sort of change.

While we're looking at this, there are a number of other patterns that support variants. We'll need to look at the intersection of this API across elements anyways, but if there is current need to address sp-asset, sp-action-bar, sp-alert-dialog, sp-clear-button, sp-close-button, sp-card, sp-help-text, sp-link, sp-meter, sp-slider, sp-split-button, or sp-tooltip as part of this, the earlier we can know the better we can support that.

[loredanaspataru]

@Westbrook Thanks for your input. This would need to support only adding new variants. From what I've seen so far we don't need to make changes to existing variants, and for small tweaks the --mod API has been enough.

For Button in particular there was only the need for the premium variant which I understand may be part of a larger effort to align across design, not something just Express-specific.

Our current needs are just for the sp-button, sp-toast and sp-badge but this may change in the future. So, if we decide on an API to support these new variants we may want to use that in other components as well in the future.