add more variations for a spectrum button web component in our component that extends the spectrum button

[Ashish-Dobhal]

We are trying to create a button web component extending the spectrum button. However we want 1 more button variant apart from the one provided by the api ie

export declare type Button Variants = 'accent' | 'primary' | 'secondary' | 'negative' | Button Statics | DeprecatedButtonVariants;

One easy way could be add another attribute for that type but we want to use the original api as is as far as possible.
Could anyone suggest the best way to achieve this functionality.
Thanks in advance

[Westbrook]

Monkey patching that types would be pretty involved, I'm not sure it would be worth it. Doing this is JS would be relatively straight forward, but that's not likely a good idea for something that is broadly used. In specific, variant holds a lot of logic while we continue to support deprecated variant, so beyond the basics of extending a type (which doesn't align to how class extension is meant to work), you'd need to reference back to the super or slice off functionality to achieve this. Again, I'm not sure it would be worth it.

One path that's not "supported" and could run into issues across future releases would be to realize that Button itself has very little code: https://github.com/adobe/spectrum-web-components/blob/main/packages/button/src/Button.ts and to take over the final steps of the element definition yourself, e.g. extend a new Button not from Button but from ButtonBase.

In the end, all of the possibilities here take you out of expected consumption of the code that is surfaced. and will likely run afoul of supported APIs at some unannounced point in the future, so again, I'd say it wasn't worth the effort.

[Ashish-Dobhal]

thanks @Westbrook for the prompt reply. Really appreciate it.
We are actually monkey patching at the moment and it works fine but not super happy with that approach.
this["spectrumBtnPrivateVar"] works but it dodgesthe typescrips valuable typing systemthus we want to avoid it.
Thanks for also explaining the reasoning the way it is currently built. The last option makes a lot of sense from our perspective. Although i do get the downside of branching out to far from the source repo.