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

fix(google-maps): maintain subscriptions across event targets #20897

Merged
merged 1 commit into from
Oct 28, 2020

Conversation

crisbeto
Copy link
Member

This came up during the review of #20873. Currently the class that manages events for the Google Maps objects assumes that once a target is assigned, it'll either be maintained or eventually removed which means that the fix from #20873 will cause any existing event listeners to be dropped.

These changes add some code which will preserve the listeners.

Furthermore, I've added a dedicated testing setup for the MapEventManager since there's a fair bit of logic encapsulated in it and we've only been testing it by proxy through the various Google Maps components.

@crisbeto crisbeto added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent target: patch This PR is targeted for the next patch release labels Oct 27, 2020
@google-cla google-cla bot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Oct 27, 2020
@@ -18,11 +19,11 @@ export class MapEventManager {
/** Pending listeners that were added before the target was set. */
private _pending: {observable: Observable<any>, observer: Subscriber<any>}[] = [];
private _listeners: google.maps.MapsEventListener[] = [];
private _target: MapEventManagerTarget;
private _targets = new BehaviorSubject<MapEventManagerTarget>(undefined);
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this member name is a little confusing. It implies there are several targets at the same time, when in fact there is still just a single target.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Also, should the type be BehaviorSubject<MapEventManagerTarget|undefined> ?

Copy link
Member Author

Choose a reason for hiding this comment

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

My thinking with making it plural was that it's a "stream of targets", but since we don't follow the $ suffix convention for observables, there wasn't a better way to indicate it. I'll rename it.

As for the | undefined, it's not necessary since MapEventManagerTarget includes undefined already.

This came up during the review of angular#20873. Currently the class that manages events
for the Google Maps objects assumes that once a target is assigned, it'll either be
maintained or eventually removed which means that the fix from angular#20873 will
cause any existing event listeners to be dropped.

These changes add some code which will preserve the listeners.

Furthermore, I've added a dedicated testing setup for the `MapEventManager` since
there's a fair bit of logic encapsulated in it and we've only been testing it by proxy
through the various Google Maps components.
@crisbeto crisbeto force-pushed the 20873/google-maps-swap-target branch from f099676 to cc56523 Compare October 27, 2020 20:43
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

@jelbourn jelbourn added the action: merge The PR is ready for merge by the caretaker label Oct 27, 2020
Copy link
Collaborator

@mbehrlich mbehrlich left a comment

Choose a reason for hiding this comment

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

LGTM

@wagnermaciel wagnermaciel merged commit cc503c4 into angular:master Oct 28, 2020
wagnermaciel pushed a commit that referenced this pull request Oct 28, 2020
This came up during the review of #20873. Currently the class that manages events
for the Google Maps objects assumes that once a target is assigned, it'll either be
maintained or eventually removed which means that the fix from #20873 will
cause any existing event listeners to be dropped.

These changes add some code which will preserve the listeners.

Furthermore, I've added a dedicated testing setup for the `MapEventManager` since
there's a fair bit of logic encapsulated in it and we've only been testing it by proxy
through the various Google Maps components.

(cherry picked from commit cc503c4)
wagnermaciel pushed a commit that referenced this pull request Oct 28, 2020
This came up during the review of #20873. Currently the class that manages events
for the Google Maps objects assumes that once a target is assigned, it'll either be
maintained or eventually removed which means that the fix from #20873 will
cause any existing event listeners to be dropped.

These changes add some code which will preserve the listeners.

Furthermore, I've added a dedicated testing setup for the `MapEventManager` since
there's a fair bit of logic encapsulated in it and we've only been testing it by proxy
through the various Google Maps components.

(cherry picked from commit cc503c4)
@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 Nov 28, 2020
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 cla: yes PR author has agreed to Google's Contributor License Agreement P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants