Material-ui: [DatePicker] Port component

@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

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

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, Datatablesand 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!

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.

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.

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.

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.

@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 :).

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 https://github.com/callemall/material-ui/issues/7574) and looks to be pretty composable (at first blush)

Is there any plans for this issue to move forward?

@DoWhileGeek The most recent plan I had was adding a new page in the docs with:

<input type="datetime-local" name="bdaytime">
<input type="date" name="bday" max="1979-12-31">
<input type="time" name="usr_time">

examples like.

@oliviertassinari I'm specifically looking for resolution on #7781, its a bit of a dealbreaker for our ux guys.

@DoWhileGeek you are free to PR a solution to #7781 for the 0.x branch; the core team is focused on a 1.0 release. That is why all of those issues have been closed.

+1 We are really interested in native v1 picker. Please let us know if you are working on that now
P.S. We are excited about material ui v1

I am locking this issue to prevent further +1 type comments.

This notice already appears in the Pickers docs:

Notice
We are currently falling back to native input controls. If you are interested in implementing or have implemented a rich Material Design Picker with an awesome UX, please, let us know on #4787 and #4796! We could add a link to or a demo of your project in the documentation.

As discussed here, the plan is to fall back to native controls in the Pickers component demo and to promote an external project that is willing to take on the _dedicated_ task of the Datepicker, Timepicker or both.

If you are interested in taking on the pickers as an outside project, many people want to see that succeed, so please share that with us and we will:

• link prominently to your project
• provide a demo within the material-ui docs
• point collaborators in your direction.

Given the popularity of material-ui and the demand for these pickers, a pickers project owner is likely to receive all the internet fame and glory that goes along with a popular project.

Interested? Please ping @rosskevin and @oliviertassinari on gitter.

@rosskevin @oliviertassinari I'm currently working on the TimePicker and hope to have a first working version (maybe still missing some animations or the landscape mode) available this weekend. :rainbow:

Once most of the time picker is done, I'll start with the DatePicker.

@leMaik I just noticed this project https://github.com/dmtrKovalenko/material-ui-pickers by @dmtrKovalenko

Perhaps you two could discuss joining projects? I have not dug in to find differences, but it might be worth consideration.

Also note that we have recently transitioned to a github organization mui-org. If you two decide you want to join up and host the project under the mui-org please let us know.

@rosskevin
Seems that it would be a lot more complex to join projects. Because we have used moment as peer dependency and implement a lot controls to display dates (such as datetime picker), instead of our @leMaik`s projects is much lightweight solution to display time pickers :smile:
What about moving to org, I'm not against, but actually cannot fully understand what it means? Just moving repository under the org?

Regarding the org: yes - it would just to be moving it under the org and perhaps the popularity of material-ui itself might give it more exposure (and more maintainers). But it's just a thought, no reason it needs to be there, just that we are now opening the doors to complementary projects under the org.

@rosskevin @dmtrKovalenko I wouldn't like to _merge_ the projects as they take a pretty different approach (we do one project with one component that does one thing only). Maybe we could transform material-ui-pickers into a Date picker only (and build on that great foundation, adding animations and everything) and keep our time picker as time picker and move both under the org? :thinking:

@leMaik
Regarding the redoing to just date - i think no, because for some projects would be much helpful to have general approach to work with dates, material-ui-pickers provide all components for that. Date-time picker as well, that is not lised in the material-design specefication. 😉

It's good to implement like https://material.angular.io/components/datepicker/overview

Found a good and flexible datepicker library:
https://github.com/gpbl/react-day-picker

Managed to create a ranged datepicker using material-ui textinputs:

@saraivinha85 Sweet! 🍬

Would you be willing to share your implmentation for others to learn from? (Even just a gist would be great!)

@mbrookes No problem:
https://codesandbox.io/s/9l7kry52or

This project for time picker is good https://github.com/TeamWertarbyte/material-ui-time-picker

Hi. As the component is pretty important and we already use the next version, have to ask is there an estimation on this, or maybe a way to help?

Checked other DatePickers, doesn't really work good enough with any, so bundled one should be the best solution (especially to work with redux-form or redux-form-material-ui@next which we do use as well).

For now, it seems like the best solution is to use https://github.com/dmtrKovalenko/material-ui-pickers. I am using it with formik.

Thanks, will try it out. Is a date picker as modal a requirement of Material Design?

An implementation of something similar to the material influenced date picker and date range pickers used on the Google Flights beta site would be neat.

https://www.google.com/flights/beta

how can i use monthPicker or yearPicker only, would you please give a guide?

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

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

awesome!

On Wed, May 2, 2018 at 11:13 AM, Ching Yaw Hao notifications@github.com
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
https://github.com/mui-org/material-ui/issues/4787#issuecomment-385914554,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AacMkVQOH0GRO7JsIyggzHidwmypEPdHks5tuXjQgaJpZM4JSThr
.

@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.

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

@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.

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

@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

@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.

@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

@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.

@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

Why is this closed? Looks like (here - https://material-ui.com/demos/pickers/) that this has not been resolved.

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.

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

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?

@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".

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.

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

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