search

mui / material-ui

Material UI: Comprehensive React component library that implements Google's Material Design. Free forever.
https://mui.com/material-ui/
MIT License
93.87k stars 32.26k forks source link

[DatePicker] Port component #4787

Closed nathanmarks closed 5 years ago

nathanmarks commented 8 years ago
sairamdevarashetty commented 7 years ago

@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 commented 7 years ago

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:

GabeDuarteM commented 7 years ago

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!

oliviertassinari commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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)

DoWhileGeek commented 7 years ago

Is there any plans for this issue to move forward?

oliviertassinari commented 7 years ago

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

DoWhileGeek commented 7 years ago

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

rosskevin commented 7 years ago

@DoWhileGeek you are free to PR a solution to mui/material-ui#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.

dmtrKovalenko commented 7 years ago

+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

rosskevin commented 7 years ago

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 mui/material-ui#4787 and mui/material-ui#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:

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.

leMaik commented 7 years ago

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

rosskevin commented 6 years ago

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

dmtrKovalenko commented 6 years ago

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

rosskevin commented 6 years ago

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.

leMaik commented 6 years ago

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

dmtrKovalenko commented 6 years ago

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

izundo-viennv commented 6 years ago

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

saraivinha85 commented 6 years ago

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

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

datepicker

mbrookes commented 6 years ago

@saraivinha85 Sweet! 🍬

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

saraivinha85 commented 6 years ago

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

pricetula commented 6 years ago

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

dmythro commented 6 years ago

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

ismail-codar commented 6 years ago

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

dmythro commented 6 years ago

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

Kussie commented 6 years ago

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

taoxueweilong commented 6 years ago

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

dmtrKovalenko commented 6 years ago

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

chingyawhao commented 6 years ago

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 commented 6 years ago

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 .

mbrookes commented 6 years ago

@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 commented 6 years ago

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

oliviertassinari commented 6 years ago

@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 commented 6 years ago

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

stunaz commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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

Material Design

techniq commented 6 years ago

@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 commented 6 years ago

@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

MyPublicGitHubAcct commented 6 years ago

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

Raemon commented 6 years ago

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 commented 5 years ago

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

jasonkylefrank commented 5 years ago

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?
    image 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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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