md-dialog: One should be able to open multiple "full screen" dialogs

[asans]

Feature Enhancement Request

Considering that Material Design specs allows the use of multiple dialogs to be open on top of one another, I believe this should really be supported. One use for this is when one wants to open up a full screen dialog and still show some dialog alerts or confirmations. The other use is the way one can open one full screen dialog on top of another on top of another. Canceling/closing the dialog will take you back to the previous one without having to reload the view, which will force one to lose context and lose track of where we were before.

A great example would be the list-to-detail view. You load a list of items and as you scroll down and see one you like to view more details of (ie. an order), you click on it to open up a full screen dialog to view the details of the order. After you view it, you will want to go back to where you were before and continue. This is also the case with reading news stories or even cards. If we had to go back by refreshing, we'd have to first load all the entries up to that point and then scroll to where we were. This is far less efficient than just allowing multiple dialog screens.

The above scenarios are frequently encountered and well implemented in the android UI (see settings and even some of the android apps like Facebook or Google+).

[dgavigan]

this sounds like two request.

1. support fullscreen dialog, which there is already an issue for adding fullscreen option for mobile to $mdDialog #2148
2. support layering dialogs? not 100% sure on whats being described.

[asans]

#2148 covers the full screen dialogs, which is used to describe the scenario here. Since my example is a bit confusing, let me copy verbatim the text from Material Design Specs about Full Screen Dialogs.

The bits that I want to emphasize is in bold below:

---

Usage

Full-screen dialogs group complex tasks that require explicit action, such as save or create, before changes are committed or discarded, as in a calendar entry.

Full-screen dialogs enable complex layouts, minimize the appearance of stacked sheets of material (dialogs above dialogs) and increase the app’s perceived z-depth. They enable individual tasks to launch simple menus or simple dialogs as part of the complex operation.

Consider using a full-screen dialog when the content or process meets any of the following criteria:

The dialog includes components like pickers or form fields requiring an input method editor (IME), such as a keyboard.
When changes are not saved in real time
When there is no draft capability in the app
When performing batch operations or queuing changes prior to submitting them
No modifications and selections made in the full-screen dialog are saved until “Save” is touched. Touching the “X” will discard all changes and exit the dialog.

---

So better to say that it's "dialog above dialogs" should be a supported feature in the future instead of just allowing only one single dialog to always be open at any one time.

[dgavigan]

Gotcha. Sounds useful indeed.

So, this looks like to be coming in v0.10 as mentioned in #698 by @ThomasBurleson

it [fullscreen/stacked] is a new feature that we will try to address in 0.10.

[naomiblack]

We agree this needs discussion, but unfortunately, we will not be able to add it before beta.

[prasannapattam]

Is there a timelines when this will be implemented (1.0-beta1)

[blakemanzo]

+1

[thunghan]

+1

[hnirvana]

+1

[reduardo7]

+1

[knizhnikov]

+1

[B3nCr]

@ThomasBurleson Sorry to be a pain but why are these being marked as Deprecated? Is there some guidance about an alternative pattern than using multiple dialogs?
Thanks

[ThomasBurleson]

Material1 will only support singleton diaologs. Material2 will support multiple dialogs.

[jaymanned]

@thomas Sorry to get back on this. What you are saying is that material for angular 1.x apps will never support dialog stacking? It's easy to see that dialog stacking is one of the most popular feature requests in this repo. For a reason, it is a very well established interaction pattern for web apps (e.g. confirm action taken on main dialog).

May I kindly ask the ng-material team to reconsider? If not possible, at least you could provide some workable alternative as suggested by @B3nCr ?

Thanx

[niveo]

http://www.codeproject.com/Articles/992699/An-Advanced-and-Easy-use-AngularJS-Modal-Dialog

[B3nCr]

@niveo I meant a pattern that follows the Material design spec.

[cesarpx]

@ThomasBurleson I really need this issue for an Agular 1.5 app I have, I can't just migrate the app to Angular 2 just because this basic feature is not available. Please let me add this functionality as a pull request, I'll wait for your answer.

[devversion]

@vassagus See #8630

[cesarpx]

@devversion thanks.

[olingern]

Unsure why this isn't documented but using skipHide on the child dialog will allow this.

Here's a plunker

And here's the line of code that "skips" hiding the parent dialog.

[jaymanned]

@olingern Great finding!

Can anyone please confirm if we can use this undocumented option safely

[jaymanned]

@olingern I've styled slightly your plunker so the stacking effect is more evident

[olingern]

@jaymanned I believe there are some issues with earlier Angular version support. The plunkr isn't actually mine. I stumbled across it here.

I eventually also stumbled across this that gives a little more detail, and is the origin of the hack / plunkr (I believe).

Here's how I'm currently using this:

Parent Setup:

$mdDialog.show({
        controller: 'MyCtrl',
        controllerAs: 'vm'
      }).then(function(res){
        _manageChildDialogAction(res);
      });

Child setup

  $mdDialog.show($mdDialog.confirm({
        title: 'Delete?',
        textContent: 'You will not be able to undo this. Are you sure?',
        ok: 'Delete',
        cancel: 'Cancel',
        skipHide: true
      })).then(function(del){
        $mdDialog.hide({
         customObject: _customObject,
         action : 'DELETE'
         });
      },function(cancel){

      })

For completeness, here's my child modal resolution handler

function _manageChildDialogAction(modalRes){
  var action = modalRes.action;

  if (action === 'SAVE') {

  } else if(action === 'DELETE') {    

  }
}