-
Notifications
You must be signed in to change notification settings - Fork 161
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(combo): update touched property and apply invalid color on blur when required - master #14922
Merged
kacheshmarova
merged 9 commits into
master
from
aahmedov/fix-touched-ivalid-color-not-applied-master
Oct 23, 2024
Merged
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
6bb2950
fix(combo): created a separate method for the validation logic
Zneeky 951e9bd
fix(combo): renamed function
Zneeky e53d267
fix(combo): test for clicking away when the combo is opened
Zneeky bb0651f
fix(combo): edited combo component test
Zneeky ec84ebb
fix(combo): onBlur and onFocus event handling this._onTouchedCallback();
Zneeky c954840
Merge branch 'master' into aahmedov/fix-touched-ivalid-color-not-appl…
Zneeky a0e31a7
fix(combo): edited onBlur to trigger touched only in a specific scenario
Zneeky 56c0876
Merge branch 'master' into aahmedov/fix-touched-ivalid-color-not-appl…
georgianastasov 63aed4a
Merge branch 'master' into aahmedov/fix-touched-ivalid-color-not-appl…
kacheshmarova File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@Zneeky @IvayloG @kacheshmarova @Lipata
I guess I'll be the bearer of bad news again, since this cannot be right :) The control cannot be in touched state on first focus, that will cause initially invalid fields to turn red on focus, which is not intended at all.
See https://angular.dev/api/forms/ControlValueAccessor#registerOnTouched
Or just the simplest of examples with the built-in
ngModel
and simple input where the touched state remains false until firstblur
:https://stackblitz.com/edit/d5xmg9?file=src%2Fmain.ts
PS: Oh wow, just realized that fix is based on a really old change in the Select and I do remember we had the ValueAccessor implemented wrong.. Hey it's even still in there 😁 That's wrong too lol
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.
The actual issue from what I can tell is touched isn't fired on blur when clicking outside - which is fair enough, and that's likely in the close handling - there's a distinction between closing with selection/KB, which restores the focus back to the input (thus focus as a whole has not yet left the component) and outside click which does mean the component is 'blurred' and should use the touched callback.
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.
See pretty similar handling in the Date Picker for example that does just that and the else case can be replicated for this fix:
igniteui-angular/projects/igniteui-angular/src/lib/date-picker/date-picker.component.ts
Lines 927 to 933 in d5df92a
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.
@damyanpetev @Lipata
Adding some more details:
The control cannot be in a touched state on the first focus, that will cause initially invalid fields to turn red on focus, which is not intended at all.
I was thinking the same, yet after the currently implemented fix the red color is updated on the outside click as it should.
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.
Possibly, because the error color is applied either if the underlying form control changes state (but it's invalid to begin with) or the check we evaluate on blur. Perhaps wasn't the best example, I suppose a better one would be if you have error message based on
model.error.required && model.touched
it should be visible before that :)On second thought, I believe this will also mess with the
updateOn: 'blur'
on form controls since that relies on the touched callback to initiate the value update. I think we had a bunch of issues for that some time ago that showed us we weren't implementing the value accessor right and I thought we hunted those down across all components.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.
Oh more fun, the combo had the same fix as the select... except we reverted that one quick enough lol 😁
See #8123
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.
@damyanpetev @IvayloG
I've created a new PR to address the issues that this PR introduced, and I'd appreciate your feedback on the proposed solution.
In the new PR I've made a change to the
handleClosing
event:I've added an else if condition to check if the currently active element is not
this.comboInput
. Initially, I expected this to work with a simple else, but the touched and validation were still somehow being updated unnecessarily. This extra check for the active element seems to prevent those unnecessary updates effectively.I am sticking to what's written in the Angular's docs =>
When the user blurs the form control element, the control is marked as "touched"
.Let me know if you have any suggestions or concerns about this approach!