-
Notifications
You must be signed in to change notification settings - Fork 6.8k
refactor(cdk/overlay): remove logic which tracks excluded elements from outside clicks #19887
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,11 +59,6 @@ export class OverlayConfig { | |
*/ | ||
disposeOnNavigation?: boolean = false; | ||
|
||
/** | ||
* Array of HTML elements clicking on which should not be considered as outside click | ||
*/ | ||
excludeFromOutsideClick?: HTMLElement[] = []; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we talked about having this be a predicate function instead of an array of elements. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jelbourn we later agreed that we should just emit on the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, when Andy and I followed-up on the discussion in the team meeting, I remembered that the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jelbourn thinking about it now, adding a predicate can stop overlays added earlier from being processed since the loop would just break based on the predicates return. I can implement the menu with either approach but I'm not sure if there's some edge cases where we may want an early break. Edit: agreed to leave as is |
||
|
||
constructor(config?: OverlayConfig) { | ||
if (config) { | ||
// Use `Iterable` instead of `Array` because TypeScript, as of 3.6.3, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these disposals happen in an afterEach() block, so they happen even if the test fails?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slightly tricky because different tests create a different number of overlays; it would probably be better to de-dupe the dispose calls, but I wouldn't hold up the PR on it since it was already like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@teflonwaffles I agree that it should be cleaned up, but I opted to keep with the structure of the existing tests rather than polluting this PR with a test refactor.