[experimentalStyled] Make sx style fn optional

[mnajdova]

This PR adds an option for making the sx prop optional as part of the experimentalStyled utility. This could unblock developers to customize the behavior of the resolver for the sx prop, depending on their needs. A simple example of how it could be used can be found here - https://codesandbox.io/s/confident-bush-346hb?file=/src/App.js (the value for the m prop is always the negative value of the resolved one).

Discussion around this issue can be found here - #23496

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 978eb34

[oliviertassinari]

@mnajdova Interesting approach. Thoughts:

1. I think that the option to disable the sx prop is interesting for design teams that want to minimize entropy. It's not unusual to have developers that want to enforce high constraints on the exposed API. I'm not sure, however, that it's common enough yet to support it, considering a workaround is to wrap. Maybe it would even work better with an option in the theme.
2. Instead of disabling the sx prop, what would be wrong if a developer uses a different name for the prop?
3. In [system] transform and themeKey do not work together when using style from material-ui/system  #23496, the root of the issue for the author seems to be a missing spacing feature. Something developer can find alternatives in: tailwindcss, or all the Stack components. I start to wonder if we even need a Stack component if a spacingX and spacingY value in the system wouldn't be enough.
4. In [system] transform and themeKey do not work together when using style from material-ui/system  #23496, the problem I was wondering about is the notion of a custom superset of CSS you can use. It might be overkill to have it in the theme as done in https://stitches.dev/docs/utils, considering we didn't yet see a developer that had this use case.

[oliviertassinari]

I might understand why the curried API on styled-system, css() method, maybe it's so they don't need to spread the props, I wonder if it helps with performance:

Suggested change

	return styleFunctionSx({ ...props, theme });
	return styleFunctionSx(props)(theme);

[mnajdova]

Let me test this separately, wouldn't like to break something else somewhere :)))

[mnajdova]

But looks like it really may help

[mnajdova]

I think that the option to disable the sx prop is interesting for design teams that want to minimize entropy. It's not unusual to have developers that want to enforce high constraints on the exposed API. I'm not sure, however, that it's common enough yet to support it, considering a workaround is to wrap. Maybe it would even work better with an option in the theme.

Instead of disabling the sx prop, what would be wrong if a developer uses a different name for the prop?

The biggest problem and the reason why I decided to add this option is the following - experimentalStyled appends the function for the sx prop last (it will always win), so even if you have custom styles under experimentalStyled like:

const CustomBox = experimentalStyled('div')(customSxFunction);

our default styleFunctionSx would still win as it runs last. I am trying to make an alternative for this. Using different prop sounds good, but still, I think it would be beneficial if we support this...

In #23496, the root of the issue for the author seems to be a missing spacing feature. Something developer can find alternatives in: tailwindcss, or all the Stack components. I start to wonder if we even need a Stack component if a spacingX and spacingY value in the system wouldn't be enough.

Maybe adding a gapX & gapY would solve the issue. However, I think it's better if we have Stack component dedicated to this, just to preserve the simplicity of the sx prop that we want to use everywhere. Not all components need this behavior, so I would be careful will adding new features, to be honest...

In #23496, the problem I was wondering about is the notion of a custom superset of CSS you can use. It might be overkill to have it in the theme as done in https://stitches.dev/docs/utils, considering we didn't yet see a developer that had this use case.

At this moment I wouldn't go that far. Adding custom props and handling of existing ones is pretty easy anyway as demonstrated on the codesandbox - https://codesandbox.io/s/confident-bush-346hb?file=/src/App.js I would stay away from introducing new API until we really see a value in it, otherwise, we will again introduce new abstractions that developers will need to learn...