MdDialog communication (i.e: passing data to MdDialog) #2181
Comments
|
If I'm understanding it correctly, you'd want the dialog module to be something like: constructor(data: SomeUserSuppliedData) {
console.log(data);
}Instead of having to do this: constructor(dialogRef: mdDialogRef) {
console.log(dialogRef.componentInstance.someUserSuppliedData);
} |
|
Yep, something like this: This does not apply constraints, it can be strict or Its much more angular than In my modal library it's working quite well. |
|
I still think that the best way(or at least a way that should be possible) to go about modals is to use inputs/outputs. <md-modal [open]="isModalOpen" (backdropClick)="isModalOpen = false">
<whatever-cmp
[data]="someData"
(onSave)="doWhatever($event);isModalOpen = false">
</whatever-cmp>
</md-modal>the way portal/overlay works, this can easily sit in your template, not created until I have yet to see a case where this wouldn't be sufficient. |
|
@fxck That's preference, its not best vs worst... just what people prefer. The question you should ask is, can I get from A->B and from B->A? Can you get from component based modal (your proposal) to a service base modal? I think no. So provide a service, if someone needs a declarative way later, no problem. @crisbeto About the providers, it's not much work anyway, you already need to create a child injector since you inject the |
jelbourn
added
the
feature
Adds the ability to pass in data to a dialog via the `data` property. While this was previously possible through the `dialogRef.componentInstance.someUserSuppliedProperty`, it wasn't the most intuitive. The new approach looks like this:
```
dialog.open(SomeDialog, {
data: {
hello: 'world'
}
});
class SometDialog {
constructor(data: MdDialogData) {
console.log(data['hello']);
}
}
```
Fixes angular#2181.
|
@shlomiassaf Can you please share your Workaround in a bin or plunker ? |
|
haha @shlomiassaf I pretty much came up with a similiar scenario... can you please share your workaround?
|
|
Hi guys, You need to remember that the Dialog service is still young :) @abidev @xtianus79 I can't find that piece of code so i'll try to write down what to do: Create a service with an open<T>(component: ComponentType<T>, config?: MdDialogConfig): MdDialogRef<T>;Extend Create a component that accepts a component and a list of providers as parameters and render it the component with the list of providers If you think it's complicated no worries once the NgComponentOutlet PR gets into angular you can use it to do the above with little effort (just use injector instead of providers). |
|
Dear all, look here... https://medium.com/@tarik.nzl/making-use-of-dialogs-in-material-2-mddialog-7533d27df41#.pf8d9o1ji Less code in controller(component) - only to call 'dialog' service... |
Adds the ability to pass in data to a dialog via the `data` property. While this was previously possible through the `dialogRef.componentInstance.someUserSuppliedProperty`, it wasn't the most intuitive. The new approach looks like this:
```
dialog.open(SomeDialog, {
data: {
hello: 'world'
}
});
class SometDialog {
constructor(data: MdDialogData) {
console.log(data['hello']);
}
}
```
Fixes angular#2181.
|
@patrykbialek I don't get how that answers what we are specifically referring to... Calling components and or modules isn't the issue... it is enacting upon code/functions at a specific point in time while the modal/dialog is awake. i.e. passing data to the open dialog modal. |
Adds the ability to pass in data to a dialog via the `data` property. While this was previously possible through the `dialogRef.componentInstance.someUserSuppliedProperty`, it wasn't the most intuitive. The new approach looks like this:
```
dialog.open(SomeDialog, {
data: {
hello: 'world'
}
});
class SometDialog {
constructor(data: MdDialogData) {
console.log(data['hello']);
}
}
```
Fixes angular#2181.
Adds the ability to pass in data to a dialog via the `data` property. While this was previously possible through the `dialogRef.componentInstance.someUserSuppliedProperty`, it wasn't the most intuitive. The new approach looks like this:
```
dialog.open(SomeDialog, {
data: {
hello: 'world'
}
});
class SometDialog {
constructor(data: MdDialogData) {
console.log(data['hello']);
}
}
```
Fixes angular#2181.
|
This is where you lose me @shlomiassaf:
Exactly how do you pass those parameters to the wrapper component? As input properties after it is instantiated (but wouldn't this be too late)? Or do you create a custom injector and then use |
@fxck My use case is that I want certain dialogs to be shown in response to the user clicking certain context menu items. These menus can be triggered by many different elements in many different routes from potentially different modules, so there is no obvious ancestor template to put them in and I obviously don't want to duplicate markup in different templates. Can you think of a nice way to handle such a situation without using the dynamic approach suggested above? |
|
depends on how many modals are you talking about, but what would I probably do is
|
|
@fxck Thanks for linking me to the |
|
@vigie it's literally the same as with using standard |
|
Also it doesn't necessarily have to be inside the root component, you can create one or more container components. It doesn't matter if you put |
* feat(dialog): add a config option for passing in data
Adds the ability to pass in data to a dialog via the `data` property. While this was previously possible through the `dialogRef.componentInstance.someUserSuppliedProperty`, it wasn't the most intuitive. The new approach looks like this:
```
dialog.open(SomeDialog, {
data: {
hello: 'world'
}
});
class SometDialog {
constructor(data: MdDialogData) {
console.log(data['hello']);
}
}
```
Fixes #2181.
* Switch to using an OpaqueToken.
* chore: fix aot errors
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug, feature request, or proposal: Proposal
What is the expected behavior?
Pass data to a component opened by the dialog service without depending on the dialog instance.
What is the current behavior?
You can pass data to a component by accessing it's instance and setting a predefined property.
What is the use-case or motivation for changing an existing behavior?
There are several ways to communicate with a dialog component:
MdDialogRefas a carrier - Set a single data item as part of the options, component consumed via MdDialogRef.data.The current behavior allow (4) and a limited (1)
It does not fit the angular pattern.
Angular uses DI a lot, this is part of the flow.
Since the dialog service abstract the component instantiation there is no control over the providers.
However, this process does allow changing providers by supplying an injector...
So all in all I think it should be possible to get some sort of control over the DI.
Workaround:
My current workaround is to create a service wrapping MdDialog.
This services uses a wrapper component as the Component to create.
The wrapper component then create the original component inside it with the supplied providers.
The text was updated successfully, but these errors were encountered: