Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for hiding a dialog without closing it #6206

Closed
superMDguy opened this issue Aug 1, 2017 · 8 comments · Fixed by #14772
Closed

Add support for hiding a dialog without closing it #6206

superMDguy opened this issue Aug 1, 2017 · 8 comments · Fixed by #14772
Labels
feature This issue represents a new feature or feature request rather than a bug or bug fix help wanted The team would appreciate a PR from the community to address this issue P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@superMDguy
Copy link

Bug, feature request, or proposal:

Only show one dialog at a time.

What is the expected behavior?

When a dialog is opened from within another dialog, all other open dialogs should be hidden.

What is the current behavior?

The new dialog gets layered on top of the old dialog(s)

What are the steps to reproduce?

  1. Open a dialog
  2. Open another dialog from within that dialog

Plunker: https://plnkr.co/edit/GglOLDnx1uJlZRgD4y1W?p=preview

What is the use-case or motivation for changing an existing behavior?

In angularjs material, multiple dialogs weren't allowed by default. See, for example http://plnkr.co/edit/qNu3q5XsIie1fYjKeJRc?p=preview. Ideally, though, there'd be a virtual stack of dialogs maintained, where only the topmost item on the stack is visible.

Is there anything else we should know?

Currently, I can work around the issue by running

Array.from(document.querySelectorAll(".cdk-overlay-container .cdk-global-overlay-wrapper")) .forEach((node, index, array) => (index !== array.length - 1) ? (<HTMLElement> node).style.display = "none" : true);

in ngOnInit, and running

Array.from(document.querySelectorAll(".cdk-overlay-container .cdk-global-overlay-wrapper")) .forEach((node) =>(<HTMLElement> node).style.display = "" );

in ngOnDestroy.

This works, and effectively creates a stack of hidden dialogs. But I don't want to add that snippet in every dialog that could possibly be opened from another dialog.

@tinayuangao tinayuangao added the feature This issue represents a new feature or feature request rather than a bug or bug fix label Aug 1, 2017
@jelbourn
Copy link
Member

jelbourn commented Aug 1, 2017

We intentionally support opening multiple dialogs at the same time.

What is missing, however, is a way to hide a dialog without closing it when you only have a DialogRef. Going to re-purpose this issue for that feature.

@jelbourn jelbourn changed the title Only show one dialog at a time Add support for hiding a dialog without closing it Aug 1, 2017
@jelbourn
Copy link
Member

jelbourn commented Aug 1, 2017

We could potentially do this by adding a hide API to MdDialogRef, but I think that this introduces too much confusion between close and hide. Instead, I think it would make sense to add the ability to add/remove css classes to the dialog via MdDialogRef.

@jelbourn jelbourn added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent help wanted The team would appreciate a PR from the community to address this issue labels Aug 1, 2017
@superMDguy
Copy link
Author

How about a way to set an "inactive" class on the overlay pane that's automatically applied to all but the topmost dialog?

@julianobrasil
Copy link
Contributor

julianobrasil commented Aug 2, 2017

If the default behavior is to hide the dialog, maybe the hide API isn't so confusing. An attribute in the parameter object passed to the open function would be simple to use. It would be something like

dialog.open({
  hideOnCascade: false 
});

The default behavior would be true. So the user could specify different when necessary.

@superMDguy superMDguy reopened this Aug 2, 2017
@xban1x
Copy link

xban1x commented Aug 7, 2017

I would be interested to help out with this small feature. But hideOnCascade seems wrong to me...

@willshowell
Copy link
Contributor

#6289 will probably help. It makes openDialogs public so you can access all open DialogRefs and assign unique ids to them for tracking.

Also agree with the dynamic add/remove classes approach since it gives you more flexibility of "inactive" dialogs that just hiding (e.g. lower opacity, transformations).

@superMDguy
Copy link
Author

The PR @willshowell's mentioned is a step in the right direction. Additionally, it'd be good to either have a way to add a class to a MdDialogRef, like @jelbourn suggested, or to have an automatically applied "inactive" class, like I suggested earlier. I like the "inactive" class better, because it makes things cleaner for me, but if it's too much of a niche use case it might be better to just use @jelbourn's suggestion.

@jelbourn jelbourn removed their assignment Jan 9, 2018
willshowell added a commit to willshowell/material2 that referenced this issue Jan 9, 2019
vivian-hu-zz pushed a commit that referenced this issue Jan 14, 2019
* feat(dialog): support adding/removing panelClasses to open dialogRef

Fixes #6206

* address comments
s2-abdo pushed a commit to s2-abdo/material2 that referenced this issue Jan 18, 2019
…lar#14772)

* feat(dialog): support adding/removing panelClasses to open dialogRef

Fixes angular#6206

* address comments
s2-abdo pushed a commit to s2-abdo/material2 that referenced this issue Jan 18, 2019
…lar#14772)

* feat(dialog): support adding/removing panelClasses to open dialogRef

Fixes angular#6206

* address comments
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature This issue represents a new feature or feature request rather than a bug or bug fix help wanted The team would appreciate a PR from the community to address this issue P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants