Skip to content

fix(forms): ensure OnPush ancestors are marked dirty when the promise resolves#39879

Closed
arturovt wants to merge 1 commit intoangular:masterfrom
arturovt:fix/10816
Closed

fix(forms): ensure OnPush ancestors are marked dirty when the promise resolves#39879
arturovt wants to merge 1 commit intoangular:masterfrom
arturovt:fix/10816

Conversation

@arturovt
Copy link
Contributor

PR Checklist

PR Type

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

Issue Number: #10816

Currently, ngModel calls setValue after the resolvedPromise is resolved. This means that change detection will not be run for this component if it's inside an OnPush component, because it is not marked as dirty.

What is the new behavior?

Does this PR introduce a breaking change?

  • Yes
  • No

… resolves

Currently, `ngModel` calls` setValue` after the `resolvedPromise` is resolved.
This means that change detection will not be run for this component if it's inside
an OnPush component, because it is not marked as dirty.

PR Close #10816
@google-cla google-cla bot added the cla: yes label Nov 29, 2020
@pullapprove pullapprove bot requested a review from AndrewKushnir November 29, 2020 13:35
@jessicajaniuk jessicajaniuk added the area: core Issues related to the framework runtime label Dec 1, 2020
@ngbot ngbot bot added this to the needsTriage milestone Dec 1, 2020
@AndrewKushnir AndrewKushnir added area: forms and removed area: core Issues related to the framework runtime labels Dec 1, 2020
@pullapprove pullapprove bot removed the area: forms label Dec 9, 2020
@ngbot ngbot bot removed this from the needsTriage milestone Dec 9, 2020
@ngbot ngbot bot added this to the Backlog milestone Dec 10, 2020
@AndrewKushnir AndrewKushnir added action: review The PR is still awaiting reviews from at least one requested reviewer breaking changes target: major This PR is targeted for the next major release labels Feb 17, 2021
@AndrewKushnir
Copy link
Contributor

Hey @arturovt, sorry for the delay in answering! Just wanted to mention that this PR is likely introducing a relatively big breaking change from behavior standpoint where more views would be processed by change detection. We will need to look into this more and see if there similar approaches and/or whether we need to have a flag to opt-in/opt-out of this behavior. I will keep this thread updated, but I don't have any ETA at this moment. Thank you.

@atscott atscott added cla: yes and removed cla: yes labels Jan 27, 2022
@atscott
Copy link
Contributor

atscott commented Jan 27, 2022

presubmit

@atscott
Copy link
Contributor

atscott commented Jan 29, 2022

Hi @arturovt, @AndrewKushnir and I investigated this today. Here's a summary of our findings:

  • We've determined that this is the right fix due to how NgModel is doing the Promise.resolve. The fact that the Promise is used causes the setValue to be called after the child template executes.
  • Ideally, this Promise would not even exist (if it didn't we wouldn't have this issue in the first place because the setValue would be called at the correct time). Unfortunately, that's a change we can't make because it would be too breaking.
  • We were concerned a bit about the performance implications - while NgModel already triggers another change detection by using the Promise, it doesn't necessarily result in anything being checked (because there might not be anything that's dirty). We determined that this shouldn't be an issue for two reasons:
    • First, anyone using ngModel and showing the value in the template would already need to be calling markForCheck to get the right value displayed (and what would be the point of the control without displaying the current value).
    • Second, if it really does have a performance impact for people in rare cases, we can add an option on NgModel to not call markForCheck
  • There was only one failure in all of Google's internal tests. We've sent out a change request to update the test to be more correct.

Could you please rebase this PR so we can proceed with merging?

@arturovt
Copy link
Contributor Author

arturovt commented Jan 29, 2022

Hey @atscott . I’ll reopen the PR since I have another fork.

@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 Mar 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: review The PR is still awaiting reviews from at least one requested reviewer area: forms breaking changes cla: yes target: major This PR is targeted for the next major release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants