Option to use SX prop syntax for classes when used with MUI?

[kpervin]

I was playing around with a way to use the sx prop syntax with makeStyles (namely being able to use shorthands and breakpoint objects) with the following code for MUI:

import { CSSObject } from "@emotion/react";
import { insertStyles } from "@emotion/utils";
import { SxProps, Theme, useTheme } from "@mui/material/styles";
import { css, unstable_styleFunctionSx as styleFunctionSx } from "@mui/system";
import { useMemo } from "react";
import { clientSideEmotionCache } from "../pages/_app";

const cache = clientSideEmotionCache();
cache.compat = true;

export function makeStyles<Key extends string>(
  generateStyles:
    | ((theme: Theme) => Record<Key, SxProps<Theme>>)
    | Record<Key, SxProps<Theme>>,
) {
  return () => {
    const theme = useTheme();
    const classes = useMemo(() => {
      const styles =
        typeof generateStyles === "function"
          ? generateStyles(theme)
          : generateStyles;
      return Object.keys(styles).reduce((s, _key) => {
        const key = _key as Key;
        const sxStyles = styleFunctionSx({ sx: styles[key], theme });
        const serialized = css(sxStyles as CSSObject);
        s[key] = `${cache.key}-${serialized.name}`;
        insertStyles(cache, serialized, false);
        return s;
      }, {} as Record<Key, string>);
    }, [theme]);

    return { classes };
  };
}

It seems to work, though it needs some optimization for better generated class names per component, and I'm unsure about how well it would work with SSR.

That being said, as it is possible, is there any chance we might be able to work this into a plug-in of some sort that allows sx syntax in makeStyles when defining it from tss-react through providing the appropriate function from whatever library tss-react is being used with?

[garronej]

@kpervin Yes,
I am interested.
I think it's a good idea.
Thank you for submitting your implementation.

What I think of would look like this:

import { useTheme } from "@mui/material/styles";
import { unstable_styleFunctionSx as styleFunctionSx } from "@mui/system";
import { createMakeAndWithStyles } from "tss-react";

export const { makeStyles: makeSxStyles } = createMakeAndWithStyles({
    useTheme,
    "customObjectToCssObject": ({ customObject: sx, theme }) => styleFunctionSx({ sx, theme })
});

We could also make makeSxStyles ans withSxStyles directly accessible like import { makeSxStyles } from "tss-react/mui".

What do you think? I'm pretty hyped.

[kpervin]

We could also make makeSxStyles ans withSxStyles directly accessible like import { makeSxStyles } from "tss-react/mui"

While I like that idea, that would mean that anyone not using MUI would have to wait until a package was released for their specific UI library, for example Theme-UI. It may make more sense to allow for a more modular approach.

Another thing we would need to ensure is classname generation so that the class can be selected via sx syntax, such as with "& .MuiSlider-thumb". To that effect, makeStyles should take a prefix name field of some sort to define it (if that's not already a feature).

[garronej]

Of course,
We would have the modular approach exported in the index (allowing the code I demonstrated in the snippet) and pre-export good default for MUI from "tss-react/mui", like, it's possible to do directly import { makeStyles } from "tss-react/mui" because I have already injected MUI's useTheme.
Anyway. We are on the same page.

Another thing we would need to ensure is classname generation so that the class can be selected via sx syntax, such as with "&
.MuiSlider-thumb". To that effect, makeStyles should > take a prefix name field of some sort to define it (if that's not already a feature).

Looks more complex that what I had in mind... you you think the customObjectToCssObject function parameter could accomodate this?

Ok now I am sorry but I am in the rush. I might not answer for a few days but any suggestion, additional informations, or even PR that you would submit in the meantime would be much appreciated.

Best regards,

[garronej]

Hi @kpervin,

It's implemented! 🥳
I just published a beta, It would be great if you could test it: yarn add tss-react@3.7.0-beta.0.

There is now a plugin system in tss-react.
One application of this plugin system is to support the sx syntax.

With this you can do things like this:

import { makeSxStyles } from "tss-react/mui";

function TestSxComponent() {

    const { classes } = useSxStyles();

    return (
        <div className={classes.root}>
            Should look like: https://mui.com/material-ui/react-box/#the-sx-prop
        </div>
    );

};

const useSxStyles = makeSxStyles()({
    "root": {
        "width": 300,
        "height": 300,
        "backgroundColor": 'primary.dark',
        '&:hover': {
            "backgroundColor": 'primary.main',
            "opacity": [0.9, 0.8, 0.7]
        }
    }
});

And it ends up looking like this:

Screen.Recording.2022-05-13.at.02.44.27.mov

@mnajdova @oliviertassinari, I tag you along, I would love to have your feedback on this new feature.

Best regards

[kpervin]

Oh wow! That's great! I will definitely try it out.

[kpervin]

@garronej just a quick question: that name prop is to set the generated class names, yes? I have yet to play with this.

[garronej]

Yes,
It's useful for debugging with the developer tool.
It's also useful if you publish a library, for example like https://github.com/gregnb/mui-datatables.
It enables users to overrides the styles of your component when creating the theme:
https://github.com/gregnb/mui-datatables/blob/b8d2eee6af4589d254b40918e5d7e70b1ee4baca/README.md?plain=1#L379-L387

You can pass { name: "TestSxComponent" } or { name: { TestSxComponent }}, it's the same thing but I prefer the latter syntax as it ensures that the name of the stylesheet and the name of the component stays consistent.

Best,

[mnajdova]

We had some requests in MUI for using the sx syntax in the styled() util too, and we decided to go with this approach - https://mui.com/system/styled/#how-can-i-use-the-sx-syntax-with-the-styled-utility It doesn't add any overhead on the existing APIs, and looked like the simplest solution to the problem :)

[garronej]

That's interesting, thank you for the feedback.
Maybe the added complexity, and increase of API surface is not worth it after all...
@kpervin, what do you think of the solution offered by @mnajdova?

[kpervin]

It makes sense, and it was how I originally got the idea. My thought was on making it cleaner, as you need to add the sx function to each class that you create in the above example.

[garronej]

So you think the beta is worth merging?

[kpervin]

I've yet to validate it personally, but if you're interested in the approach I don't see why it isn't worth pursuing.