Skip to content

allow multiple different color modes in addition to light|dark for themes #4471

Open
@michaelcozzolino

Description

Is your feature request related to a problem? Please describe.

right now the appearance has the following type:

appearance?: boolean | 'dark' | 'force-dark' | 'force-auto' | (Omit<UseDarkOptions, 'initialValue'> & {
        initialValue?: 'dark';
    });

the Omit<UseDarkOptions, 'initialValue'> allows to have only valueDark and valueLight, but it does not allow me to have other modes different than dark/light such as custom mode created by the developer giving further color customisation to the theme: light|dark|luxury|business and so on.

Describe the solution you'd like

i would like to have the possibility to use multiple modes in addition to dark/light. so that the appearance type becomes something like:

interface Appearance<T extends string> {
    appearance?: boolean | 'dark' | 'force-dark' | 'force-auto' | (Omit<UseColorModeOptions<T>, 'initialValue'> & {
        initialValue?: 'dark';
    });
}

where T is a union type of color modes like 'light'|'dark'|'luxury'|'business' that the developer will specify

Describe alternatives you've considered

No response

Additional context

if this is not possible please provide a solution in the case where:

  1. I override the theme switcher with a custom theme switcher created by me containing different modes
  2. I still have to keep the appearance to be not false in the config.ts else the switcher will disappear

my current workaround is to use the vitepress-theme-appearance as storageKey in my custom component

 type AvailableTheme = 'light' | 'dark' | 'gourmet';

const theme = useColorMode<AvailableTheme>({
    attribute:  'data-theme',
    storageKey: 'vitepress-theme-appearance',
    modes:      {
        // custom colors
        light:   'light',
        dark:    'dark',
        gourmet: 'gourmet',
    },
    initialValue: 'dark',
});

that would be fine if the component would not be a part of a vue components package i am building. yeah, i could still pass the storageKey as props and let the developer handle it if needed, but it might not be the best option.

Validations

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions