[RFC] Remove MUI

[lkostrowski]

After several discussion we have some reasons to remove MUI from Macaw.

I keep this issue open to evaluate:

1. How important it is for us (how much this dependency is blocking us)
2. How much time it will take to remove it
3. What can we use instead (headless libraries?)
4. What strategy can we use for migration

[Cloud11PL]

Macaw has only a few components that were customized to match our needs. The rest of components (inputs, cards etc.) that we use in eg. Dashboard, app-template are imported directly from MUI with just some styles applied (correct me if I'm wrong though). Removing MUI would require us to re-create all of the components that we use, animations, and a lot of the logic behind them eg. dialogs, formcontrol etc. Therefore it's not an easy task.

Headless libraries such as radix seems like a good option but they require quite a bit of boilerplate as they use compound components pattern. On top of that we would have to re-write all makeStyles styles to use stitches if applicable.

[lkostrowski]

Indeed it's not an easy task. We definitely need to consider many factors.

Maintaining a design system isn't easy, so I would try something light with not much dependencies. Headless UI's promise here seems to fit us. Also, Tailwind approach can be good to speed up development and allow some customizations. Headless UI will work it https://headlessui.com/

On one side, this isn't easy, but on the other, the longer we wait, the harder it will be.

The good part is that we don't aim to build extensible library for everyone (like MUI or Chakra), but to have consisten UI for our internal needs and for Dashboard apps.

Strategically we can consider v1 developed in parallel and slowly deprecation of v0.x

Let's wait for some comments from @saleor/frontend

[dominik-zeglen]

I planned to switch to Material UI Base to minimize required amount of work and just rewrite component styles (and markup probably). We can even keep JSS as styling engine to avoid rewriting 796 (xD) useStyles hooks.

[lkostrowski]

Another proposal, low-ui component foundation to be considered https://reach.tech/

[witoszekdev]

If I may add a few cents:

I think in macaw we should use a solution that outputs static CSS. This way you are free to chose whatever you need (for example in your Saleor App), we don't force you to use JSS. To achive this we could use vanilla-extract (or some other zero-runtime styling library). It uses simmilar style of writing styles like JSS, but it primarly uses CSS Variables for overrides and creating variants. It even has Recepies API for writing variants easily like in Stiches.

This would also allow us to do graduall rollout of Macaw 2.0 in Dashboard - because we could keep on using Material UI and dashboard-specific overrides for components directly imported from MUI and new components from Macaw. We would also avoid issues with having 2 CSS-in-JS libraries conflicting with each other.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[oliviertassinari]

It looks like https://github.com/saleor/macaw-ui/pull/280 was the first PR to adopt Radix UI.

Overall, I'm curious, doing marking research. What was the main incentive to?

1. Remove Material UI
2. Adopt Radix UI over Base UI (Material UI unstyled)

Thanks