Material-components-web: DateTime Picker Component?

[RavenHursT]

Be it that, many data-store backends store temporal data in a comprehensive date-time data point, and not as two different points of data...

And be it that, many UI/UX usecases exist to have a user "pick", or "set" a singular dateTime data point, rather than a 2-step process for setting two data points...

And be it that, the added step and complexity of compiling two data points, date and time, add complexity and added layers of testing in order to integrate and compile the two points of date and time data into a singular datetime data point that can be sent down for backend data-stores to persist...

Would it not be possible to consider the possibility of adding to the Material Design Guidelines/Spec, an integrated component that allows for a user to pick/choose/set a singular dateTime value?

For example, while clearly incomplete, there seems to be a great start to such a component (at least in UI/UX design) here: https://github.com/Ilyaololo/react-material-datetimepicker/blob/master/0000.png

[hebbet]

see #54 and #55

[bonniezhou]

Yep, marking as duplicate of #54 and #55.

[RavenHursT]

Wait @bonniezhou @hebbet.. how is this a duplicate? Am I reading those two issues wrong? Looks like they are looking to implement time and date pickers _separately_... Not _integrated_ into _one_ component.

[bonniezhou]

Oh you're totally right, sorry about that!
I'll ask our designers about integrating date and time picker into one component and update this issue on their reasoning behind the decision.

[RavenHursT]

Awesome. Thanks @bonniezhou. 😊

[theenoahmason]

+1

[bonniezhou]

The reason for keeping the date picker and time picker separate is essentially to keep our components as broad and simple as possible. From our designer:

_There are lots of different use cases and needs for date pickers, and we made a conscious decision to provide a basic date picker that is broadly useful and relevant. We can take this request into consideration, but we also have a strong desire to avoid making things more complex. We don't proscribe building upon or adapting the components we provide, so if they need a date picker to do something special, they can certainly build their own.
There is also less of a need for a dedicated time picker on web, since you can just type numbers into a text field or select a time from a menu._

[RavenHursT]

Thanks for the response @bonniezhou, and I'm glad y'all are willing to take this request into consideration... Here's my sentiments on the design response...

There is also less of a need for a dedicated time picker on web, since you can just type numbers into a text field or select a time from a menu.

I strongly disagree w/ this. If we're in a world of "mobile-first" design, then what works for "mobile", we should (and almost always can) strive to make what works for a "mobile" device, utilized w/ a touch interface, work similarly to how the same application works on a "web" or desktop device, with a "click" interface. There's really no reason why we cannot utilize the Material time-picker on a large-screen w/ a click interface.

There are lots of different use cases and needs for date pickers

This assertion is 💯 % correct, but also applies to the time picker as well and for the two in conjunction. Clearly, there's a myriad of use cases for an interface that allows a user to pick a date-time in _one_ step, not 2, or more. This is clearly the case in a number of situations, _especially_ since, like I said in the OP, back-end data stores almost _always_ store date-time data as a single data point (UTC ms, ISO date-time strings, etc). Not as separate date and time, data points.

The logic gymnastics required to take separate date and time data points, in two separate steps (over two points in time), is cumbersome and clumsy. Having a Material spec that integrates the two would do away w/ that complexity, ultimately _lowering_ complexity... Not _increasing_ it.

If there weren't required use cases, we wouldn't see people struggling to create them themselves in the OSS community, as you suggested, and as we see them doing like in the example I linked to in the OP. Here's some more examples:

https://github.com/Ilyaololo/react-material-datetimepicker/ (A good start, I think. But ultimately incomplete as a solution)
https://dmtrkovalenko.github.io/material-ui-datetimepicker/ (just a wrapper around the two components resulting in a clumsy interface that's confusing to navigate)

The problem though, is that while the date and time pickers are clearly defined in the Material spec, how we should all be _integrating_ the two, into a _single-step date-time_ picker is not. And so, as you can see, we end up with some very odd, and incomplete solutions to the problem at hand.

I've even come across a number of threads in Material implementation libraries where the request has been made to add something like this, and the answer always comes back from the maintainers to the effect of, "This is outside of Material spec, so we're closing this.": https://github.com/mui-org/material-ui/issues/4151#issuecomment-216881808

We don't proscribe building upon or adapting the components we provide

That assertion can easily be proven false. The only thing that's being requested here is not to "adapt" the current date and time pickers, but simply to provide a spec design that will show how the two should be integrated to solve the single date-time data point problem. Your own animated gifs on your spec site show _both_ the pickers as not stand-alone components, but as components integrated with another component (https://material.io/guidelines/components/pickers.html#pickers-time-pickers , https://storage.googleapis.com/material-design/publish/material_v_12/assets/0B3321sZLoP_HWk1jVmpGN0ZIaDg/components-pickers-time-transition.webm). In each case, w/ the Dialog component.

Furthermore, almost _every_ Material implementation out there, integrates the TextField, Dialog, and Time/Date Picker into one interface, since that's almost always the way users interact w/ them.

W/o a spec to show how to integrate the two components, this is clearly a limitation in the Material spec. When we send data back to a back-end, in a single point in time, we should be able to send them something to the likes of an date-time data point (ms, ISO date-time format, etc). Right now, Material has no way to map that kind of data to an input interface, without some kind of middleware doing the work to reconcile the two data points across the two points in time... and that's where the limitation lies.

[kfranqueiro]

Firstly, thank you for your thorough and thoughtful feedback.

Regarding your first point, personally I agree with your assessment regarding text fields providing a sub-optimal interface for time input, especially for mobile devices, and I definitely think we should at minimum seek to tackle both date and time inputs individually on Web (and we have tasks tracked for both).

Regarding the integration of date and time inputs into a single component, I can see what you're getting at regarding the end result potentially being simpler from an MDC Web consumer perspective; however, the complex part is designing a reasonable UI that combines both, and this is the sort of thing where designers on teams consuming MDC Web are likely to have wide differences in opinions. It's tricky and perhaps unlikely to arrive at a one-size-fits-all solution, and the integration of date and time into a single UI is best left to the particular application and use case.

Presently, there are no plans for Material Design to include a compound component that incorporates both of these, and it's common for Material UIs to present separate entry points for date and time. I'll be sure to relay your feedback to the design team though, so that this can potentially be considered at a future point in time.

Going back to the original concern of combining the values from a date picker and time picker into a single Date object, this seems like a reasonable concern, and something we should consider when implementing the time picker, and document once we have implemented both individually.

[RavenHursT]

Thanks for engaging @kfranqueiro...

Going back to the original concern of combining the values from a date picker and time picker into a single Date object, this seems like a reasonable concern, and something we should consider when implementing the time picker, and document once we have implemented both individually.

I appreciate y'all taking this into consideration.. But your response seems to only address about half of the problem regarding the compiling of both a time data point and a date data point _across two points in time_ into a singular Date object.

The problem, AFAICT, can _only_ be solved by a component that results in _both_ of these data points mutating the UI state at a _singular point in time_.

The problem w/ them remaining separate is, how does the underlying persistence layer know _when_ to persist a compiled Date? If a user changes one or the other, do you persist twice, potentially persisting a compiled Date that was never intended by the user because they were still in the middle of choosing the entirety of the Date they wanted?

Sure, there are ways to make this work, but the mental and engineering gymnastics required to make this happen seem to be overly complex.

I still think having a MDC that sets a spec for integrating the two, for this singular purpose is still the best way to go about solving this problem that this community faces regarding a clean, simple to implement, uniform interface for a user to control a Date object in state, at a singular given point in time.