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

bug(forms): Date range picker incorrectly has matStartDateInvalid error after hiding component #39590

Closed
blyndcide opened this issue Nov 6, 2020 · 3 comments
Labels
area: forms forms: validators P2 The issue is important to a large percentage of users, with a workaround state: has PR
Milestone

Comments

@blyndcide
Copy link

Reproduction

Use StackBlitz to reproduce your issue: https://stackblitz.com/edit/angular-uotl3m?file=src%2Fapp%2Fdate-range-picker-forms-example.html

Steps to reproduce:

  1. Pick a date range in date picker.
  2. Hide then show the date range picker with the toggle button.
  3. Pick the date range again at a date later then the previous range.

Expected Behavior

What behavior were you expecting to see?
I do not expect to see a start date error.

Actual Behavior

What behavior did you actually see?
I see a start date error.

Environment

  • Angular: 10.2.7
  • CDK/Material: 10
  • Browser(s): Edgeium
  • Operating System (e.g. Windows, macOS, Ubuntu): windows 10

Seems this is linked to #39235 . Want to make sure there is a specific simple example here to test against.

@blyndcide blyndcide changed the title fix(forms): Date range picker incorrectly has matStartDateInvalid error after hiding component bug(forms): Date range picker incorrectly has matStartDateInvalid error after hiding component Nov 6, 2020
@AndrewKushnir AndrewKushnir added area: forms forms: validators P2 The issue is important to a large percentage of users, with a workaround labels Nov 6, 2020
@ngbot ngbot bot modified the milestone: Backlog Nov 6, 2020
@AndrewKushnir
Copy link
Contributor

Hi @blyndcide,

Thanks for reporting the issue and providing a repro.

I've tested the behavior with the changes from PR #39235 that improves internal cleanup logic in Forms package (to also cleaning up validator functions from destroyed components) and everything seems to be working fine. You can also test the behavior locally by using Forms package with the fix from #39235 as described here. Note: the package from the #39235 is not suitable for production use and it will be removed within a couple weeks.

Please let us know if the changes from #39235 resolve the problem on your app.

Thank you.

AndrewKushnir added a commit to AndrewKushnir/angular that referenced this issue Dec 7, 2020
…responding directive instances

Prior to this commit, removing `FormControlDirective` and `FormGroupName` directive instances didn't clear
the callbacks previously registered on FromControl/FormGroup class instances. As a result, these callbacks
were executed even after `FormControlDirective` and `FormGroupName` directive instances were destroyed. That was
also causing memory leaks since these callbacks also retained references to DOM elements.

This commit updates the cleanup logic to take care of properly detaching FormControl/FormGroup/FormArray instances
from the view by removing view-specific callback at destroy time.

Closes angular#20007, angular#37431, angular#39590.
AndrewKushnir added a commit to AndrewKushnir/angular that referenced this issue Jan 4, 2021
…responding directive instances

Prior to this commit, removing `FormControlDirective` and `FormGroupName` directive instances didn't clear
the callbacks previously registered on FromControl/FormGroup class instances. As a result, these callbacks
were executed even after `FormControlDirective` and `FormGroupName` directive instances were destroyed. That was
also causing memory leaks since these callbacks also retained references to DOM elements.

This commit updates the cleanup logic to take care of properly detaching FormControl/FormGroup/FormArray instances
from the view by removing view-specific callback at destroy time.

Closes angular#20007, angular#37431, angular#39590.
josephperrott pushed a commit that referenced this issue Jan 5, 2021
…responding directive instances (#39235)

Prior to this commit, removing `FormControlDirective` and `FormGroupName` directive instances didn't clear
the callbacks previously registered on FromControl/FormGroup class instances. As a result, these callbacks
were executed even after `FormControlDirective` and `FormGroupName` directive instances were destroyed. That was
also causing memory leaks since these callbacks also retained references to DOM elements.

This commit updates the cleanup logic to take care of properly detaching FormControl/FormGroup/FormArray instances
from the view by removing view-specific callback at destroy time.

Closes #20007, #37431, #39590.

PR Close #39235
@AndrewKushnir
Copy link
Contributor

Quick update: the fix (PR #39235) was merged and should be available in v11.1.0 release later this month.

@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 Feb 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: forms forms: validators P2 The issue is important to a large percentage of users, with a workaround state: has PR
Projects
None yet
Development

No branches or pull requests

2 participants