MdDialog communication (i.e: passing data to MdDialog)

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:

1. Custom Dependency injection - Set Providers as part of the options
2. Fixed Dependency injection - Set a single data item as part of the options, injected via a token.
3. MdDialogRef as a carrier - Set a single data item as part of the options, component consumed via MdDialogRef.data.
4. Direct assignment - Current behavior

The current behavior allow (4) and a limited (1)

(1) Only predefined providers.

It does not fit the angular pattern.

Angular uses DI a lot, this is part of the flow.

• Automatic errors if DI mismatch
• Allows proper use of hooks
• Less dependant

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.

[fxck]

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 [open] is true, and you can use the component inside as you would any other angular2 component. It’s as angular2 as it gets.

I have yet to see a case where this wouldn’t be sufficient.

[shlomiassaf]

Yep, something like this:

constructor(dialogRef: mdDialogRef,  /*public?*/ data: SomeUserSuppliedData) {
}

This does not apply constraints, it can be strict or @Optional and the developer doesn’t need to check if the value has been assigned or not… if not the DI will throw.

Its much more angular than

dialogRef.componentInstance.someUserSuppliedData

In my modal library it’s working quite well.