[RtlProvider] Add component & hook

[mnajdova]

Fixes #41217

The idea is to add separate context for rtl, outside of the ThemeProvider as the notion of ThemeProvider won't exist in the zero-runtime. The implementation is done in such a way that it is non-breaking when using emotion.

[mui-bot]

Netlify deploy preview

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

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 3fafd73

[siriwatknp]

I think we need to scope this PR down to just zero runtime first. How zero runtime is going to support Rtl and then move up to integrate with Material UI.

So I think the first PR would be exposing APIs from zero-runtime, the RtlProvider and the generated styles.

Then the next PR would be integration with Material UI which could likely be the same as createUseThemeProps exported from ../zero-styled.

The structure could look like this:

The change should be on Material UI, not System:

// mui-material/src/zero-styled/index.ts
import useTheme from '../styles/useTheme';

export function useRtl() {
  const theme = useTheme();
  return theme.direction === 'rtl';
}

…

// mui-material/src/Drawer/Drawer;
…
import { useRtl } from '../zero-styled';

const rtl = useRtl();

[mnajdova]

For useThemeProps, I understand the reasoning for having this double API and switching, as we are getting a benefit for not using context in Material UI, but for rtl, I don't understand why we would complicate that much if we can use common API? I mean it's just context added in the ThemeProvider, it's not necessary to complicate it if we don't gain anything using it.

For supporting rtl in zero-runtime, we can create docs page showing how it can be done, I suppose we would still use the styling plugin cc @brijeshb42 to confirm. This PR just makes sure that in the component's logic we need to have a way to check if the component should be rendered in rtl mode, as the logic depends on it.

[brijeshb42]

@siriwatknp I don't think we can implement useRtl as a processor in zero-runtime similar to what you did with useThemeProps since theme will only have tokens and direction value will come at runtime. Even if theme had theme.direction in the bundler config, that'd still only generate css for that specific value and there won't be a way to change that.

[siriwatknp]

@siriwatknp I don't think we can implement useRtl as a processor in zero-runtime similar to what you did with useThemeProps since theme will only have tokens and direction value will come at runtime. Even if theme had theme.direction in the bundler config, that'd still only generate css for that specific value and there won't be a way to change that.

It's not my intention to have rtl in Pigment theme. Pigment still expose the hook and context to get rtl for behavioral logic. Using hook and context from the System works but just a reminder that we are creating dependency between Pigment and System along the way with this approach.

One more thing, I don't see how Pigment handles style interpolation for RTL in this PR. Is it the next step? I think it should be in this PR.

[mnajdova]

It's not my intention to have rtl in Pigment theme. Pigment still expose the hook and context to get rtl for behavioral logic. Using hook and context from the System works but just a reminder that we are creating dependency between Pigment and System along the way with this approach.

From what I saw pigment already has a dependency on the system, this is why I decided to add the context there. We can likely long term create some utils package that both system and pigment can depend on.

One more thing, I don't see how Pigment handles style interpolation for RTL in this PR. Is it the next step? I think it should be in this PR.

As I mentioned this will be solved later, we have to revise with Brijesh how we want to tackle this. This is for runtime rendering & different styles based on the state, it's not about transforming the styles.

[siriwatknp]

👍

[oliviertassinari]

as the notion of ThemeProvider won't exist in the zero-runtime

I connected the dot with #43443. It feels like we should remove the RtlProvider component and approach the solution differently.