Audit Log Date Range Picker update

[robertandremitchell]

PULL REQUEST

Summary

This initializes a DateRangePicker component in line with the frontend guidance:

It also adds tests of date range to AuditLog to ensure functionality.

This moves the DateRangePicker logic out of AuditLog and establishes what could be the prototype for timeboxing, since that will need a date range picker in addition to the other components: https://www.figma.com/design/Iuw9me6kYftBF4WTCEsCZz/Query-Connector?node-id=1757-1955&p=f&m=dev.

However, per discussions with @mikang we should avoid full implementation since this more simplified date range is all that is needed for MVP.

Related Issue

Fixes #441

Additional Information

Anything else the review team should know?

The only edit I made to the design was the inclusion of a Clear button. I found that when playing around with dates that there was not a clear way to reset the dates without refreshing. This is because I have the textbox set to readOnly so that users can only implement date ranges via the picker and not trying to type in two dates.

The other thing is that I have currently commented out the onClick logic that opens the calendars on click. I had trouble getting the tests to "ignore" that logic to type dates. Further, having the calendar open automatically does seem to go against accessibility guidance, which states:

Always allow a user to type in the date manually. Usability testing suggests some people prefer manually typing the date rather than using the calendar picker. Whenever possible, keep the keyboard active so people can enter in the date information without having to use the picker.

So, I'm curious if we want to add that back in. If so, I will need to figure out the best way to get tests to work with that logic (the rabbit hole went deep...).

Checklist

• Descriptive Pull Request title
• Link to relevant issues
• Provide necessary context for design reviewers
• Ensure test coverage is above agreed upon threshold
• Update documentation

[github-actions]

Coverage report for ./query-connector

St.❔	Category	Percentage	Covered / Total
🟡	Statements	60.7% (+1.29% 🔼)	1798/2962
🔴	Branches	51.87% (+2.62% 🔼)	540/1041
🟡	Functions	64.03% (+1.18% 🔼)	372/581
🟡	Lines	60.62% (+1.28% 🔼)	1695/2796

Show new covered files 🐣

St.❔	File	Statements	Branches	Functions	Lines
🟢	... / DateRangePicker.tsx	98.82%	92.31%	100%	98.73%

Test suite run success

162 tests passing in 20 suites.

Report generated by 🧪jest coverage report action from 9d85ffc

[fzhao99]

great work on this Rob! left a couple nits, but nothing blocking

[mikang]

This looks great!!! Thanks, @robertandremitchell !

[mikang]

Looks great!!

[katyasoup]

Looks great! There are a couple validation things I noticed that shouldn't be blockers, but maybe we'd want to make a new ticket for/ follow-up on:

• seems to trigger early, ex. enter a start date, then any text in end date triggers warnings until the full date is typed out. Maybe an "Apply" button or similar would solve?

• Invalid format warning shows but filtering works as expected underneath: (enter 3/1/24 for start in this ex - year is corrected to YYYY format but month/day stays single digit and proper filtering is applied to results):

[robertandremitchell]

Looks great! There are a couple validation things I noticed that shouldn't be blockers, but maybe we'd want to make a new ticket for/ follow-up on:

• seems to trigger early, ex. enter a start date, then any text in end date triggers warnings until the full date is typed out. Maybe an "Apply" button or similar would solve?

• Invalid format warning shows but filtering works as expected underneath: (enter 3/1/24 for start in this ex - year is corrected to YYYY format but month/day stays single digit and proper filtering is applied to results):

Looks great! There are a couple validation things I noticed that shouldn't be blockers, but maybe we'd want to make a new ticket for/ follow-up on:

• seems to trigger early, ex. enter a start date, then any text in end date triggers warnings until the full date is typed out. Maybe an "Apply" button or similar would solve?

• Invalid format warning shows but filtering works as expected underneath: (enter 3/1/24 for start in this ex - year is corrected to YYYY format but month/day stays single digit and proper filtering is applied to results):

Looks great! There are a couple validation things I noticed that shouldn't be blockers, but maybe we'd want to make a new ticket for/ follow-up on:

• seems to trigger early, ex. enter a start date, then any text in end date triggers warnings until the full date is typed out. Maybe an "Apply" button or similar would solve?

• Invalid format warning shows but filtering works as expected underneath: (enter 3/1/24 for start in this ex - year is corrected to YYYY format but month/day stays single digit and proper filtering is applied to results):

No dice fixing locally yesterday, unfortunately :/ . I'm sure there is a way to handle date error handling more gracefully, but the main thing I ran into was the balance between having a permissive date values (YYYY.MM.DD, MM/DD/YYYY, MM-DD-YY, etc.) but still triggering the errors when they became valid. We could try to enforce MM/DD/YYYY as the only datetype we support, but it does feel a little restrictive, even if our error messaging then recommends they use that format.

Made a follow-up ticket to investigate for the sake of merging this since date range picker works: https://linear.app/skylight-cdc/issue/QUE-223/update-date-range-error-handling.