Should `color` prop type definitions allow arbitrary string values?

[ohmree]

With the following sass that generates a new button variant:

// src/app.scss
// include this however you like.
@import 'bootstrap';

$twitch-purple: #9146ff;
.btn-twitch {
  @include button-variant($twitch-purple, $twitch-purple);
}

I can do <Button color="twitch" /> and get the expected behavior (a purple button) - except typescript complains about 'twitch' not being a valid value for this prop. Should components that accept color/variant props allow arbitrary strings for cases like this? There are other ways to make the button look the way I want it to in this case but I think they're both inferior:

• <Button class="btn-twitch" /> - compiles to an element with both btn-secondary and btn-twitch, which looks like I want it to in practice but I feel like might interfere with some tools that do tree-shaking (plus the unnecessary class just bothers me).
• Manually styling the element - tedious and error-prone, you'd either be duplicating the button-variant mixin or have an inconsistently styled element (e.g. if you style just the background and text colors, you might end up with the default border color from .btn-secondary).

[bestguy]

Hi @ohmree , Yes I think we should support | string here: https://github.com/bestguy/sveltestrap/blob/master/src/shared.d.ts#L8 since Bootstrap allows this type of customization.

Thanks for the heads up, we can PR this week.

[demetrius-mp]

@bestguy actually it would be necessary to change the color on the Button.d.ts file as well. I think it would be better if the ButtonColor type kinda "extended" the Color type available in shared.d.ts, as it only adds another color (which is "link").

[demetrius-mp]

@bestguy also, i just tried adding | string to the type definition and it completely loses intellisense, and at the end of day, it will treat the type as a simple string, not literals

[ohmree]

i just tried adding | string to the type definition and it completely loses intellisense, and at the end of day, it will treat the type as a simple string, not literals

I've noticed that too, I think it's just due to how typescript works.

What I typically end up doing is using my editor's go-to-definition functionality to check what the type looks like.
It's not ideal but it works.

EDIT: I asked on the typescript discord and was told that the workaround for this is something along the lines of 'variant1' | 'variant2' | string & {}, but the person who suggested this said they try to avoid this pattern when possible.

[demetrius-mp]

EDIT: I asked on the typescript discord and was told that the workaround for this is something along the lines of 'variant1' | 'variant2' | string & {}.

just tested this and it works just as expected. still providing intellisense for the literal strings, but allowing to enter other values.

but the person who suggested this said they try to avoid this pattern when possible.

sure, this syntax definetly looks weird, but i guess there is no other way to handle this without sacrificing intellisense

[ohmree]

Another alternative that was suggested is 'variant1' | 'variant2' | { custom: string }. I'm not sure which one is preferable here but I think I'm leaning more towards the former version (| string & {}), just because it looks nicer.