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

Allow componentFactoryResolver to be passed to MatDialog.open #16431

Closed
scriby opened this issue Jul 3, 2019 · 1 comment · Fixed by #16437
Closed

Allow componentFactoryResolver to be passed to MatDialog.open #16431

scriby opened this issue Jul 3, 2019 · 1 comment · Fixed by #16437
Assignees
Labels
feature This issue represents a new feature or feature request rather than a bug or bug fix P4 A relatively minor issue that is not relevant to core functions

Comments

@scriby
Copy link
Collaborator

scriby commented Jul 3, 2019

Feature Description

The portal made by MatDialog always defaults to the root component factory resolver, which means any dynamically rendered components must be registered in the root component. This seems to cause a lot of confusion (#1491, #8473) and lots of stack overflow posts.

Having to declare these components in the root module is bad for modularity and code splitting. It seems that if we could provide the component factory resolver to the portal (similar to how the viewContainerRef is provided for the injector), then it would be possible to define the dynamically created entryComponents in modules closer to where they're used.

See

const contentRef = dialogContainer.attachComponentPortal<T>(
new ComponentPortal(componentOrTemplateRef, undefined, injector));
. This code path is both not using the passed in viewContainerRef, and it also doesn't provide a componentFactoryResolver to the portal.

Use Case

Support lazy loaded dialog components, allowing for better code modularity and more precise code splitting.

@scriby scriby added the feature This issue represents a new feature or feature request rather than a bug or bug fix label Jul 3, 2019
@crisbeto crisbeto self-assigned this Jul 3, 2019
@crisbeto crisbeto added has pr P4 A relatively minor issue that is not relevant to core functions labels Jul 3, 2019
crisbeto added a commit to crisbeto/material2 that referenced this issue Jul 3, 2019
Allows for a different `ComponentFactoryResolver` to be passed in when creating a dialog.

Fixes angular#16431.
crisbeto added a commit to crisbeto/material2 that referenced this issue Jul 3, 2019
Allows for a different `ComponentFactoryResolver` to be passed in when creating a dialog.

Fixes angular#16431.
jelbourn pushed a commit that referenced this issue Jul 17, 2019
Allows for a different `ComponentFactoryResolver` to be passed in when creating a dialog.

Fixes #16431.
jelbourn pushed a commit that referenced this issue Jul 19, 2019
…in (#16437)

Allows for a different `ComponentFactoryResolver` to be passed in when creating a dialog.

Fixes #16431.
@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 11, 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 P4 A relatively minor issue that is not relevant to core functions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants