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(ivy): maintain coalesced listeners order #32484

Closed

Conversation

@AndrewKushnir
Copy link
Contributor

commented Sep 5, 2019

Prior to this commit, listeners order was not preserved in case we coalesce them to avoid triggering unnecessary change detection cycles. For performance reasons we were attaching listeners to existing events at head (always using first listener as an anchor), to avoid going through the list, thus breaking the order in which listeners are registered. In some scenarios this order might be important (for example with ngModelChange and input listeners), so this commit updates the logic to put new listeners at the end of the list. In order to avoid performance implications, we keep a pointer to the last listener in the list, so adding a new listener takes constant amount of time.

This PR resolves FW-1528.

PR Type

What kind of change does this PR introduce?

  • Bugfix

Does this PR introduce a breaking change?

  • Yes
  • No
@ngbot ngbot bot modified the milestone: needsTriage Sep 5, 2019
@googlebot googlebot added the cla: yes label Sep 5, 2019
@AndrewKushnir AndrewKushnir marked this pull request as ready for review Sep 5, 2019
@AndrewKushnir AndrewKushnir requested review from angular/fw-core as code owners Sep 5, 2019
Copy link
Member

left a comment

LGTM, I used to have an alternative approach here: #29786 (comment)
But your approach works for me as well

@AndrewKushnir

This comment has been minimized.

Copy link
Contributor Author

commented Sep 5, 2019

packages/forms/test/template_integration_spec.ts Outdated Show resolved Hide resolved
Prior to this commit, listeners order was not preserved in case we coalesce them to avoid triggering unnecessary change detection cycles. For performance reasons we were attaching listeners to existing events at head (always using first listener as an anchor), to avoid going through the list, thus breaking the order in which listeners are registered. In some scenarios this order might be important (for example with `ngModelChange` and `input` listeners), so this commit updates the logic to put new listeners at the end of the list. In order to avoid performance implications, we keep a pointer to the last listener in the list, so adding a new listener takes constant amount of time.
@AndrewKushnir AndrewKushnir force-pushed the AndrewKushnir:FW-1528_listeners_order branch from 69486ae to 193dd2c Sep 5, 2019
@AndrewKushnir AndrewKushnir requested a review from kara Sep 5, 2019
@kara
kara approved these changes Sep 5, 2019
Copy link
Contributor

left a comment

LGTM

@matsko matsko closed this in 098feec Sep 5, 2019
sabeersulaiman added a commit to sabeersulaiman/angular that referenced this pull request Sep 6, 2019
Prior to this commit, listeners order was not preserved in case we coalesce them to avoid triggering unnecessary change detection cycles. For performance reasons we were attaching listeners to existing events at head (always using first listener as an anchor), to avoid going through the list, thus breaking the order in which listeners are registered. In some scenarios this order might be important (for example with `ngModelChange` and `input` listeners), so this commit updates the logic to put new listeners at the end of the list. In order to avoid performance implications, we keep a pointer to the last listener in the list, so adding a new listener takes constant amount of time.

PR Close angular#32484
arnehoek added a commit to arnehoek/angular that referenced this pull request Sep 26, 2019
Prior to this commit, listeners order was not preserved in case we coalesce them to avoid triggering unnecessary change detection cycles. For performance reasons we were attaching listeners to existing events at head (always using first listener as an anchor), to avoid going through the list, thus breaking the order in which listeners are registered. In some scenarios this order might be important (for example with `ngModelChange` and `input` listeners), so this commit updates the logic to put new listeners at the end of the list. In order to avoid performance implications, we keep a pointer to the last listener in the list, so adding a new listener takes constant amount of time.

PR Close angular#32484
@angular-automatic-lock-bot

This comment has been minimized.

Copy link

commented Oct 6, 2019

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 Oct 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.