Material-ui: Responsive Material-UI

[mbrookes]

Google have published guidelines for Responsive UI in MD: https://www.google.com/design/spec/layout/responsive-ui.html#

As responsive design is a Roadmap item, this issue is to intended log the intent, and capture feedback.

A common question on gitter is whether MUI includes a grid system, or, failing that, what grid system to use.

In addition to making individual components more responsive, this is an opportunity to provide the grid system that complements the core Material-UI components.

[alitaheri]

I don't think we should do layout too. It's against unix philosophy. There are already many awesome grid systems out there. The specs are for applications not libraries.

Frankly I believe we shouldn't have all the components either! It would be great if we didn't have Table, GridList and SvgIcon in this repository, let along a layout system. That's my opinion, absolutely open to discussion :sweat_smile:

The more code we add to this library the harder it gets for us and other contributors to keep consistency and a lot harder to change core stuff. We might wanna consider breaking this repo down if we wish to support more components.

[aweary]

I think it depends on the goal of the library. If the overall goal is to be a reference implementation to the Material Design spec in React (Similar to how angular-material is the reference implementation in Angular) than I think it should implement the spec in full.

On the other hand, if MUI is just a collection of Material Design components than it doesn't really matter and you can pick and choose what components you want. With this approach you get more control and allow more selectiveness, but you lose the status of :tada: reference implementation :tada:. On a personal note, I think having a full reference implementation within the React community is a good thing.

@alitaheri I think that either way, breaking down the repo into isolated components would be great. Being able to just install FlattButton or Dialog would be a huge benefit, but I know discussions in the past have mentioned the difficulty of isolating components due to shared implementation details.

[alitaheri]

@Aweary I agree with you :+1: Then it boils down to what the goal of this library actually is.

but I know discussions in the past have mentioned the difficulty of isolating components due to shared implementation details.

True :sweat_smile: we should investigate this in more details.

[chrismcv]

I've just had a read of the spec, and come away with the impression that it's a series of guidelines for ways to make an application responsive, rather than a spec for responsive components.

I think our purpose should be something like "to be a toolkit for building Material design compliant applications", and as such there are maybe some building blocks that we should include to make doing some of the responsive pieces more straightforward, but there is nothing that _needs_ implemented here directly to my mind.

@alitaheri - I agree that table, grid-list, and icons should be separate (and thought that when some of them were added... e.g. https://github.com/zippyui/react-datagrid is much better that <Table /> - a material-ui/table project would seem logical to me!)

[aweary]

Its a spec in the sense that it defines specific values (breakpoints, grid row count, gutters/margins, etc.) that you would implement to be compliant. You can see how angular-material does it: https://material.angularjs.org/latest/layout/container

[nathanmarks]

@alitaheri I could argue that the responsive layout is a core part of the MD philosophy.

Develop a single underlying system that allows for a unified experience across platforms and device sizes. Mobile precepts are fundamental, but touch, voice, mouse, and keyboard are all first-class input methods.

https://www.google.com/design/spec/material-design/introduction.html#introduction-goals

[alitaheri]

Yes it's debatable, but my concerns aren't related to whether we should implement these or not. It's simply that we cannot maintain everything ourselves, there are so many components here already. Angular has a big team, we aren't that big. I'm only saying we should break it down to smaller projects, whether it's under material-ui or not. by doing that we can have specific maintainers, not general ones who know so little about some components and so much about others.

[nathanmarks]

@alitaheri

I agree. Maintaining the grid system in addition is huge. Great point mate.

I think that breaking the grid/layout system into a separate project, or finding an existing one that we can integrate with seamlessly is the best route :+1:

I actually have been playing with a test layout system (not responsive yet), but I decided to wait on working on that project until I see where this one goes with regards to styling. I am still very torn on the best way to do styles with react libraries, especially with a layout system that needs to place nice with different setups :worried:

[julianmartinezmansell]

@mbrookes @oliviertassinari Would it be possible to make quick fixes, like make that Appbar to have mobile height, and few little things which are easy to implement, without having to implement a whole new grid system.
There will soon be a sky rocketing number of web apps thanks to new progressive web-app technology. I think it makes a lot of sense to make Material-UI compatible on Mobile Web. We are using it for our new web app but the Appbar doesn't look great at unless its 56.

[oliviertassinari]

@julianmartinezmansell For a quick fix, you can do the following:

import getMuiTheme from 'material-ui/styles/getMuiTheme'; // (new v0.15.0 import path)
import MuiThemeProvider from 'material-ui/styles/MuiThemeProvider';

const muiTheme = getMuiTheme({
  appBar: {
    height: 56, // Instead of 64
  },
});

...

<MuiThemeProvider muiTheme={muiTheme}>

...

And few little things which are easy to implement, without having to implement a whole new grid system.

True, but we need to think and solve the problem globally.

[rosskevin]

While a grid system would be nice, I recommend against it in this project.

it may be just as easy to support a recommended grid system. Grids are difficult to maintain, and I wouldn't want that noise in this issue tracker. A separate grid-specific project is doable, but making material-ui responsive doesn't mean taking on the whole responsibility. As long as it can be responsive with the addition of other projects (with a reasonable developer experience), I think it should stay out of this project.

With that said (and the reason I read this issue) is to try and understand the "recommended way" for this project. For example, is a css reset recommended? Which one? or is it not necessary (and why)? Grid system? Which one?

I think a sample repo/starter might be really useful. The docs app could certainly be this, but as I read them I haven't bumped into a grid or a reset.

I guess this is all to say, it would be nice to see a prescribed best way of doing things in one of the getting started docs (or sample repo), albeit noting that the developer is free to implement any way they would like.

[rosskevin]

FYI - while looking at the styling issues/options (one of those being JSS), I bumped into perdido is a grid system for JSS ported from LostGrid. JSS + CSSX + perdido may be a really good combination.

[nathanmarks]

@rosskevin I wish CSSX had syntax highlighting and autocomplete/snippet support in my editor!!

[rosskevin]

@nathanmarks - agreed, I need to see if I can get JetBrains to ignore CSSX (at least), it is trying to reformat it (incorrectly) and I'm addicted to just typing + reformat all the time.

Also there is an eslint issue. @krasimir is going to look at it soon, and see if he can get a solution. As a nice to have he might get some css linting as well.

[nathanmarks]

@rosskevin I love the look of it, but I feel like you have to sacrifice even more in the way of development tools than you already do with object literals. It would be fantastic to have syntax highlighting and css linting!

[krasimir]

Hey guys,

just so you know that there is eslint-plugin-cssx that transforms the CSSX expressions to an empty object literal. So, at least we can make js linting tools happy. If you need same logic in another context feel free to use this code.

[oliviertassinari]

@krasimir Thanks for sharing this project. That could be useful.
The tooling, is definitely one aspect of CSS in JS that will need to improve if we want this approach to success.

[kripod]

I think that this should be flagged as a milestone towards v1.

[lancecarlson]

This is a huge problem the should be fixed right away. When scanning the documentation, it took me quite awhile to figure out that this library didn't include a responsive component by default and then finally to stumble across this discussion about the topic. The fact that the Google Material UI spec talks about Responsive UI specifically and Materialize CSS implements components and has an entire page dedicated to mobile makes it clear that this is an important topic. That being said, the immediate resolution to this problem is not a difficult one to start. I propose putting a blurb somewhere in the documentation to highlight either this discussion or general philosophy behind this library. Saying something like "We don't have a grid system because it doesn't necessarily play nice with inline CSS and would bloat the library. Please see alternatives like flexboxcss." Would be extremely helpful for the community trying to implement their first components. Please don't wait on v1 to update the documentation. Thanks! :)

[lesreaper]

After looking through this, I'm trying to stay positive here, however, I think I have to transition back to Bootstrap.

I don't understand how you can implement a component system without taking into account responsive design in 2016. I can't seem to find how to modify my Toolbar like bootstrap does at breakpoints (Turning my menu items into a dropdown icon as you go smaller, etc). Sure, I can add Flexbox, but neither the documentation or help areas tell me how to interact with Material UI components in any meaningful way to make them responsive with a CSS grid system.

If I'm missing something, please feel free to correct me. However, without this basic implementation, or explanations/samples in the documentation, I don't see how Material UI could be used in a production app.

[nathanmarks]

@lesreaper There is a refactor of the library currently under development that has better support for responsive applications.

However, I have a question regarding the specific example you used (turning menu items into a dropdown icon). What technique are you referring to specifically?

[lesreaper]

@nathanmarks I'm referring to the moving of UL's into a dropdown icon list. Also uses some data toggles. Here are 2 examples below from Bootstrap. The top is a wide desktop, over 992px, and the other is a mobile under 480px. I'm skipping the inbetweens for clarity's sake.

I don't understand how any of this could be possible with just adding Flexbox and using the current Material UI components. Am I wrong? Is there a temp fix until the team is done re-working the rebuild?

[oliviertassinari]

I don't understand how any of this could be possible with just adding Flexbox

@lesreaper The material design equivalent to the bootstrap example you showed seems to be the <Drawer /> docked / open behavior depending on the screen width.

I agree, that's definitely not something you can achieve with a simple browser layout engine, like flexbox or media queries. You need to interact at the React properties level of abstraction.

Material-UI provides simple components that you can compose to get whatever behavior you need. I think that we have an implementation example of what you are looking for https://github.com/callemall/material-ui/blob/master/docs/src/app/components/Master.js#L194.
Material-UI doesn't provide any layout abstraction yet.
We are focusing on the core components, we have still quite a lot to do in this area.

[bobmonteverde]

Depending on the extent, making material-ui's components responsive is likely a very large project. What would be a nice start, would be to make it possible/easy to define responsive styles to material-ui's components. A step beyond that would be to allow you to define component params for 2 states, one for desktop one for cell phone (I know truly responsive designs have more than the 2 break points, but having the 2 would go a long way).

Some examples....

The stepper being horizontal on desktop, vertical on mobile (A smaller change, would be to shorten the labels on smaller devices).

Pretty much the same thing would be nice on the Tabs and Menu.

Of course this stuff could be done manually (in my case I'm using redux) and could be passing the screen width to the components that need to be responsive. But this is obviously far from ideal when the usual solution for this is a purely CSS solution. The styles that are defined in the JS on the components would be a good place, I'm just not aware of any way to define responsive styles here.

[rlmckenney]

As I am experimenting with integrating MUI components into a new project, I think it would be really helpful to make sure that we play nicely with Radium. That would allow a good deal of flexibility on a per component basis for example supporting @media directives in the style object.

This would allow us to make individual components more responsive independently of integrating a grid.

[vizath]

In our product, we created our own components that manages responsiveness of layouts and of other components. The responsive components bind themselves to the onResponsiveChange of the ResponsiveStore. So when the screen size changes, an event is fired, the component rerenders with the new breakpoint and screen info.

It makes it easy to define a xs/sm/md/lg grid. Media queries becomes simple ifs
Here is a minimal example: https://gist.github.com/vizath/605d5e1dc8eece005aa9cf6a8407ea2e

<Drawer open={Response.isAtLeast(Responsive.LAPTOP) || this.state.opened} />
<Stepper orientation={Response.isAtMost(Responsive.TABLET) ? 'vertical' : 'horizontal'} />

const ResponsiveStepper = ({ orientation, ...others }) => {
  if (orientation === 'responsive') {
    orientation = Response.isAtMost(Responsive.TABLET) ? 'vertical' : 'horizontal';
  }
  return (<Stepper orientation={orientation} {...others} />);
};

etc.

[rlmckenney]

Thanks @vizath for the example. It pointed me in the right direction and I just found the redux-responsive project. From a quick reading of the docs, it appears to work similarly to your custom components.

The approach is simple and performant. Since we will be using Redux, I think we will try this solution.

[hoschi]

@rlmckenney thanks for sharing, I'm starting the implementation of my own redux-responsive 7 minutes ago and just stopped :D

[rosskevin]

As an FYI to those watching, I have implemented flexboxgrid.com on material-ui#next as a set of self contained react/jss components that is tightly integrated with material-ui#next theme's responsive breakpoints. I don't have time to create and maintain another OSS project, but if someone wants to, I'm happy to contribute this working code and sample. NOTE: this only works on the next branch and is not applicable to material-ui 0.15.x. Please contact me if interested, this could be published as something like material-ui-layout or material-ui-grid.

[oliviertassinari]

@rosskevin I would love to have a look at it. Would it make sens to share it in a gist?

[rosskevin]

@oliviertassinari

• Code gist
• Samples gist

The Samples gist recreates the flexboxgrid.com homepage samples.

[oliviertassinari]

@rosskevin Sweet. Thanks.

I think that we could create a _Layout_ docs section.
So people know we don't provide any solution for it and we can link some great project solving the issue.

[mbrookes]

@oliviertassinari I would be in favour of adding something based on @rosskevin's work to next. This is the single biggest FAQ by far on gitter, and a having "native" solution would make so much sense.

[pdf]

@rlmckenney I knocked up a trivial responsive grid system using Flexbox and redux-responsive a couple of days ago. Could probably simplify the breakpoint selection, but it's not terrible as is. Has covered all my use-cases so far.

An alternative if you didn't want extra DOM elements would be to convert these into HOCs that apply the styles to a wrapped component, which would be pretty trivial.

[oliviertassinari]

@rosskevin I'm curious. Why not using flexboxgrid with responsive breakpoints matching ours?

@mbrookes I agree, we need to do something about it! That could be a good idea.
However, I'm wondering if we have the time to maintain it.

[rosskevin]

@oliviertassinari I chose to use the flexboxgrid css code (it uses myth in the src), converted to jss within react components using material-ui breakpoints. The rationale is that when you boil down the original css code, it is quite repetitive and a good case to use jss (less to maintain). I also wanted fully self contained react components that can be included like any other react component (without a toolchain or global setup), as well as the dynamic prefixing etc that jss offers.

I do not think it is much to maintain, just check the commit log as evidence. Given periodic checks against commits from kristoferjoseph/flexboxgrid, there isn't much in the code as upkeep effort. What I fear is the number of the support _questions_, not in that the code will be changing much, but in that users will want to do things with it and not understand how to do it. This may be unfounded, given that the original project only has 144 issues all-time total, and it has 4000+ stars.

[stunaz]

I like the idea of https://github.com/callemall/material-ui/pull/5267, been using angular-material styles in the past, and loved it. its offers really more flexibility than flexboxgrid.

[ashl1]

I suppose if MUI want to use any grid system it should follow Google Material specification. So, from one hand it can be flexible, from the other it should not give the control to make grid inconsistent to GMD.

[oliviertassinari]

@rosskevin Right, from a technical point of view, I completely understand. I was more interested in the material design aspect. Turn out, after digging into the specification. I think that there is a real need for us to implement a solution. The material spec layout system is a 12 column system, with some specific breakpoints and margins / gutters.

I just had a look at #5267, that seem more complex but interesting too.

[dano-giftbit]

A material-ui spec grid would be very useful. We've considered react-mdl but only need the grid, currently trying to decide on the best route forward. There doesn't seem to be a good material spec grid out there that integrates well with material-ui.

[Cleanshooter]

@dano-giftbit I needed one too and was thinking the same thing, MDL but just the grid... I whipped up a starter this week and would interested in your thoughts. I'm going to be testing it with the full material-ui component kit next week, got a holiday coming up and need to head out of town right now though ;)

https://www.npmjs.com/package/material-grid

[oliviertassinari]

@Cleanshooter Thanks for sharing your project.
That's another good one to have a look at when designing our solution.

[oliviertassinari]

I have given a shot to that component. I would love to get some feedback #5808.

[oliviertassinari]

I first iteration have been merged with #5808. If you find anything that could be improved, fell free to raise your voice / open a PR. Thanks.

A preview is available here.

[mbrookes]

Awesome work @oliviertassinari!

[oliviertassinari]

Thanks, I have done a second iteration on that component for higher flexibility https://github.com/callemall/material-ui/pull/5827.

[DoWhileGeek]

That looks fantastic, @oliviertassinari, When do you think it will get tagged and bagged?

[oliviertassinari]

@DoWhileGeek What do you mean by tagged or bagged? Official Release won't happen until we have migrated all the components but we plan to do some beta / alpha releases before.

[thomasmodeneis]

do you plan plan to do some beta / alpha releases to happen still in this q1 ?
Cheers

[oliviertassinari]

@thomasmodeneis We do, have a look at https://github.com/callemall/material-ui/releases/tag/v1.0.0-alpha.1.

[thomasmodeneis]

@oliviertassinari oh nice, thanks.

[baerrach]

Another alternative is https://github.com/material-components/material-components-web/tree/master/packages/mdc-layout-grid