[DatePicker] Port component

[nathanmarks]

• Component
• Tests (at least unit tests)
• Docs
• Demo
• Keyboard accesibility [DatePicker] Use keyboard to write date mui-x#6232
• Composable, so users can build something like [DatePicker] Include range selector #7574 for instance
• Fixes old issues [DataPicker] FlatButton hover color change. #7866, [DatePicker] DatePicker and TimePicker render differently #7783, [DatePicker] Popover appears on top left #7781, DatePicker localized in French encounters some issues between 1944 and 1981 #7767, Date picker dosn't working well in iPhone 6/6s Plus from 0.15.0 #6970, [DatePicker] onBlur event sent at the start of interaction (rather than at the end) #6944, [DatePicker] Please add optional week numbers to datepicker #6918, [DatePicker] Dates flickering on fast hover in Chrome #6916, [DatePicker] Callback event(s) for switching month / year #6886, [DatePicker] Add custom action buttons #6718, [DayButton] when disabled will not update hover state #6594, [DatePicker] Inconsistent event implementation #6439, [DatePicker] minDate/maxDate bug #6358, [DatePicker] Please enable month selection #6312, Focus *picker inputs on tap #6134, [DatePicker] doesn't capture tabs correctly #5897, [DatePicker] Select multiple dates option? #5800, [DatePicker] Preserve time component of Date #5743, [DatePicker] Is the DatePicker timezone aware? #5726, [DatePicker] Can't reset date #5696, [DatePicker] should integrate date input #5664, [DatePicker] material-ui  #5633, [DatePicker] Missing/duplicate days #5400, [DatePicker] Provide ability to add css className to DatePicker Dialog for Selenium WebDriver Testing #5329, [DatePicker] Touch working rarely on mobiles #5198, [DatePicker] Selecting a year does not trigger validation #5197, [DatePicker] Can't resize to fit smaller devices #5188, [DatePicker/Calendar] Feature Request: Default "firstDayOfWeek" prop for Calendar component #5037, [DatePicker] Enabling setting a month/date that the picker opens on #4900, [DatePicker] should have css class for weekend days and header to style them separate #4765, [DatePicker] Setting to a default state as a controlled component #4707, [DatePicker][TimePicker] exposing the api for TimePickerDialog and DatePickerDialog #4587, [DatePicker] add prop: openImmediately={true} #4401, [DatePicker] Inline mode has multiple positioning and transition placement/direction issues #4219, [DatePicker] Add possibility to customize particular days #3794, [Docs] Calendar Component (date-picker) #3710, [DatePicker] possible enhancements #2930, [DatePicker] Support tabbing through a DatePicker field #2203, [DatePicker] test fails for the 31 of October #2023, [Datepicker] Allow selecting a date range #1566, [DatePicker][TimePicker] are unusable on iPhone5/s #1261, [Datepicker] Allowed to select dates which are disabled using shouldDisableDate prop #1207, [DatePicker][TimePicker] Does not correctly accept UTC Dates. #4538, [DatePicker] Inline dialog doesn't (re)appear on Android (Chrome) #5144, [DatePicker] October turns into September for some years when localized #7399, [DatePicker] keyboard accessibility #5612

[sairamdevarashetty]

@oliviertassinari I would like to know any plans on implementing this component in the new version .I would like to help .Please let me know .Thanks

[oliviertassinari]

The best way to start a migration of a component is to look at the opened issues. That gives a better understanding of the limitations the current implementation has. I have removed the DatePicker and TimePicker from the v1 release milestone so we can make it happen sooner. Still, your help is welcomed.

Some thoughs one the component:

• It's very challenging as if we are providing a poor UX, people would be better of relying on the native pickers of the platform
• Date manipulation can be complexe. Let's see if we can take advantage of another lib.
• Desktop UX is poor, we need to rethink it.
• It's missing composition power. We need to expose lower-level APIs

[GabeDuarteM]

Just leaving my opinion regarding the importance of the datepicker (and timepicker), i think there are 3 major components that define if your're dealing with a good ui framework or not, and they are: Autocomplete, Datatables and Datepickers.

I've tried lots of different frameworks, and those three components are the ones that gives me most headaches, mostly because of their poor implementation and internationalization options, async capacities and pagination, to name a few of the problems.

So, to keep things short: I rather prefer that the these three components arrive in their full state, but keep i'm mind too that, at least in my opinion, there will be a lot of people that will not choose a ui framework that lacks some of those components.

Anyway, MUI v1 looks very promising, i'm looking forward to try it when its fully released!

[oliviertassinari]

I rather prefer that the these three components arrive in their full state

@GabrielDuarteM I agree, the DatePicker and TimePicker implementation need to be as good as the native one in order to compete. Otherwise, it's pointless. Right now, I would not use the v0.x pickers on a production ready app. I would rather use the pickers of the platform.
We will most likely release v1.0.0 without those components, I don't think that they are crucial, native pickers have improved a lot over the years.

Regarding the Autocomplete, you can find an example here.

[skirunman]

We make extensive use of MUI timepicker and datepicker in our production app today so unfortunately won't be able to migrate to v1.0.0 without a Material Design based solution. Using native time/date pickers is not a good solution and I disagree that they are not "crucial" to having a good and complete Material Design React component UI package.

[mauriciojovel]

I agree with @skirunman, the DatePicker and TimePicker are very important in the production apps, also the native implementation in the most browser are very limitated, for example in chrome for android you can't choose the month and the year and I think that part is crucial when the user want choose for example the birthday.

[skirunman]

Let me add more details on my opinions:

It's very challenging as if we are providing a poor UX, people would be better of relying on the native pickers of the platform

Disagree strongly. Native pickers are generally limited in capabilities and certainly don't fit in with Material Design.

Date manipulation can be complexe. Let's see if we can take advantage of another lib.

I think punting on implementing a Material Design based time and date picker will leave quite a few current users out in the cold. Using another library for what is currently, and really should be, a core component of MUI, weakens the overall appeal of MUI.

Desktop UX is poor, we need to rethink it.

Not sure why you say this as long as it follows Material Design Guidelines.

It's missing composition power. We need to expose lower-level APIs

This is a nice to have, but not a requirement for v1.0.0 IMO.

[oliviertassinari]

@skirunman We agree, we need that component. What is at stake here is regarding the timing priority. We think that there is more value to get from releasing v1 first and implementation the DatePicker/TimePicker later. (people can always use the master version).
It also comes down from the need of the core contributors. For instance, I might never work on it as it's not something I need.

That's without to say that if a contributor has a ✨ implementation of the component, we will definitely review it and merge once we are all happy with it :).

[techniq]

I've only recently begun looking at react-infinite-calendar, but it might be a worthwhile replacement to the v0 calendar for some. It does work differently by being scrollable between months instead of explicit month stepping, but it has some additional requested features such as range selection (requested via #7574) and looks to be pretty composable (at first blush)

[dmtrKovalenko]

@taoxueweilong Please write an issue here. Here is not better place to give an advices :)

[chingyawhao]

Hello fellow developers...
I have an implementation of datepicker using Material UI here
https://github.com/chingyawhao/material-ui-next-datepicker

I think I might be available to contribute to Material UI if anyone can guild me how to get started

[github-herve-bourzeix]

awesome!

…

On Wed, May 2, 2018 at 11:13 AM, Ching Yaw Hao ***@***.***> wrote: Hello fellow developers... I have an implementation of datepicker using Material UI here https://github.com/chingyawhao/material-ui-next-datepicker I think I might be available to contribute to Material UI if anyone can guild me how to get started — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4787 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AacMkVQOH0GRO7JsIyggzHidwmypEPdHks5tuXjQgaJpZM4JSThr> .

[mbrookes]

@chingyawhao The contributing guide is mostly complete, but new components now go in packages/material-ui-lab. I will defer to @oliviertassinari as to whether this is a suitable candidate.

[chingyawhao]

@mbrookes I ll attempt to make a pull request to material-ui-lab in the weekend

[oliviertassinari]

@chingyawhao Thanks for sharing the project. I believe the best step, for now, is to document it alongside the alternatives in the documentation.
There is already a lot of work to do in the other area of the library. I do think that the date picker is a complexe component to get right. For instance, have a look at all the isuses of bootstrap-datepicker. From a strategic point of view, I think that the longer we can defer this component to the community, the better. From the download stats, we can estimate that ~13% of the people needs a date picker, a time picker or somethings in between. It might be better to focus on the 87% others.

[chingyawhao]

@oliviertassinari got it...
Can you notify me when you are ready to start developing, maybe I can help?

[stunaz]

@chingyawhao what don't you team up with @dmtrKovalenko on https://github.com/dmtrKovalenko/material-ui-pickers, I am sure there are plenty room of improvement

[up-to-you]

@stunaz I think they have different views on look and feel, however, obviously https://github.com/dmtrKovalenko/material-ui-pickers is much better fits overall design of current material-ui-next, as well as UX point.

[chingyawhao]

@up-to-you my final objective is to follow material-design's depiction of pickers in text fields in desktop. Those pickers are in popovers instead of dialog.

The project that I was working on requires a more customized component of datepicker which does not limit the user to select date from picker, user can also type in the date in a masked text input.

My project will allow that level of customization, you can import only the calendar component out which is the picker without the input or the containing dialog or popover.

import {Calendar, Clock} from 'material-ui-next-pickers'

And by the way, I released the timepicker too XD

[techniq]

@chingyawhao is it possible to trigger the popover via an IconButton (ala via an adornment). I have my own masked inputs but would like to be able to popup a date picker on button press.

[chingyawhao]

@techniq yup, certainly...that sounds similar to what I've done in my project
If you need any example, create an issue in my repo

[Raemon]

FYI, my current issue is that there isn't a good solution for datetime-local, since Firefox doesn't support it natively. Upon switching to material 1.0 we found that firefox users just couldn't use our datetime fields.

It looks like most of the discussion above is about nice implementation of date or time, but neither of those address the issue of datetime working at all.

[IssueHuntBot]

@rogerstorm funded this issue with $120. See it on IssueHunt

[jasonkylefrank]

Hello!

Can we get an update on the state of the DataPicker progress?

It's getting difficult to assess this in these long threads.

And it seems that @dmtrKovalenko has been steadily committing to Material-UI-Pickers for a while.

To be specific:

1. The original issue listed checkbox items and none of them have been checked off. Is that accurate?
   
   
   It seems like @dmtrKovalenko has tests, documentation, demos, etc. Maybe he doesn't have everything done, but is it accurate to say that nothing can be checked off at this point?

2. I'd love to hear from @dmtrKovalenko on this issue. Have you been in discussions with the Material UI team about bringing your material-ui-picker into the fold?

[mbrookes]

@jasonkylefrank Nothing is ticked off because nothing has been done in the official repository, and, to be fair, is unlikely to be any time soon. (We were only this week discussing closing all the datepicker / timepicker issues in deference to 3rd party solutions.)

@dmtrKovalenko Has done an excellent job, and no reason not to use his components even though they are not "official".

[oliviertassinari]

We don't plan any work on the DatePicker and TimePicker components.
I think that we should defer it to the community. @dmtrKovalenko has been killing it!
We need to update the documentation to refect this position, so we can close the issue.

[dmtrKovalenko]

@rogerstorm if issue is resolved by material-ui-pickers can I get my $120 from IssueHunt? 🤣

[mbrookes]

I know you were half joking, but: cc @rogerstorm