[Box] Atomic CSS classes

[Elfayer]

My question is based on the often used classes for Spacing for Margin and Padding such as:

• m-0: margin: 0;
• pb-1: padding-bottom: 0.25rem;

Is there anything similar in MUI? I've seen the System (alpha), is this the way to go?
What is the right way to handle Spacing in MUI v3?

I've noticed that most (all?) examples are based on useStyles. But it seems like it is creating new classes each time it is used. If I am right, I wouldn't think of it as a good go, as it'll make the project's CSS scale up over time while adding more style, as opposed to atomic CSS approach (as in TailwindCSS).

Any suggestion for managing Spacing(Margin & Padding) in MUI?

[oliviertassinari]

My question is based on the often used classes for Spacing for Margin and Padding such as:

@Elfayer It's an excellent question. The current answer in v4 is to use the Box component: https://next.material-ui.com/utils/box/. Did you know about this existence? I have written a blog post about it.

Any suggestion for managing Spacing(Margin & Padding) in MUI?

We have a second helper when writing custom CSS: https://next.material-ui.com/customization/themes/#spacing.

---

Does it help? Do you still prefer the global class name approach? We could consider generating them 🤔.

[Elfayer]

I've seen the Box component, but since it's in alpha, I was expecting another approach to manage spacing in v3. So I guess I'll go for the Box approach. 😉

Material-UI makes me think of Vue's most popular library: Vuetify. It looks very similar to MUI, being material design and also the most popular in its own stack. They made the choice to use atomic classes instead though.

If I understand correctly, in MUI, the styles objects (from @material-ui/styles), are going to generate classes at runtime only?
If yes, wouldn't it bring a performance impact as opposed to build time/atomic CSS classes approach?
(I read your blog post, I am wondering why this tradeoff decision runtime vs network&cache)
Wouldn't it prevent browser caching and also have to be re-evaluated each time in that case?

I also wonder if the Box syntax approach might not be a bit verbose. It's going to add 2 lines in the templating each time we need styling, and adds an extra wrapping element on the output (default to div, which is why there is the clone attribute, if I understand correctly? Pass Box props to the child?), which is gonna be used very often. Or it is going to replace almost all tags in the templating using the component attribute.

Maybe I'm misunderstanding the whole thing. I like to learn new approaches and will definitely dig more into it. Thanks for the first feedbacks! 😃

[oliviertassinari]

@Elfayer I'm chatting from time to time with John from Vuetify. I closely follow what he's doing. I try to bring the good stuff in Material-UI. The main advantage of the Box approach is that the values are dynamic and can be accessed from the theme.

<Box p={[1, 2]} color="success.main" />

If yes, wouldn't it bring a performance impact as opposed to build time/atomic CSS classes approach?

You are right, it's slower than using pre-generated CSS values. If people start to notice slowness in their application, we should be able to work on them. I wouldn't worry too much about it. One of the possible approaches is to generate atomic class names, e.g. https://github.com/segmentio/ui-box.
It has the advantage of not generating a lot of CSS your browser has to load.

I also wonder if the Box syntax approach might not be a bit verbose.

The clone prop removes the extra element. In the future, I would like to make the core Material-UI components based on the Box. Meaning, this would work:

<Button m={1} />

What's the most important dimension for you?

[oliviertassinari]

I had a similar thought recently. The more I think of the atomic CSS approach for the Box component, the more I like it.

[oliviertassinari]

An exploration we have done in this direction: mnajdova#3 with @mnajdova.

[oliviertassinari]

Closing for #21657. It's a performance concern.