Material-ui: Why are Grid container & item the same component?

Created on 2 Sep 2017  路  5Comments  路  Source: mui-org/material-ui

As you all know, the grid component consists of two parts - one with the container prop which is the container for grid items with the item prop.
My question is, why?
It makes the code messier, it makes the docs harder to understand and to read the API methods, and the most important thing is that it's _combining two elements that are separate into one element_. That's like making Card's CardContent and CardAction into <Card actions>, <Card content> and <Card container>.
I don't see who benefits from Grid being one component with two different behaviours.

enhancement

Most helpful comment

This has always made me curious, but your explanation makes sense.

My experience so far tells me that the average use case doesn't mix container and item props. With that in mind, there could be an easy "best-of-both-worlds" approach. MUI could provide named components that just wrap Grid. Something like:

// src/Grid/Container.js
import React from 'react'
import Grid from './Grid'

export default function Container (props) {
  return (
    <Grid container {...props} />
  )
}

Thoughts? If you think it's a decent idea, I'd be happy to make the PR. The docs would need to be updated as well in order to add clarification. Maybe that would be a good time to add an example of a layout using both container and item.

All 5 comments

First thing, the Grid component entente to be a helper around the flexbox model of CSS. The slimmer the wrapper is, the better. An element in the spec can be a flex container and a flex item at the same time.
So it means that <Grid container item /> can potentially be valid.

Second and more importantly, the combination is an advanced and undocumented mode. We have been adding a visual regression stress test for it.
https://github.com/callemall/material-ui/blob/865b39bef48c3f85743c3914ba146b97b93fce0f/test/regressions/tests/Grid/StressGrid.js#L25-L27

I'm open to change it in the future if we don't see any people taking advantage of it. But as we are speaking, I still believe that the current tradeoff is good.

This has always made me curious, but your explanation makes sense.

My experience so far tells me that the average use case doesn't mix container and item props. With that in mind, there could be an easy "best-of-both-worlds" approach. MUI could provide named components that just wrap Grid. Something like:

// src/Grid/Container.js
import React from 'react'
import Grid from './Grid'

export default function Container (props) {
  return (
    <Grid container {...props} />
  )
}

Thoughts? If you think it's a decent idea, I'd be happy to make the PR. The docs would need to be updated as well in order to add clarification. Maybe that would be a good time to add an example of a layout using both container and item.

It makes the code messier

@stavlocker This is not something we can easily change. We need the stylesheet to have access to both container and item styles.

it makes the docs harder to understand and to read the API methods,

Possibly yes.

and the most important thing is that it's combining two elements that are separate into one element. That's like making Card's CardContent and CardAction into , and .
I don't see who benefits from Grid being one component with two different behaviours.

This concern should have been answered in https://github.com/mui-org/material-ui/issues/8013#issuecomment-326759971.

My experience so far tells me that the average use case doesn't mix container and item props.

@zachwolf Mine neither. It's definitely advanced.

Maybe that would be a good time to add an example of a layout using both container and item.

Yes, I agree!

MUI could provide named components that just wrap Grid. Something like:

This is not something I would personally use. I would rather do a single import. In +90% of the cases, you are going to use a container and an item at the same time.

Regarding going forward. I have added the waiting for users upvotes tag. I'm not sure people are looking for such abstraction. So please upvote this issue if you are. We will prioritize our effort based on the number of upvotes.

Thanks @oliviertassinari! Would it be appropriate to reopen this issue?

Was this page helpful?
0 / 5 - 0 ratings