V7 nested MantineProvider to force dark theme on partial UI

[naivefun]

In V6 we used nested MantineProvider to force partial of the UI to always be with dark mode. For example, the header will always remain dark no matter the app theme is dark or light. It is convenient because all components within the header will adapt automatically.

In V7 if I use force color scheme, it will overwrite app level color scheme, causing the whole app always to be dark.

Is there a way to force partial of the UI to always be dark without affecting the app theme?

[rtivital]

Use nested MantineProvider:

• Update css variables selector – https://mantine.dev/theming/mantine-provider/#cssvariablesselector
• Change root element – https://mantine.dev/theming/mantine-provider/#getrootelement
• Add custom color scheme manager that updates the attribute – https://mantine.dev/theming/mantine-provider/#colorschememanager

[Toshinaki]

Hi, many thanks for the v7. All updates look great.
I remember there're examples for nested providers to use didferent theme for part of the app in the previous version's doc.
Could you please add a similar example to the newest doc?

[Toshinaki]

@naivefun
Hi, did you find any solution to this?

@rtivital
if I understand it right, we need to:

<MantineProvider> // this will use `html` and default storage key
  <div>
    <MantineProvider 
      getRootElement={() = > document.getElementById("section1")} 
      cssVariablesSelector="#section1" 
      colorSchemeManager={localStorageColorSchemeManager({ key: 'section1-scheme' })}
    >
      <div id="section1"></div>
    </MantineProvider>
    <MantineProvider 
      getRootElement={() = > document.getElementById("section2")} 
      cssVariablesSelector="#section2" 
      colorSchemeManager={localStorageColorSchemeManager({ key: 'section2-scheme' })}
    >
      <div id="section2"></div>
    </MantineProvider>
  </div>
</MantineProvider>

Is this code right?

[alexbatis]

hi @rtivital - I used this nextjs app dir mantine template to generate a reproduction (code sandbox/github repo) to outline some issues I've been facing with nested Mantine theme providers. These examples build off of the example codeblock from @Toshinaki above.

note: this seemed like an appropriate place to report my findings, but let me know if i should add this as an issue on the mantine repo.

I'm looking forward to resolving these issues with you

issue 1

• dark theme inside of light theme works, light theme nested inside of dark theme does not (different behaviors between Card and Paper component)

issue.1.-.card.paper.mov

issue 2

• nested toggle color scheme not working first time after parent color scheme is changed

issue.2.mov

issue 3

• forceColorScheme not working for nested MantineProviders

issue 4

• custom color passed to nested mantine provider not working on first render, shows up after calling toggleColorTheme in the nested provider

issue.4.mov

issue 5 (perhaps not an issue, but misunderstanding)

• local storage seems to work when refreshing page, but useMantineColorScheme seems to return the wrong value

issue.5.-.local.storage.mov

[rtivital]

Thanks for the reproduction! It is planned to add documentation for nested MantineProviders in one of the next minor releases. I'll have a look at these bugs as well.

[kevinbeal]

If you use nested mantine providers with different scheme values, the @mixin light and @mixin dark styles both apply. Whichever (light or dark) is defined last wins.

[alexturpin]

The following seems to have worked for me:

<MantineProvider
  getRootElement={() => document.querySelector<HTMLElement>("#dark-area") ?? undefined}
  cssVariablesSelector="#dark-area"
  forceColorScheme="dark"
>
  {children}
</MantineProvider>

With the caveat that text elements were still getting their color from the body. Throwing this in my CSS modules did the trick:

:global {
  #aside {
    color: var(--mantine-color-text);
  }
}

[ihqtim]

Thanks! This is simple to apply & works well for me for most children of the nested provider. Two issues I see are that the background color of the TagsInput - in this case the top-most provider is dark theme, and this nested area is light theme:

Similarly Select components from the child (nested) provider have their dropdown coloring set by the top level provider (dark) rather than the nested provider (light):

[hunterwilhelm]

For me, this is all I had to do.

...

const ref = useRef<HTMLElement | null>(null);

return (
  <MantineProvider
    getRootElement={() => ref.current ?? undefined}
    forceColorScheme="dark"
  >
    <section
      ref={ref}

      ...

(I didn't need to change the text color, just a Segmented Control)

[kevinbeal]

The problem is the CSS, not the JS. The selectors are written like this [data-mantine-color-scheme=light] .m-8d3f4000.

If you have defined a new root within a parent root element, you don't change the CSS. The selectors are still written the same. They will simply have both [data-mantine-color-scheme=light] .m-8d3f4000 and [data-mantine-color-scheme=dark] .m-8d3f4000 targeted on the same element.

If it works in your case it is purely by accident that the inner (dark) one was defined after the outer (light) one for the element you are looking at. As soon as you pick another component where the order is different (light after dark) your solution won't work for that component/element.

The order is different for different components and there's no reason to think the order will stay stable over time. A solution has to be built into the library itself somehow to work reliably across all components.

[Adg1]

This is the complete solution if someone is still struggling,

import { MantineProvider } from '@mantine/core';
import { useId } from 'react';

const ColorSchemedChildren = ({
  children,
  colorScheme,
}: {
  children: React.ReactNode;
  colorScheme: 'light' | 'dark';
}) => {
  const id = useId().replace(/:/g, '');
  const selector = `#${id}`;
  return (
    <div id={id}>
      <MantineProvider
        getRootElement={() => document.querySelector<HTMLElement>(selector)!}
        cssVariablesSelector={selector}
        forceColorScheme={colorScheme}
      >
        {children}
      </MantineProvider>
    </div>
  );
};

export const DarkSchemedChildren = ({
  children,
}: {
  children: React.ReactNode;
}) => (
  <ColorSchemedChildren colorScheme="dark">{children}</ColorSchemedChildren>
);

export const LightSchemedChildren = ({
  children,
}: {
  children: React.ReactNode;
}) => (
  <ColorSchemedChildren colorScheme="light">{children}</ColorSchemedChildren>
);

The extra div wrapper may cause some side effect in styling

[kevinbeal]

I explain above why this is not a complete solution and will fail often, even within the context of the same component. The problem is the CSS, not the JS.

[Adg1]

I tried this solution for my use case and it worked well. You're probably right that the issue might occur with MantineProvider nested at multiple levels, due to how CSS gets loaded.
Until we find a proper fix, though, this solution seems like a good temporary approach, especially for cases with a single-level provider setup.
If you could share a reproducible example of the issue you encountered, it would be helpful. I think we might be able to address it with a custom component.

[blisst]

This worked great for me when other methods didn't.

I used this to force a color scheme in a particular area of the UI, which was already inside of another, root MantineProvider.

Some things I found:

1. darkHidden and lightHidden won't work in the nested area because of the reason @kevinbeal is bringing up, that say your root scheme is color scheme = light and the nested scheme = dark, "[data-mantine-color-scheme=light] .m-8d3f4000 { display: none }" and "[data-mantine-color-scheme=dark] .m-8d3f4000 { display: none } " are the CSS rules that get generated and both will match your element and therefore your element will never show.

However, you can pass the computed color scheme from the root provider to the nested provider components and use that to make changes based on the root color scheme
const computedColorScheme = useComputedColorScheme('light', { getInitialValueInEffect: true });

2. If you want to have a button inside of the nested provider that changes color scheme for the ROOT provider, you need to make the const { setColorScheme } = useMantineColorScheme(); from OUTSIDE the nested context available to your button in the nested context. If you use useMantineColorScheme in the nested provider, it will pull the nested color scheme rather than the root.

[Toshinaki]

I can see from the doc that there's a MantineThemeProvider that also accpets a theme object.
But the doc only shows the use case for defaultProps for a part of the app,
so I wondering if MantineThemeProvider can also be used for nested themes?

[Toshinaki]

Hi @rtivital
I just found a recent discord message: Is it possible to have a theme and a sub-themes?

And you answered, as I quote

Nested themes and MantineProviders are not currently supported

So this WAS possible but impossible now?
Any updates on this topic?

[DonnyVerduijn]

@rtivital what do you think about this idea, are you open to it?

[DonnyVerduijn]

We might even be able to support custom themes with this approach if we can generalize across anything that is not the current color scheme. Seems this is just a matter of setting all css variables to inherit.

[DonnyVerduijn]

a cleaner approach might be to use css layers, but i would have to figure that out.

[rtivital]

I've tried implementing that, it does not work. I'd rather not support this feature as it is not performant at all and generates a lot of (hundreds) CSS variables injected with js. To override styles for a subtree of components, use Styles API.

[DonnyVerduijn]

For my use case i revisited the problem and i can actually live without nested providers as multiple providers can still coexist in sibling trees. It might not be a solution to every case, but for things like storybook docs, it is.