Introduce a Spacing component

MUI currently has a theme.mixins.gutters({}) that apply responsive gutters (16px on small screens, 24px on large) to the left and right sides of an element.

Occasionally you want to apply these same gutters to the top and bottom of an element. For example, one typical place this would be applied is the scrollable body of a page – so that stuff inside aren’t up against the top if you’re not using a subheader and so that there is an expected amount of padding at the end of the scroll.

• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior

Right now you can only mixin left/right gutters.

Because the breakpoints are created dynamically and passed to createMixins but mixins is just an object that gets merged in, it’s not possible to easily create your own custom gutters mixin.

So the only way of adding vertical gutters at the moment is to copy the code used by the gutters mixin and manually apply the same pattern of padding and the same media query but to paddingTop/paddingBottom. Which works, but it’s not great to have to write this manually. The styling is more verbose than it should be and you are writing code in your application assuming the code inside MUI will always work the same.

Expected Behavior

One option would be to just create a verticalGutters to apply gutters to paddingTop/paddingBottom. However sometimes you only want to apply padding to one of them (e.g. If you have a contents you want a bottom gutter for, but the top of your scroll view uses a heading that already comes with it) and if you override that gutter using paddingBottom: 0 in styles it won’t actually work because the breakpoint sub-styles will still have the padding.

For this reason, and having additional flexibility I suggesting changing the gutters signature (in a backward compatible way) to allow the gutter edges to be specified.

The edges arg/option is a string | Array<string> that contains one or more of the following keys: top, bottom, left, right, vertical (equivalent to ['top', 'bottom']), and ‘horizontal’ (equivalent to ['left', 'right']), and all (equivalent to [‘vertical’, ‘horizontal’]). The default is horizontal which matches the existing and most common behaviour of gutters({}).

The proposed new method signature is:

theme.mixins.gutters([edges], [styles])

Both arguments are optional, i.e. if the first argument is not edges (typeof edges !== 'string' && !Array.isArray(edges)) then it is styles.

This allows for the following usage:

{root: theme.mixins.gutters({width: '100%'})}
{root: theme.mixins.gutters('vertical', {width: '100%'})}
{root: theme.mixins.gutters('bottom', {width: '100%'})}
{root: theme.mixins.gutters(['horizontal', 'bottom'], {width: '100%'})}
{root: {
   ...theme.mixins.gutters('vertical'),
   ...theme.mixins.gutters('bottom'),
   width: '100%',
}}

I’m not sure if it’s worth it, but I do have an alternative extra signature:

theme.mixins.gutters(styles)
theme.mixins.gutters(edges, styles)
theme.mixins.gutters(styles, options)

Options would be an object and accept an edges key for the edges. The reason for having options is because there may be a reason to allow specifying that the gutters should be made using margin* instead of padding*. However I find having the options last after a mandatory styles unhelpful, and we can’t make it first or make styles optional because they are both objects. If margins as gutters are at all useful it would probably be better to add a separate marginGutters mixin.

[iamyojimbo]

Any movement on this?

[oliviertassinari]

@dantman I’m glad you have opened this issue. I do think that Material-UI could be exposing some generic spacing helpers. Instead of modifying the mixins key of the theme. I think that we could be focusing on extending the spacing key. I find the spacing helpers exposed by Bootstrap interesting. We could provide two levels of API for this problem. It would be the same approach to what we do with the typography. We have both a Typography component and a typography theme key.

• A theme level API: theme.spacing.
• A React component API: Spacing.

What do you think of going into this direction? Of course, we gonna have to refine the API first, find something with a great DX/implementation tradeoff.