Skip to content

refactor(cdk-experimental/dialog): rewrite experimental dialog #24759

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

Merged
merged 1 commit into from
Apr 20, 2022

Conversation

crisbeto
Copy link
Member

Rewrites most of the CDK experimental dialog to prepare it for public release. The changes were largely informed by implementing material/dialog, material-experimental/mdc-dialog and material/bottom-sheet using the new API, however the API can be used directly without having to be wrapped. Overview of the changes:

  • The classes for the dialog container, dialog config and dialog data aren't provided using DI anymore. The previous approach could've been a problem for apps that use multiple different versions of a CDK-based dialog.
  • Several fixes from the Material dialog that were never backported to the CDK version have been incorporated.
  • All animations and styles have been removed from the CDK dialog since they were going to be difficult to override by users. Custom animations can be achieved by extending the dialog container class.
  • The public API has been cleaned up to avoid some of the issues that were inherited from the Material dialog.
  • A demo has been added to the dev app.

Example of how the new APIs was used to implement the Material components: crisbeto@446a552.

@crisbeto crisbeto added P2 The issue is important to a large percentage of users, with a workaround target: major This PR is targeted for the next major release labels Apr 11, 2022
@crisbeto crisbeto requested review from a team, mmalerba, devversion and jelbourn as code owners April 11, 2022 15:36
@crisbeto crisbeto force-pushed the finalize-cdk-dialog branch from 656ea61 to 0a7ff56 Compare April 11, 2022 15:39
@crisbeto crisbeto requested a review from andrewseguin as a code owner April 11, 2022 15:39
@crisbeto crisbeto force-pushed the finalize-cdk-dialog branch from 0a7ff56 to 41bb9dc Compare April 11, 2022 15:55
@josephperrott josephperrott removed the request for review from a team April 11, 2022 15:55
@crisbeto crisbeto force-pushed the finalize-cdk-dialog branch from 41bb9dc to 4ca7fef Compare April 14, 2022 22:11
Rewrites most of the CDK experimental dialog to prepare it for public release. The changes were largely informed by implementing `material/dialog`, `material-experimental/mdc-dialog` and `material/bottom-sheet` using the new API, however the API can be used directly without having to be wrapped. Overview of the changes:
* The classes for the dialog container, dialog config and dialog data aren't provided using DI anymore. The previous approach could've been a problem for apps that use multiple different versions of a CDK-based dialog.
* Several fixes from the Material dialog that were never backported to the CDK version have been incorporated.
* All animations and styles have been removed from the CDK dialog since they were going to be difficult to override by users. Custom animations can be achieved by extending the dialog container class.
* The public API has been cleaned up to avoid some of the issues that were inherited from the Material dialog.
* A demo has been added to the dev app.

Example of how the new APIs was used to implement the Material components: 446a552.
@crisbeto crisbeto force-pushed the finalize-cdk-dialog branch from 4ca7fef to 0eb132e Compare April 19, 2022 08:49
@crisbeto
Copy link
Member Author

crisbeto commented Apr 19, 2022

All of the feedback should be implemented now. In the last push I also ended up moving around the generic parameters of Dialog.open a bit. Previously the signature was something like open<ComponentType, DataType, ResultType> which can be annoying since the most common case is to type the result and the data. I've changed it so it's open<ResultType, DataType, ComponentType>. It's also worth noting that most of the time the ComponentType and DataType can be inferred automatically from the parameters that are passed in.

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Comment on lines +119 to +126
/** Alternate `ComponentFactoryResolver` to use when resolving the associated component. */
componentFactoryResolver?: ComponentFactoryResolver;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does the Material dialog need to pass it through, though? Isn't it the same to use this vs. instantiating the component directly? (which admittedly would require a code change in the portal, but we should probably do that anyway?)

@crisbeto crisbeto added the action: merge The PR is ready for merge by the caretaker label Apr 20, 2022
@crisbeto crisbeto merged commit 3889165 into angular:master Apr 20, 2022
@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 May 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker P2 The issue is important to a large percentage of users, with a workaround target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants