[zero][system] Implementation of styled tag processor for linaria

[brijeshb42]

This PR introduces two main packages

1. zero-tag-processor - Package to contain all tag processors to be used by linaria for build time manipulation
2. zero-runtime - The actual runtime implementation of styled that ends up in the user bundle.

What's done in the implementation -

1. Processing css objects from styled calls, theme overrides, variants in styled call as well as theme object.
2. CSS Variables for runtime styling based on component props. See.

What's left to implement (only in context of styled call) -

• Optional processing of shorthands
• Replacing usage of palette.primary.main (theme tokens) inside the dynamic functions with equivalent css variables at build time.
• Restricting usage of theme object inside above functions
• Generating theme classes with all the theme tokens

Moving some of the todos to independent PRs for easy review -

• Copying over some of the logic from @mui/system to the package
• Typescript typings for styled
• Tagged template support. This version only support css objects.

There is also a test vite app to verify the changes in development. Note that this is not a workspace project yet as I need to figure out how to import items from ts file so that it can be used in vite.config.ts. So we need to manually run yarn install and then yarn dev to start the app.

• I have followed (at least) the PR section of the contributing guide.

[brijeshb42]

@mnajdova @oliviertassinari One point to note in the ZeroSlider file is that some of the dynamic styles were made possible by using css variables in the css object definitions. So I think we should have first party support for declaring css variables. Something similar to Stitches as demonstrated here - https://github.com/brijeshb42/vite-example-no-stitches/blob/main/src/components/Slider/Slider.tsx#L183-L201

[mnajdova]

We will need to review this order. For e.g. now, whatever is defined in the theme would override the styles defined in the component (including "variants" styles). What I mean by this is:

const theme = createTheme({
  components: {
    MuiButton: { 
      styleOverrides: { // or variants with props {}
        root: { 
           background: '#00FF00',
        }
      }
    }
  }
});

Will override the button's background regardless of what color is used. We can come back to this later tough, I am just mentioning it for awareness.

[mnajdova]

One more question, how do we make sure that the component that is wrapped has it's styles defined previously? In cases like:

styled(Slider)

[brijeshb42]

Even if you define variants in base css, they get added after styleOverrides css.

[brijeshb42]

One more question...

It's made sure by virtue of the bundler. If a component A is imported from A.ts like -

A.tsx

export const A = styled()...

and imported in B.tsx

import {} from './A';

const B = styled(A)(...)

CSS class ordering is in the order of the import. So first styled call in A gets processed and then in B

.class-A {}
.class-B {}

[mnajdova]

Even if you define variants in base css, they get added after styleOverrides css.

This makes sense to me, however is different than the current behavior, which may cause some issues. But again, let's revisit this later and focus on the other aspects.

[mui-bot]

Netlify deploy preview

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

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 8c9a938

[brijeshb42]

Added 3 new commits in the PR to

1. Replace usage of theme tokens in runtime functions with it's equivalent css variable.
2. Generate theme css with all the possible tokens.

[brijeshb42]

@mnajdova Moved over some of the TODOs to the package README as it would be better reviewable individually. So for now, this PR is feature complete.

[mnajdova]

two nits, implementation wise I think we can go with this for a first iteration. For me, the most important bit is to plan out the testing strategy for it.

[brijeshb42]

@mnajdova Builds are passing now. I'll merge once you approve.

[mnajdova]

Looks good for a first iteration. I would propose creating a page next for the lighthouse score performance test. For the next iteration, would be great to add next.js integration too.

[brijeshb42]

There's one more PR for sx prop support. After that I'll create two more packages. One for a vite plugin and other for nextjs.