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(forms): handle numeric values properly in the validator #36157
Conversation
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.
This change is an improvement, generally, since it is always safer (and more performant) to compare against undefined
and I am happy for it to land.
But we should be aware, and encourage people (perhaps via documentation) not to use minlength
with number
fields, precisely for some of the reasons laid out in the comments for the original issue. Use cases where the string length of the number are important seem to me that they should really be considered strings that are restricted to certain patterns, which can be dealt with by the pattern
validator. For example a telephone number is not really a "number" in the HTML forms sense of the word. It is really a string of digits, which could be validated with something like Validators.pattern(/\d{9,11}/)
for example.
ebed1ab
to
83e15d8
Compare
0
properly in the validator83e15d8
to
5631a5c
Compare
@AndrewKushnir / @petebacondarwin Something is wrong with CI. It's failing with a 403 error. |
Not your fault @sonukapoor - the setup task makes requests to the Github API in order to check some stuff related to the current master commits, etc. Since this is done via the unauthenticated API, we occasionally overrun the number of allowed requests. I'll re-run the job and see if it gets through. |
23e9d3e
to
48aa5eb
Compare
8d1ed82
to
1cc99f2
Compare
d497cd8
to
3e12381
Compare
e377758
to
c165918
Compare
@AndrewKushnir Thanks, your version sounds good to me. I will update both, the commit and the PR description. |
55eb59e
to
0b6c43c
Compare
@AndrewKushnir Updated. |
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.
Thanks for updating breaking changes section Sonu! 👍
The changes LGTM, I just left a final comment on the tests, could you please have a look when you get a chance?
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.
Change LGTM, but can we update the first paragraph of the commit message to read:
Previously, the behavior of the `minLength` and `maxLength` validators
caused confusion, as they appeared to work with numeric values but
did not in fact produce consistent results. This commit fixes the issue
by skipping validation altogether when a numeric value is used.
@sonukapoor I'll start Global Presubmit tonight and if it goes well, we'll be able to add this PR to the merge queue. I noticed that it was rebased 25 days ago, so it'd be great to do one more rebase, so this PR is in the up-to-date state and we have a fresh CI run. Thank you. |
Previously, the behavior of the `minLength` and `maxLength` validators caused confusion, as they appeared to work with numeric values but did not in fact produce consistent results. This commit fixes the issue by skipping validation altogether when a numeric value is used. BREAKING CHANGES: * The `minLength` and `maxLength` validators now verify that a value has numeric `length` property and invoke validation only if that's the case. Previously, falsey values without the length property (such as `0` or `false` values) were triggering validation errors. If your code relies on the old behavior, you can include other validators such as [min][1] or [requiredTrue][2] to the list of validators for a particular field. [1]: https://angular.io/api/forms/Validators#min [2]: https://angular.io/api/forms/Validators#requiredTrue Closes angular#35591
c0a9220
to
28c5190
Compare
@kara I have changed the message. @AndrewKushnir All done and rebased. |
Thanks for the updates @sonukapoor 👍 FYI, presubmits went well, so I'm marking this PR as ready for merge. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…36157) Previously, the behavior of the `minLength` and `maxLength` validators caused confusion, as they appeared to work with numeric values but did not in fact produce consistent results. This commit fixes the issue by skipping validation altogether when a numeric value is used. BREAKING CHANGES: * The `minLength` and `maxLength` validators now verify that a value has numeric `length` property and invoke validation only if that's the case. Previously, falsey values without the length property (such as `0` or `false` values) were triggering validation errors. If your code relies on the old behavior, you can include other validators such as [min][1] or [requiredTrue][2] to the list of validators for a particular field. [1]: https://angular.io/api/forms/Validators#min [2]: https://angular.io/api/forms/Validators#requiredTrue Closes angular#35591 PR Close angular#36157
Previously, the behaviour of the
minLength
andmaxLength
validatorcaused confusion, and making it appear as they work with numeric values.
This commit fixes this, by always passing the validation when a numeric value
is used.
BREAKING CHANGES:
minLength
andmaxLength
validators now verify that a value hasnumeric
length
property and invoke validation only if that's the case.Previously, falsey values without the length property (such as
0
orfalse
values) were triggering validation errors. If your code relies onthe old behavior, you can include other validators such as min or
requiredTrue to the list of validators for a particular field.
Closes #35591
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #35591
What is the new behavior?
Does this PR introduce a breaking change?
Other information