-
Notifications
You must be signed in to change notification settings - Fork 6.8k
feat(dialog): add ability to open dialog with templateRef #2853
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
Changes from 5 commits
ad9617f
14ef81c
bd19bd3
dbb1676
1803505
9a0a28b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,3 +6,7 @@ | |
max-width: 350px; | ||
margin: 20px 0; | ||
} | ||
|
||
.demo-button-group { | ||
margin-bottom: 20px; | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,10 +14,18 @@ export class MdDialogRef<T> { | |
/** The instance of component opened into the dialog. */ | ||
componentInstance: T; | ||
|
||
/** Expose overlay backdrop click event */ | ||
backdropClicked: Observable<void>; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should be I don't think there needs to be an API for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's what I thought first as well, but then there is As for escape, there is |
||
|
||
/** Subject for notifying the user that esc key way pressed */ | ||
escapePressed = new Subject<void>(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FYI: the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is that I need to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure that we need observables for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That wouldn't trigger if escape/backdrop click didn't actually close the dialog. Which in result wouldn't allow for creating a stateless dialog component(which is honestly a must have in redux and ngrx/store world). Or There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. EDIT: I see what you mean, but why would the user want to know that the backdrop was clicked and it didn't result in a close? You could differentiate it based on the source. My worry is that we're ending up with 5-6 different dialog-related observables. If we added these, we'd have 3 just for the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What could I differentiate? The problem is that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My question is why does the user need to know that an attempt to close it was made? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Check #2855 Imagine you keep state of your modal in a global store, like redux or @ngrx/store, so you create a component that looks like this. <my-dialog [open]="modalState$ | async">
<button (click)="doSomethingThatChangesModalState$toFalse()">close</button>
</my-dialog> Now you are in full control of the state, when you change So ideally you want to do <my-dialog
[open]="modalState$ | async"
(close)="doSomethingThatChangesModalState$toFalse()">
<button (click)="doSomethingThatChangesModalState$toFalse()">close</button>
</my-dialog> where close event happens on either It's what's called stateless components and what you want to do when using redux or store. There are other components where this would make sense, for example keeping sidenav state inside ngrx/store is currently a bit of a pain in the ass as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, it makes sense. I still think that they should be combined into something along the lines of |
||
|
||
/** Subject for notifying the user that the dialog has finished closing. */ | ||
private _afterClosed: Subject<any> = new Subject(); | ||
|
||
constructor(private _overlayRef: OverlayRef) { } | ||
constructor(private _overlayRef: OverlayRef) { | ||
this.backdropClicked = this._overlayRef.backdropClick(); | ||
} | ||
|
||
/** | ||
* Close the dialog. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
TemplateRef
should be instantiated indialog.ts
and we should just callattach
on the dialog container (fromBasePortalHost
) that will delegate to the appropriate method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this correctly, but to be able to create a portal, you need ViewContainerRef, which is not accessible inside
dialog.ts
. In my previous PR I hadMdDialog.openFromPortal()
, but I think it a little too tedious for user to have to create a portal rather than to be just able to pass inTemplateRef
. But I don't really mind either.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I could make
ViewTemplateRef
available todialog.ts
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about types thought, wouldn't you lose them by just calling
attach
instead ofattachComponentPortal
/attachTemplatePortal
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also if I just use
attach
, typescript will complain about not properly implementingattachTemplatePortal
andattachComponentPortal
.. what should I do please, @jelbourn ?