[docs] Fix useStorageState regressions

[Janpot]

Addresses #41096 (comment)

• Fix hydration mismatches in the theme toggle. The implementation didn't deal well with mode being defined during hydration, even though it had logic to stabilize values during hydration already. I'm just rendering an empty disabled button until it's mounted, as that seems to have been the intended behavior already. This is the simplest solution to avoid us from stabilizing every possible prop during mounting.
• Fix tooltip warning on disabled theme toggle button
• To address [system] Catch localStorage unavailability #34027 I propose we just fall back to the SSR implementation, which is a simple React.useState brought back the try/catch to handle all the ways localStorage can be disabled.

@siriwatknp Instead of switching them in the dom, I assume it could be possible to use css vars to toggle the visibility of these two icons. I can't seem to immediately find how to do this though. Opportunity to improve the docs?

Preview: https://deploy-preview-41223--material-ui.netlify.app/

[mui-bot]

Netlify deploy preview

https://deploy-preview-41223--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against e217b3d

[Janpot]

I noticed that many of these hooks define 'use client'. This seems a bit useless. I can understand that for our components we do this as a subset of the properties can be used to transfer data from server to client, but with these hooks I don't see any possible use. Perhaps we should mark these with import 'client-only' instead?

For our components we could consider exporting a separate 'use client' version that only defines the subset of the properties that are serializable. This could take away some of the confusion that happens when they are imported in server components.

[oliviertassinari]

I noticed that many of these hooks define 'use client'

@Janpot I think I get the point but do you have an example?

How I understand things work:

This could take away some of the confusion that happens when they are imported in server components.

Which confusion?

For our components we could consider exporting a separate 'use client' version that only defines the subset of the properties that are serializable

This makes me think of #42750. I believe we need a theme.js in the server bundle, and one in the client bundle (which runs serverside for the initial request).

[Janpot]

How I understand things work:

Yep, seems about right. So the question would be why is e.g. useOnMount.ts marked with 'use client'? You can't call it as a hook in server components. It might make more sense to mark it with import 'client-only', to have it fail at build time. Not super important, just a thought I had reading through this code.

Which confusion?

The file is marked as a server/client boundary ('use client'). The types of the components allow for assigning non-serializable values. e.g. they happily autocomplete and build but fail at runtime

'use server'
import { Box } from "@mui/material";

export default function Home() {
  return (
    // This fails at runtime
    <Box sx={{ background: (theme) => theme.palette.background.paper }}>
      Hello
    </Box>
  );
}

Perhaps it makes sense to make two versions of the components:

• one that defines only the serializable subset of the properties in its types and that defines 'use client' and that proxies its calls to the next one
• one that defines all properties and that adds import 'client-only'

That way either the build fails (you imported something that has import 'client-only' on the server). Or the types don't suggest you can put a function there.

Just some shower thoughts though. Nothing ground-breaking, I just tend to treat types as documentation, and it would be helpful if they prevent me from writing invalid code. Haven't found any comment of the React core team on how libraries should deal with this in the ideal scenario.

[oliviertassinari]

Moved this to wrap the maximum possible scope.

[Janpot]

Is this operating on the same key as useLocalStorageState? Can't it just use the hook instead? I don't think the storage value should be manipulated by anything else, it will definitely lead to bugs.

[oliviertassinari]

Is this operating on the same key as useLocalStorageState?

It does, but the TODO comments I have left in the code are to move to a point where the mode is to be handled by useCurrentColorScheme and not useLocalStorageState.

[Janpot]

The way I envisioned this was

// have these hooks available in the docs
function usePaletteModeUserPreference() {
  const [mode, setMode] = useLocalStorageState('colorScheme', 'system');
  return { mode, setMode };
}

function useCurrentPaletteMode() {
  const { mode: userMode } = usePaletteModeUserPreference();
  const systemColor = useSystemColor();
  return userMode === 'system' ? systemColor : userMode;
}


// for theme provider
const paletteMode = useCurrentPaletteMode()
const theme = paletteMode === 'dark' ? darkTheme : lightTheme;

// anywhere for theme switchers
const { mode, setMode } = usePaletteModeUserPreference();
<Button active={mode === 'dark'} onClick={() => setMode('light')}>dark</Button>
<Button active={mode === 'light'} onClick={() => setMode('dark')}>light</Button>

The nice thing about useLocalStorage is that it acts as global state, so you don't ever need to add a shared state variable somewhere and create a context for it. Just the hook works anywhere you use it, it handles state outside of React. This system worked very well for the Toolpad app theme switcher. I might be oversimplifying for the docs, I'd have to look deeper into it, there may be blockers to adopt the same way of doing a theme switcher in the core docs

[oliviertassinari]

@Janpot Yes but what I see is that the mode is a lot more integrated with MUI System once you use CSS Variables and Zero runtime than it was with Emotion (what Toolpad uses).

MUI System almost needs to completely own that logic. If it's possible to separate things then I'm 💯 for it. I had this feeling that hard to understand how things work because of how closely things are linked together but I don't really see how to simplify things. We have effectively built https://github.com/pacocoursey/next-themes.
cc @siriwatknp.

[oliviertassinari]

I'm never clear on what's the return value of functions, makes it clear.

[oliviertassinari]

We would render twice, unnecessary.

[oliviertassinari]

Sorted to match the dependencies, it makes it easier to find missing value.

[oliviertassinari]

For consistency in the codebase, makes it easy to see components to other stuff.

[oliviertassinari]

Convention

[oliviertassinari]

Avoid redundant renders

[oliviertassinari]

This explains why code is gone.

[oliviertassinari]

Either we use different modeStorageKey and attribute keys between Material UI and Material UI Next or we remove this.