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

Add placeholder and pattern to daterange picker widget #32738

Merged
merged 8 commits into from
Mar 21, 2023
Merged

Conversation

esoergel
Copy link
Contributor

Product Description

Adds a placeholder text with the expected format to the date range widget:
image
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

  • This PR can be reverted after deploy with no further considerations

Labels & Review

  • Risk label is set correctly
  • The set of people pinged as reviewers is appropriate for the level of risk of the change

@esoergel esoergel added the product/feature-flag Change will only affect users who have a specific feature flag enabled label Mar 14, 2023
@esoergel esoergel requested a review from Jtang-1 March 14, 2023 14:56
@esoergel esoergel requested a review from orangejenny as a code owner March 14, 2023 14:56
@dimagimon dimagimon added the Risk: Medium Change affects files that have been flagged as medium risk. label Mar 14, 2023
@@ -370,6 +370,9 @@ hqDefine("cloudcare/js/formplayer/menus/views/query", function () {
autoUpdateInput: false,
"autoApply": true,
});
this.ui.dateRange.attr("placeholder", dateFormat + separator + dateFormat);
Copy link
Contributor

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);

Copy link
Contributor Author

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

Copy link
Contributor

@Jtang-1 Jtang-1 Mar 15, 2023

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)

Copy link
Contributor Author

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
@Jtang-1 Jtang-1 self-requested a review March 15, 2023 20:25
Copy link
Contributor

@Jtang-1 Jtang-1 left a 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);
Copy link
Contributor

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) {
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor Author

@esoergel esoergel Mar 16, 2023

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.

Copy link
Contributor

@Jtang-1 Jtang-1 Mar 16, 2023

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

totally agree

Copy link
Contributor

@Jtang-1 Jtang-1 left a 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!

@orangejenny
Copy link
Contributor

Is this going through QA?

@esoergel
Copy link
Contributor Author

@orangejenny yep, here: https://dimagi-dev.atlassian.net/browse/QA-4817

@esoergel esoergel merged commit 43c0bf1 into master Mar 21, 2023
@esoergel esoergel deleted the es/daterange branch March 21, 2023 16:46
@esoergel esoergel mentioned this pull request Jul 11, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
product/feature-flag Change will only affect users who have a specific feature flag enabled QA Passed Risk: Medium Change affects files that have been flagged as medium risk.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants