Add abillity to prevent CssVarsProvider from using local storage

[zroug]

Summary 💡

The current implementation of CssVarsProvider requires the use of local storage to store the theme settings. My suggestion is to make the use of local storage optional. One idea is to add a mode property to CssVarsProvider, in addition to the existing defaultMode property. With this new property, the theme would be controlled solely by the property and would not be affected by local storage. Another suggestion is to delay writing to local storage until the theme is explicitly changed using the setter of the useColorScheme hook. That way, if the setter is not used, nothing would be written to local storage.

Examples 🌈

No response

Motivation 🔦

The current version of CssVarsProvider requires the use of local storage, even though it is unnecessary in certain situations. For example, if the theme is only controlled by the system theme, or if there is only one theme, there is no need to use local storage. Local storage adds unnecessary complexity due to statefulness. For example, it adds the need to check how divergent states in local storage and in code interact.

[kingpalethe]

Has anyone found a solution for this for usage in Joy? I need to change the color scheme programmatically for certain templates, and it would seem I would need to interact with the local storage and CSSVarsProvider in order to do this, in a complex way?

[tuckergordon]

I'm not sure if this belongs as a comment on this ticket or if it should be its own ticket, but using localstorage like this creates some developer headaches when developing apps with different themes.

Say I have an app foo and another app bar and each app has a different theme. I first open foo locally at localhost:8080. Later I switch to working on bar and I open it at localhost:8080 and it shows up with foo's theme.

This seems to require manually going in and clearing localstorage, so having an ability to disable that feature would be useful!

At minimum, I would suggest adding a note to the documentation instructing developers to clear localstorage if switching between sites with different themes.

[NotYoojun]

The same issue, I don't want MUI to save the modes into localStorage. Instead we have our own theme manager.

[acomanescu]

Maybe the ThemeProvider can expose a prop to set a StorageProvider that's an object/class instance that has getKey setKey where setMode can write into and read from. It's a really important feature if you need to have the same mode across multiple browsers/devices for the same user.

[ggascoigne]

I hate to jump on this with a me-too comment, but since there's been no obvious movement here I'd like to add my use case to the list.

We provide an internal library that use @mui, we expose our own provider that configures themes etc. and as part of that we manage themes in our own code. This include setting the preferred theme.

Having @mui explicitly try and do all of this for us just adds a list of features to work around, and honestly I've spent more times dealing with this than I have getting everything else related to css-variables working nicely.

I don't want this library to automatically persist state. I don't particularly want this library to sync themes across multiple tabs (by reading that variable), at least make this opt-in.

Can we please have an option to disable this behavior, it's such an intrusive change in behavior when compared to the previous interface.

[NotYoojun]

Is anybody caring about this? These items are really messing up my app. I don't want these crap to appear here.

[mnajdova]

Maybe the ThemeProvider can expose a prop to set a StorageProvider that's an object/class instance that has getKey setKey where setMode can write into and read from. It's a really important feature if you need to have the same mode across multiple browsers/devices for the same user.

This makes sense to me. cc @siriwatknp can you look into this please?

[siriwatknp]

Yes, I'm looking into it.