Feature Description

#4398 introduced a generic type argument for MatDialogConfig. This type argument is forwarded in open. However, the type is never tied in anyway to the actual component, making the type argument an essentially useless type assertion.

While due to the nature of Angular's dependency injection full type-safety cannot be achieved, it would be nice if at least the dialog component could declare the type it receives itself in such a way that a call to open will infer the correct type automatically. In order to achieve this, the dialog component needs to somehow expose this information. Here are a few possible solutions in no particular order, though others might exist:

Interface with type inference

We could define an interface and a helper type as follows:

interface MatDialogHasData<T> {
  data: T;
}

type ExtractDialogDataType<T> = T extends MatDialogHasData<infer D> ? D : any;

We can then adjust the type signature of open to infer the type accordingly:

open<T, R = any>(
  component: ComponentType<T>, 
  data?: MatDialogConfig<ExtractDialogDataType<T>>
): MatDialogReg<T, R>

Finally, a dialog component would be required to have a public field named data of the according type, which would typically be achieved through the injection itself:

constructor(@Inject(MAT_DIALOG_DATA) public data: MyDialogDataType) {}

Note: This change is breaking because the generic signature of open changes and because dialog components could have an unrelated data field which would lead to an unintended type inference. Unfortunately we cannot prevent this here due to TypeScript's structural typing nature. In particular users would no longer be able to manually define the generic type argument. However see further below for a solution to this problem.

Interface with explicit method

Instead, we could also introduce an interface with an explicit method to be implemented:

interface MatDialogHasData<T> {
  getDialogData(): T
}

Otherwise the approach is largely similar. This change is only breaking in the generic type signature (I'm not sure whether you count this as a breaking change), however we could actually avoid that by changing our helper type to

type ExtractDialogDataType<T, FALLBACK> = T extends MatDialogHasData<infer D> ? D : FALLBACK;

and then using the type argument as a fallback:

open<T, D = any, R = any>(
  component: ComponentType<T>, 
  data?: MatDialogConfig<ExtractDialogDataType<T, D>>
): MatDialogReg<T, R>

Note: The same could be done in the solution above. I believe we could make this a completely backwards-compatible change, excluding of course the exotic situation that a component happens to already have a getDialogData method for unrelated reasons. The only disadvantage here is forcing the component to provide a public method. In practice I don't consider this a concern as Angular already forces us to make many things public that shouldn't be public from a component API perspective.

On a very similar note, it would be nice to have the same for the inferred result type R, i.e. the component being able to define the type of data it can return, and have this information flow through the open method to the caller. The approaches mentioned above could, in theory, cover this as well.

Use Case

Given some MyDialogComponent which expects dialog data of type MyDialogData, I would like

open(MyDialogComponent, {
  data: {
    // …
  }
});

to type-check data against MyDialogData without having to manually specify open's type arguments, but rather have this information flow from MyDialogComponent.