Add classname for DefaultTheme

[silveltman]

I would like to have a classname for specifically setting the default theme.

Why? Because this allows for nested themes. For example: a section that ahs a coloured themes, but that has a card in it which should use the colors of the default theme.

[RyanClementsHax]

I'd prefer to keep the default theme "special" in that it applies to the :root selector. To achieve this, my recommendation is to create another theme and don't use the default theme. Will that work for you?

[silveltman]

Yes, that will work. I can manually add it to the body.

[silveltman]

@RyanClementsHax I'm running into issues on this topic when using Histoire.dev

It doesn not allow me to set any classes on the body, therefore no theme is used. Or I have to manually add the theme to every story..

[RyanClementsHax]

Hmmm. This seems like a limitation of Histoire itself. Is your issue with Histoire specifically that it allows the default theme to be applied, but you can't set the class to enable other themes?

[yuriyward]

Hi @RyanClementsHax,I'm encountering a similar problem. I have the default theme and three additional ones. We have a specific area where we want to maintain consistent colors across all themes. I tried to avoid using the defaultTheme, but this doesn't work for us as the theme is set up dynamically based on backend responses. As a workaround, I created a theme that contain the same colors as default one, which works, but isn't the most convenient solution. What are your thoughts on this?

[yuriyward]

@RyanClementsHax thank you for reply :)

Current Scenario:

1. Our application supports multiple themes, not just the traditional dark and light modes. We have more than 5 themes available.
2. Every user has a configuration that specifies their selected theme.
3. When a user visits the website, the frontend has to wait for the backend to provide information about the user's chosen theme.
4. There are specific UI elements that are not customizable and should display in the default theme.

Current Workaround:

To address this issue, we've implemented a workaround. We created a "default" theme with the same configuration settings as one of the other themes. This allows us to apply the default theme to those specific, non-customizable UI elements.

Concern:

While the current workaround functions as expected, I feel that there might be a more efficient or elegant solution available.

const defaultThemeStyles = { [...] };
themer({
  defaultTheme: {
    extend: defaultThemeStyles ,
  },
  themes: [
    {
      name: 'dafault-theme',
      extend: defaultThemeStyles ,
    },
    [...]

[RyanClementsHax]

Oh for your use case, you want to force the default theme in certain areas of your app even if some other theme is active in that subtree of the dom. Is that right?

[yuriyward]

Yes, that's correct.

[RyanClementsHax]

Thanks for that. I'm currently considering options to help you out. It seems the closest thing would be to always treat your default-theme as just another theme. That way you can get all of the enabling selector features to turn on the theme where needed. You're already doing most of this but you'd just need to ditch the defaultTheme and apply the default-theme in all cases you want that to show.

From a maintainers perspective, I could add an option on defaultTheme but I'd just be allowing another place to specify a theme that goes in the themes array.

When forcing a nested theme I imagine you're running into css specificity problems. Is that correct?

If you could make a toy app of your specific use case that would help me think through a solution for you.

[RyanClementsHax]

So I wrote an e2e test to explore this behavior and it seems that this is already what the plugin does

tailwindcss-themer/e2e/tests/multipleThemes.spec.ts

Line 122 in ae1db1a

test('themes can be overwritten by themes enabled higher in the tree by using class names regardless of theme declaration order', async ({

Could you go more into what problem you are experiencing? An example repo would be helpful.