-
-
Notifications
You must be signed in to change notification settings - Fork 218
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
Add placeholder and pattern to daterange picker widget #32738
Conversation
@@ -370,6 +370,9 @@ hqDefine("cloudcare/js/formplayer/menus/views/query", function () { | |||
autoUpdateInput: false, | |||
"autoApply": true, | |||
}); | |||
this.ui.dateRange.attr("placeholder", dateFormat + separator + dateFormat); |
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.
I think we should redefine dateFormats
to prioritize dateFormat
in the list of allowable formats if dateFormat
is the recommended input pattern.
This is because we parse the input of dateRange
using dateFormats
as order of priority input formats. parts = _.map(oldValue.split(separator), function (v) { return moment(v, dateFormats);
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.
Fair point, just updated it. I'd also forgotten about that part that parses input formats for the date range picker. This means we can consistently apply the input parsing to both widgets! Working on that now
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.
Good catch, that's a win for consistent date picker behavior!
I thought you were running into issues previously with using strict mode on date range picker based on this comment. But I now realize I think you were looking at something else #32628 (comment)
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.
I was, because I was trying to do it in the library (as the single date picker does with parseInputDate
). Turns out we already interpret the dates in the date range picker in this code though, so i can just jump in there. I did a bunch more fiddling to unify input processing. I still need to do more testing, but let me know what you think.
Dates aren't moment objects, so the first part of the conditional would be hit anyways. Besides, I don't this happens, since convertTwoDigitYear would fail hard on a Date input if one were passed in
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.
defining input parsing in one spot makes a lot of sense and great change
} | ||
newValue = start.format(dateFormat) + separator + end.format(dateFormat); |
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.
nice clean up
var dateFormats = ['MM/DD/YYYY', 'YYYY-MM-DD', 'M/D/YYYY', 'M/D/YY', 'M-D-YYYY', 'M-D-YY', moment.defaultFormat]; | ||
|
||
/** Coerce an input date string to a moment object */ | ||
var parseInputDate = function (dateString) { |
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.
I feel like something weird happens if the dateString input is YYYY-MM-DD
since convertTwoDigitYear
will try to convert the DD into four digits. But the unit test seems to pass and i can't figure out why
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.
Ah, no issue here. YYYY-MM-DD
won't be converted because convertTwoDigitYear
checks if dateString
has <= 6 digits before converting
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.
Nice, yeah that makes sense - it might even be reasonable to switch to a more strict pattern like regex matching ^\d{1,2}[.-/]\d{1,2}[.-/]\d{1,2}$
. Hell, I wonder if temporarily patching moment.parseTwoDigitYear
might be an option if we did something like:
oldParseTwoDigitYear = moment.parseTwoDigitYear;
moment.parseTwoDigitYear = function () {...};
userDate = moment(dateString, ...);
moment.parseTwoDigitYear = oldParseTwoDigitYear;
Anyways, I think iterating via unit tests is probably our best bet here, especially given that part of this is controlled somewhat opaquely by a library. Once I switched to that approach, I felt a lot more confident in this code. Honestly I should've done it much sooner, but I guess I'm just not used to that in javascript.
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.
I'm not a huge fan of how convertTwoDigitYear
requires the argument to follow some pattern/format. I'm thinking if the argument should be be just the YearString but that'll make the caller complicated. Patching seems interesting but not sure if that's a hacky solution. So not sure what a better would be.
Agreed about the tests, great addition
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.
totally agree
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.
Pulled the change in locally and tested some cases. Didn't see any issues!
Is this going through QA? |
Product Description
Adds a placeholder text with the expected format to the date range widget:
It also adds loose validation so things like "Jan 1, 2022" will show up red when the user starts typing them
Technical Summary
https://dimagi-dev.atlassian.net/browse/QA-4867
Feature Flag
Case Search: Enable synchronous mobile searching and case claiming
Safety Assurance
Safety story
Automated test coverage
n/a
QA Plan
Grew out of QA on #32628
https://dimagi-dev.atlassian.net/browse/QA-4867
Rollback instructions
Labels & Review