Date picker #1340
Date picker #1340
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
|
This looks great and we desperately need it. Bundle sizeBundle size addition is 163 kB / 53 kB gzipped. It's not that much and I don't really see any way around it besides spending time we definitely don't have writing our own 2000 line implementation of date range state. We can always split the pages out like we're doing with Recharts and xterm.js, but honestly even that is of dubious value. The second it causes me some inconvenience I will stop bothering to do it. Before
After
|
|
|
||
| export function Calendar(props: CalendarProps<DateValue>) { | ||
| const { locale } = useLocale() | ||
| const state = useCalendarState({ |
There was a problem hiding this comment.
Look at the source of useCalendarState lmao. This is why we're using a library.
There was a problem hiding this comment.
Dang lol. Yes, I'm glad we don't have to write that.
| {children} | ||
| </div> | ||
| ) | ||
| } |
There was a problem hiding this comment.
I think you've mentioned this before, but we can almost certainly replace Reach Dialog with this.
There was a problem hiding this comment.
Yep — goes beyond the scope of this PR but worth discussing a replacement to Reach Dialog at some point now that the library is no longer maintained.
|
For the record, I tried converting the diff --git a/package.json b/package.json
index 22fedbed..9ac3f13b 100644
--- a/package.json
+++ b/package.json
@@ -36,6 +36,13 @@
"@reach/dialog": "^0.16.2",
"@reach/menu-button": "^0.16.2",
"@reach/tabs": "^0.16.4",
+ "@react-aria/button": "^3.6.4",
+ "@react-aria/calendar": "^3.0.5",
+ "@react-aria/datepicker": "^3.2.1",
+ "@react-aria/dialog": "^3.4.2",
+ "@react-aria/focus": "^3.10.1",
+ "@react-aria/i18n": "^3.6.3",
+ "@react-aria/overlays": "^3.12.1",
"@react-spring/web": "^9.5.5",
"@tanstack/react-query": "^4.12.0",
"@tanstack/react-query-devtools": "^4.12.0",
@@ -49,7 +56,6 @@
"mousetrap": "^1.6.5",
"prop-types": "^15.7.2",
"react": "^17.0.2",
- "react-aria": "^3.22.0",
"react-dom": "^17.0.2",
"react-error-boundary": "^3.1.3",
"react-hook-form": "^7.38.0", |
|
Here's what I did:
|
|
Haha hell yeah. CI server is of course in UTC. I thought hard coding Chicago in the tests would work, but I forgot there are parts where we pull the local time from the browser. Will fix.
|
david-crespo
force-pushed
the
date-picker
branch
from
2ce67cb to
9355e1b
Compare
|
Here's a better summary of what's in place. I think it's better than what we have, so I'm ready to merge. Some issues:
|
| }) | ||
|
|
||
| describe('custom mode', () => { | ||
| describe.skip('custom mode', () => { |
There was a problem hiding this comment.
Couldn't get any of this shit to work because getting the displayed date in what used to be a simple <input> is very unsimple now. A lot of this is due to quirks in jsdom. This is one of very few things we're still testing with Testing Library instead of Playwright. I'm inclined to convert these to Playwright, but that can be a followup.
I think a few of these issues will be resolved with the larger calendar element, since it has the relative times integrated directly in the calendar. Apply wont be necessary outside of that element because we can apply the input on blur (of the overall input not the individual segments). And by including "Today" in the list of relative time ranges we will no longer need clear. IMO we move time zone from the inline input but show it in the calendar when opened otherwise it's a million miles long. I can come back with a PR later, but more than good enough for now. Thanks for getting that integrated! |
Closes #1132
Closes #1046
First pass at a date picker.
This does not include the quick actions that let you choose a relative time ago, or the multi-month range, though this does not seem complicated to add. Time zone selection could be added on the larger multi-month modal.
Error handling still needs work, and I'm running into some unusual behaviour when the calendar modal closes where it is inconsistent with the element that it focuses on.
This PR is using the
react-ariaoverlay and dialog also. I did not convert it toreach-uinow that it is no longer maintained.This was a bit of an experiment, but I'd say the
react-ariadate picker hooks is a good approach. We could for sure get something simpler, a drop-in component, but would be sacrificing a lot of control both on styling and functionality.