Replace react-datetime with react-day-picker

[majakomel]

Closes #689

I only replaced the date picker on/search page and would be happy to hear feedback before applying changes to the other forms.

I decided to use react-day-picker because it's very customizable and it doesn't depend on any date library.

After the changes are applied to other forms as well, moment.js can be safely removed from the project.

[vercel]

@majakomel is attempting to deploy a commit to the OONI Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/ooni/explorer/BPDpq19254HvPwHfNfUNHZ5uUCjg
✅ Preview: https://explorer-git-fork-majakomel-new-date-range-picker-ooni1.vercel.app

[sarathms]

@majakomel Thanks for rewriting the date picker. Important change.

I haven't finished reviewing everything. However, I thought I should share some early feedback for us to discuss.

1. Looks like a new major version (v8) of react-day-picker was released recently. And the documentation for v7 says that it won't be maintained anymore. I wonder if it is better we start out with v8 which seems to have some useful improvements over v7 like reduced size, tree-shaking, hooks API
2. It does depend on the date library date-fns because it is a peerDependency. This makes the use of dayjs as replacement (Replace momentjs with dayjs where possible #699) for moment a bit redundant. If we go ahead with react-day-picker, we might as well just use date-fns as the replacement for momentjs. It seems to be a well written library, except that it is not a drop-in replacement for moment. @hellais what do you say?
3. There seem to be merge conflicts after Replace momentjs with dayjs where possible #699 was merged because this PR also adds a different version of dayjs. This might need a fresh rebase for this branch.

Looking at the implementation, I feel it might benefit from the hooks-based API of react-day-picker@8.0.0

• We can possibly avoid using the FormProvider and useFormContext route of implementing the search form
• Based on above point, the DateRangePicker component can be implemented independent of the react-hook-form library which allows us to use it flexibly in other places if needed.

[majakomel]

@sarathms Thanks for checking the PR and for the tips for improvements!

I was so consumed with trying to find a nice date picker alternative, that I completely missed the newer version. Just saw v8 was released 3 days ago.
I agree that going with v8 makes much more sense, just a bit of a bummer this one is dependent on date-fns. Otherwise, I really like the documentation (at least for previous version) and flexibility it offers.

I'll first upgrade the react-day-picker, after that, I'll try to find an elegant solution to deal with UTC dates (day.js/moment.js offer a nicer way to do it than date-fns), in order not to carry two different date libraries.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
explorer	✅ Ready (Inspect)	Visit Preview	May 30, 2022 at 2:57PM (UTC)

[hellais]

This looks good to me!

I would suggest a small improvement to the styling of the date selector, by adding a 2px top & bottom padding to the cells so that it looks something like this:

[majakomel]

@hellais I have added the styling change.
The only thing here in order to get completely rid of react-datetime component is to figure out what to do with /experimental/website, which is already a bit broken. Is this something we want to maintain?

[hellais]

I have added the styling change.

The styling looks good.

The only thing here in order to get completely rid of react-datetime component is to figure out what to do with /experimental/website, which is already a bit broken. Is this something we want to maintain?

I think we can drop everything in that tree entirely. It's work that was started on creating the website centric pages, but we since then decided to go in a different direction, so it's mostly dead code.

I suggest we just drop it all.

[hellais]

LGTM!

We can drop /experimental/websites either as part of this PR or future work.