Responsive Material-UI #3614

Closed
mbrookes opened this Issue Mar 7, 2016 · 52 comments

Comments

@mbrookes
Member

mbrookes commented Mar 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alitaheri

alitaheri Mar 7, 2016

Member

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 😅

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.

Member

alitaheri commented Mar 7, 2016

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 😅

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

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Mar 7, 2016

Contributor

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 🎉 reference implementation 🎉. 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.

Contributor

aweary commented Mar 7, 2016

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 🎉 reference implementation 🎉. 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

This comment has been minimized.

Show comment
Hide comment
@alitaheri

alitaheri Mar 7, 2016

Member

@aweary I agree with you 👍 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 😅 we should investigate this in more details.

Member

alitaheri commented Mar 7, 2016

@aweary I agree with you 👍 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 😅 we should investigate this in more details.

@chrismcv

This comment has been minimized.

Show comment
Hide comment
@chrismcv

chrismcv Mar 7, 2016

Contributor

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!)

Contributor

chrismcv commented Mar 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Mar 8, 2016

Contributor

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

Contributor

aweary commented Mar 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathanmarks

nathanmarks Mar 8, 2016

Member

@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

Member

nathanmarks commented Mar 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@alitaheri

alitaheri Mar 8, 2016

Member

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.

Member

alitaheri commented Mar 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathanmarks

nathanmarks Mar 8, 2016

Member

@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 👍

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 😟

Member

nathanmarks commented Mar 8, 2016

@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 👍

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 😟

@julianmartinezmansell

This comment has been minimized.

Show comment
Hide comment
@julianmartinezmansell

julianmartinezmansell Apr 6, 2016

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Apr 6, 2016

Member

@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.

Member

oliviertassinari commented Apr 6, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@rosskevin

rosskevin Jun 2, 2016

Collaborator

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.

Collaborator

rosskevin commented Jun 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@rosskevin

rosskevin Jun 7, 2016

Collaborator

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.

Collaborator

rosskevin commented Jun 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathanmarks

nathanmarks Jun 8, 2016

Member

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

Member

nathanmarks commented Jun 8, 2016

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

@rosskevin

This comment has been minimized.

Show comment
Hide comment
@rosskevin

rosskevin Jun 8, 2016

Collaborator

@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.

Collaborator

rosskevin commented Jun 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nathanmarks

nathanmarks Jun 8, 2016

Member

@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!

Member

nathanmarks commented Jun 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@krasimir

krasimir Jun 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Jun 12, 2016

Member

@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.

Member

oliviertassinari commented Jun 12, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@kripod

kripod Jun 19, 2016

Contributor

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

Contributor

kripod commented Jun 19, 2016

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

@lancecarlson

This comment has been minimized.

Show comment
Hide comment
@lancecarlson

lancecarlson Jul 27, 2016

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! :)

lancecarlson commented Jul 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lesreaper

lesreaper Aug 10, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@nathanmarks

nathanmarks Aug 10, 2016

Member

@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?

Member

nathanmarks commented Aug 10, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@lesreaper

lesreaper Aug 10, 2016

@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?

desktop

mobile

lesreaper commented Aug 10, 2016

@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?

desktop

mobile

@oliviertassinari

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Aug 13, 2016

Member

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.

Member

oliviertassinari commented Aug 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bobmonteverde

bobmonteverde Aug 15, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@rlmckenney

rlmckenney Sep 13, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@vizath

vizath Sep 23, 2016

Contributor

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.

Contributor

vizath commented Sep 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@rlmckenney

rlmckenney Sep 23, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@hoschi

hoschi Sep 23, 2016

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

hoschi commented Sep 23, 2016

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

@rosskevin

This comment has been minimized.

Show comment
Hide comment
@rosskevin

rosskevin Sep 23, 2016

Collaborator

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.

Collaborator

rosskevin commented Sep 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Sep 23, 2016

Member

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

Member

oliviertassinari commented Sep 23, 2016

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

@rosskevin

This comment has been minimized.

Show comment
Hide comment
@rosskevin

rosskevin Sep 23, 2016

Collaborator

@oliviertassinari

The Samples gist recreates the flexboxgrid.com homepage samples.

Collaborator

rosskevin commented Sep 23, 2016

@oliviertassinari

The Samples gist recreates the flexboxgrid.com homepage samples.

@oliviertassinari

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Sep 23, 2016

Member

@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.

Member

oliviertassinari commented Sep 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mbrookes

mbrookes Sep 26, 2016

Member

@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.

Member

mbrookes commented Sep 26, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@pdf

pdf Sep 27, 2016

Contributor

@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.

Contributor

pdf commented Sep 27, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Sep 27, 2016

Member

@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.

Member

oliviertassinari commented Sep 27, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@rosskevin

rosskevin Sep 27, 2016

Collaborator

@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.

Collaborator

rosskevin commented Sep 27, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@stunaz

stunaz Sep 29, 2016

Contributor

I like the idea of #5267, been using angular-material styles in the past, and loved it. its offers really more flexibility than flexboxgrid.

Contributor

stunaz commented Sep 29, 2016

I like the idea of #5267, been using angular-material styles in the past, and loved it. its offers really more flexibility than flexboxgrid.

@ashl1

This comment has been minimized.

Show comment
Hide comment
@ashl1

ashl1 Sep 29, 2016

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.

ashl1 commented Sep 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Oct 2, 2016

Member

@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.

Member

oliviertassinari commented Oct 2, 2016

@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.

@rosskevin rosskevin referenced this issue Nov 15, 2016

Closed

[Layout]: Add new `Layout` components #5267

3 of 3 tasks complete
@dano-giftbit

This comment has been minimized.

Show comment
Hide comment
@dano-giftbit

dano-giftbit Nov 15, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@Cleanshooter

Cleanshooter Nov 23, 2016

@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

@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

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Nov 24, 2016

Member

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

Member

oliviertassinari commented Nov 24, 2016

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

@oliviertassinari

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Dec 21, 2016

Member

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

Member

oliviertassinari commented Dec 21, 2016

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

@oliviertassinari

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Dec 25, 2016

Member

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.

Member

oliviertassinari commented Dec 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mbrookes

mbrookes Dec 27, 2016

Member

Awesome work @oliviertassinari!

Member

mbrookes commented Dec 27, 2016

Awesome work @oliviertassinari!

@oliviertassinari

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Dec 27, 2016

Member

Thanks, I have done a second iteration on that component for higher flexibility callemall#5827.

Member

oliviertassinari commented Dec 27, 2016

Thanks, I have done a second iteration on that component for higher flexibility callemall#5827.

@DoWhileGeek

This comment has been minimized.

Show comment
Hide comment
@DoWhileGeek

DoWhileGeek Jan 3, 2017

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

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

@oliviertassinari

This comment has been minimized.

Show comment
Hide comment
@oliviertassinari

oliviertassinari Jan 3, 2017

Member

@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.

Member

oliviertassinari commented Jan 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@thomasmodeneis

thomasmodeneis Jan 30, 2017

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

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

@oliviertassinari

This comment has been minimized.

Show comment
Hide comment
@thomasmodeneis

This comment has been minimized.

Show comment
Hide comment

@oliviertassinari oh nice, thanks.

@fzaninotto fzaninotto referenced this issue in marmelab/react-admin Feb 18, 2017

Closed

Responsive Datagrid #282

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment