Add sensible defaults for v1.0

[jordyvandomselaar]

I'm using version 1.0 right now, and one thing that I find annoying is that there's so much config/styles to be added before it looks alright. This make rapid development a lot less rapid. Imho it would make sense to have defaults that make sense.

For example; https://material-ui.com/demos/drawers/ The drawer needs all this CSS:

const drawerWidth = 240;

const styles = theme => ({
  root: {
    width: '100%',
    height: 430,
    marginTop: theme.spacing.unit * 3,
    zIndex: 1,
    overflow: 'hidden',
  },
  appFrame: {
    position: 'relative',
    display: 'flex',
    width: '100%',
    height: '100%',
  },
  appBar: {
    position: 'absolute',
    transition: theme.transitions.create(['margin', 'width'], {
      easing: theme.transitions.easing.sharp,
      duration: theme.transitions.duration.leavingScreen,
    }),
  },
  appBarShift: {
    width: `calc(100% - ${drawerWidth}px)`,
    transition: theme.transitions.create(['margin', 'width'], {
      easing: theme.transitions.easing.easeOut,
      duration: theme.transitions.duration.enteringScreen,
    }),
  },
  'appBarShift-left': {
    marginLeft: drawerWidth,
  },
  'appBarShift-right': {
    marginRight: drawerWidth,
  },
  menuButton: {
    marginLeft: 12,
    marginRight: 20,
  },
  hide: {
    display: 'none',
  },
  drawerPaper: {
    position: 'relative',
    height: '100%',
    width: drawerWidth,
  },
  drawerHeader: {
    display: 'flex',
    alignItems: 'center',
    justifyContent: 'flex-end',
    padding: '0 8px',
    ...theme.mixins.toolbar,
  },
  content: {
    width: '100%',
    flexGrow: 1,
    backgroundColor: theme.palette.background.default,
    padding: theme.spacing.unit * 3,
    transition: theme.transitions.create('margin', {
      easing: theme.transitions.easing.sharp,
      duration: theme.transitions.duration.leavingScreen,
    }),
    height: 'calc(100% - 56px)',
    marginTop: 56,
    [theme.breakpoints.up('sm')]: {
      height: 'calc(100% - 64px)',
      marginTop: 64,
    },
  },
  'content-left': {
    marginLeft: -drawerWidth,
  },
  'content-right': {
    marginRight: -drawerWidth,
  },
  contentShift: {
    transition: theme.transitions.create('margin', {
      easing: theme.transitions.easing.easeOut,
      duration: theme.transitions.duration.enteringScreen,
    }),
  },
  'contentShift-left': {
    marginLeft: 0,
  },
  'contentShift-right': {
    marginRight: 0,
  },
});

To look how you'd expect it to. I think this should be a default as it makes my code messy, fast, not to mention that it's a timekiller having to do this every time.

[oliviertassinari]

@jordyvandomselaar We haven't been looking into higher abstracted component yet. I think that we should wait 6 months or so before looking into it. Right now, people can build such abstractions in userland. But I'm 💯 with you on this. We can do better, we need to do better.

[leMaik]

I'd also like to see some wrappers for common layouts and usages of components. 👍
Customizing everything as it can be done right now shouldn't be affected, though.

[jordyvandomselaar]

I couldn't agree with you more @leMaik .

[HriBB]

We can start working on some unofficial components. I have a bunch of them that I use across a few projects, and I was thinking about putting them in something like material-ux private repo. Most of them are really simple, comfort now I'm simply copy pasting ux folder from project to project.

[mbrookes]

@HriBB packages/material-ui-lab is our proving ground for experimental components if that was appropriate.

[rosskevin]

I'm thinking this might not be a lab thing, but one or more other projects under mui-org.

For example, I just spent a lot of time for example creating ContactAvatarEdit, which behaves similarly to what you would see from Google contacts (plus gravatar integration), select file, crop, etc. I'm not sure something like this is too prescriptive to not be a community component, but I am sure it is too high level to be considered in material-ui proper.

At the same time, I think project startup overhead could be problematic for sharing, so a monorepo for @material-ui/meta components could useful. Then again, the issues area could get really noisy because in that kind of project, we would be venturing much farther towards opinionated components that are less driven by the spec.

I'm +1 for sharing higher level components, just not sure about the best approach.

[oliviertassinari]

I'm closing for #14519.