Material-ui: [FullScreenDialog] Support for full screen dialogs

[kyle-vermaes]

Can material-ui support the following part of the spec?

https://www.google.com/design/spec/components/dialogs.html#dialogs-full-screen-dialogs

It could be baked in to the existing Dialog component, or added as a new component.

There is some discussion in issue #1748 about this, which ultimately concluded with the "solution" of either manually setting the height of the content or setting negative margins, both of which seem less than ideal. Currently my only alternative is to change the source locally, which obviously isn't great since I can't (easily) receive future upgrades.

Having an easy way of making the dialog go full-screen without the rounded corners would be much appreciated.

Thanks!

[mbrookes]

Currently my only alternative is to change the source locally, which obviously isn't great

Actually, changing the source locally is absolutely the best way to address this, since then you can submit it back as a PR so everyone can benefit! :+1:

https://github.com/callemall/material-ui/blob/master/CONTRIBUTING.md

[adieuadieu]

I also have a need for this in two projects I'm working on. I'm considering implementing it since it's missing from material-ui. Before I take a stab at producing a PR, are there any thoughts on how this could be implemented, in a way that's inline with the other prevailing design philosophies which have been incorporated into material-ui? Another way of saying that: Anyone have any ideas on how they might implement full screen dialogs?

My current thoughts are to start off with the code for the existing Dialog component as suggested in #1748 but also add the ability to slide the dialog in from the left or right edge of the screen, implementing behaviour you might see in one of Google's mobile app such as gmail or hangout.

[cgestes]

I did wrote a simple implementation of fullscreen dialog, that I called Window.

The dialog implementation is already very complicated, not sure we should add some more complication there, or some refactoring are needed to split concerns.

My 2 cents.

my code is not submitable, but I can try a new implementation with react-overlays.

[nathanmarks]

@cgestes hold up for a moment, we're figuring out the best route forward esp considering #156 which has recently come to my attention.

Feel free to chime in there by the way if you want to help out with this :+1:

[cgestes]

I'll check that if I work on it :)

On Sat, 9 Apr 2016, 02:26 Nathan, [email protected] wrote:

@cgestes https://github.com/cgestes hold up for a moment, we're
figuring out the best route forward esp considering #156
https://github.com/callemall/material-ui/issues/156 which has recently
come to my attention.

Feel free to chime in there by the way if you want to help out with this [image:
:+1:]

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/callemall/material-ui/issues/3553#issuecomment-207661622

[joadr]

I need this feature as well, now I did the tricky thing that sets the top style to a minus value, the thing is that it's not going to work well on all devices.

[lefnire]

In the interim you can use Bootstrap Modal. I know it's dirty to mix-n-match, but react-bootstrap's modal API is so similar to MUI's that it's a 30m swap; then full-screening via CSS is a breeze. Here's my own diff for such.

[IrvingAxelB]

+1

Im trying to have my dialog turn full screen for mobile users but I'm running into issues using media queries and changing the length of the dialog.

[jcheroske]

@IrvingAxelB I ran into very similar issues on a recent project. My take is that the dialog should be mobile-first, but it's not, and is therefore difficult to use responsively. It also behaves strangely when flexbox is turned on.

[dwilt]

I am also trying to achieve a fullscreen modal. I was a bit disappointed to see the lack of className hooks int the dialog options. There are 5 divs inside of the base Dialog component that come with styling, but there isn't a hook into the div that sets the max-height so it can easily be overridden with CSS. I'd imagine tying in this hook would be pretty easy.

[zuhair-naqvi]

+1 not having fullscreen dialogs is massive issue on mobile. Is this on the roadmap?

[nathanmarks]

@zuhair-naqvi I think I could roll this in to work I'm doing to address #156 for 0.16.0.

[oliviertassinari]

The dialog implementation is already very complicated, not sure we should add some more complication there

I agree, having a look at the material specification, I don't think that we should be using the actual Dialog to implement it. The UI look exactly like a normal view.
What's the point of reusing the Dialog?

[hashwin]

Any update on this? Adding this would be of amazing value.

[m19]

Why shouldn't we reuse Dialog for this? Shouldn't Dialog just be responsive? Ie. on big screens we show the actions on the bottom and keep space around it and on mobile we make it fullscreen and put the actions on top?

[dzenkovich]

I've managed to get modal full size via these styles, but this came at a cost of slide-out animation:

<Dialog repositionOnUpdate={false}
                autoDetectWindowHeight={false}
                modal={false}
                open={true}
                contentStyle={{width: '100%', transform: 'translate(0, 0)'}}
                bodyStyle={{padding: 0}}
                style={{paddingTop: 0, height: '100vh'}}
        >

[oliviertassinari]

Why shouldn't we reuse Dialog for this? Shouldn't Dialog just be responsive?

@m19 I'm quite opposed to this approach.
Reading the material design specification, I strongly think that the _Full-screen dialogs_ behavior described is from an UX point of view not from a component point of view.
I most cases, you will not display the same information on mobile and desktop. Making the Dialog a responsive component will lead to a poor UX. I think that the Dialog should stay a low level component that can be combined to provide a great UX experience.

The _Full-screen dialogs_ is a high level component. We haven't invested much in high level component.
We believe that we should focus on low level components so that the community can build one responsive component like this one (using the AppBar, the Paper, the IconButton, etc.)
Let me know what you think.

[m19]

@oliviertassinari that makes sense. Thanks!

Nobody in the community is working on this. Correct?

[oliviertassinari]

Nobody in the community is working on this.

Not I have heard of.
That shouldn't be too hard to do. Like building a castle with legos. The most challenging block I'm aware of is the animation.

[joshunger]

@oliviertassinari can you elaborate on "you will not display the same information on mobile and desktop"? For example, on the current project we're working on, we're displaying a contact us dialog. It has the same information on mobile and desktop but I would like the dialog full screen on mobile.

[oliviertassinari]

can you elaborate on

@joshunger What I'm saying is your business case might require you to need more than a responsive Dialog. E.g. You might want to add some IconButton on the left side of the AppBar.
What about the dialog's action, where should they be displayed?
The type of responsiveness needed here is high level. We can't get away with just styles.
Some JavaScript are definitely going to be needed.

[stunaz]

I think that Dialog responsiveness and Dialog fullscreen are two different things. Dialog responsiveness must be the responsibility of the developer.

[leMaik]

I know I'm late to the party, but I recently started implementing a FullscreenDialog, with animation simmilar to the animation found on Android. After reading this issue, I finally had some motivation to extract it into it's own project.

Once I have a little more spare time, I'll see if I can port it to next and provide a PR. :wink:

[StRibbon]

@leMaik Thank you!

[stunaz]

its already done in next https://material-ui-1dab0.firebaseapp.com/#/component-demos/dialogs

[StRibbon]

@stunaz unfortunately not available now. and I'm launching asap

[oliviertassinari]

@stunaz Thanks for reminding us that the next branch is now supporting it. @pradel Did a great job adding it. I'm closing.

[hhimanshu]

Is it not available right now?

[imornar]

I had use case when I needed all modals to be full screen only on xs screens.
What I did is to add these tree tags in Dialog definition:

bodyClassName="global--modal-body"
contentClassName="global--modal-content"
paperClassName="global--modal-paper"

and then I defined those classes globally like this:

@media (max-width: 600px) {
  .global--modal-content {
    width: 100% !important;
    transform: translate(0, 0) !important;
    position: absolute !important;
    top: 0 !important;
    height: 100vh !important;
  }

  .global--modal-body {
    padding: 0 !important;
    max-height: none !important;
  }

  .global--modal-paper {
    overflow: auto !important;
    height: 100vh !important;
  }
}

worked perfectly for me.

[kjr247]

This sounds wonderful. However, and it could just be that I have the "itis" from lunch, I am not entirely sure what you mean by "tree tags" or "Dialog definition".

I am imagining you mean that you added:

bodyClassName="global--modal-body"
contentClassName="global--modal-content"
paperClassName="global--modal-paper"

to the actual implementation inside the node package? My understanding of monkey patching tells me that probably isn't what you meant, because that only solves the issue until you want to update material-ui.

[leafoflegend]

@kjr247 If you look at http://www.material-ui.com/#/components/dialog you can see that those are props exposed by material-ui itself.

So if you set those props to those classNames and inject rules for those classes in CSS somehow, you can accomplish the above!