-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Calendar control validity state #1676
Labels
Type: Enhancement
Issue contains an enhancement related to a specific component. Additional functionality has been add
Milestone
Comments
Check out our wrapper, which does support NG validation:
|
I created a pull request with the implementation of the NG_VALIDATORS within the calendar control itself. |
cagataycivici
added
the
Type: Enhancement
Issue contains an enhancement related to a specific component. Additional functionality has been add
label
Jan 18, 2017
cagataycivici
added a commit
that referenced
this issue
Jan 18, 2017
Fixing issue #1676 - Calendar control validity state
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Type: Enhancement
Issue contains an enhancement related to a specific component. Additional functionality has been add
Currently, when entering an invalid value into the control, the bound "value" is null, because it's not a valid date. (does not parse successfully)
The problem is that the invalid value is still visible to the user, which might be confusing.
This makes it impossible to hook in custom validation logic.
When we look at the value I don't know if the value is empty (to trigger the "required" validation) or if the value is invalid (when the control is not required in the form, but we want to prevent submission if the user entered invalid value)
One way of solving it might be to use the same logic that the autocomplete control has - expose a Date value if a valid date is selected or entered, or a string value otherwise.
Plunkr Case (Bug Reports)
Please fork the plunkr below and create a case demonstrating your bug report. Issues without a plunkr have much less possibility to be reviewed.
http://plnkr.co/edit/NtWWnN
Current behavior
Expected behavior
Minimal reproduction of the problem with instructions
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Language: [all | TypeScript X.X | ES6/7 | ES5]
Node (for AoT issues):
node --version
=The text was updated successfully, but these errors were encountered: