Quasar: [v1] I miss the calendar/Datetime component

[victorborgaco]

As in earlier versions there was this co-rapporteur that unified in one component the option of selecting date and time making it much easier to develop.

[alterhu2020]

also why missing this page: https://v1.quasar-framework.org/vue-components/date ?

[victorborgaco]

I mean the component
<q-datetime v-model = "model" type = "datetime" />
https://v0-15.quasar-framework.org/components/datetime-input.html
where a co-rapporteur unifies date and time

[karelbyte]

the new component is bullshit

[smolinari]

@karelbyte - You should refrain from such useless attacks and language.

The new date and time pickers are meant to be separate now, so to get both a date and time input. two different input fields for date and time are needed. Combining them with QInput to make such an input is easy.

https://codepen.io/smolinari/pen/MxaJBv

Scott

[nothingismagick]

A lot of people are new to open source, and don’t realize that there are
real people behind these projects. @karelbyte - I suppose you probably know
by now that your comment was WAY out of line. I’ve been guilty in the past
of similar comments, and I always regretted them the instant I posted them.
Nowadays I ask myself how I would feel if someone were to use the same
language about my website? My software? My children?

To get to the meat of your comment, you have responded to an issue with our
BETA release, and both Calendaring and the underlying Date logic
will receive some (hopefully) productive community discussions where we
find the pain points and make things even more awesome (aka less
“bullshit”). You are invited to participate, under the condition that you
keep your comments both civil and productive.

[snowyu]

1. The orignial can process the date and time at one input box. More useful on mobile.
2. The output value is the ISODate string which the Date Object can process it directly.

Split the QDate and QTime component from QDateTime is good arch for reusing code.

But it's hard to merge the two components(QDate and QTime) to the original QDatetime compnent now for no option to hide the all picker headers.

[tegola]

Since the new approach is going to stay, I am trying to make my own date-input component that retains the look of an input with a dropdown arrow.

Here's my component so far:

<template>
  <q-input
    :value="value"
    v-bind="$attrs"
    @input="$emit('input', $event)"
    @keydown="onKeyDown"
    @click.native="open"
    @focus.prevent
    v-on="$listeners">

    <!-- Clear button -->
    <q-btn
      slot="append"
      v-if="clearable && value"
      flat
      round
      @click.stop="$emit('input', null)">
      <ap-icon name="close" />
    </q-btn>
    <q-icon slot="append" name="arrow_drop_down" />

    <!-- Popup -->
    <q-popup-proxy ref="popup">
      <q-date
        :value="value"
        @input="$emit('input', $event)"
      />
    </q-popup-proxy>
  </q-input>
</template>

<script>
export default {
  props: {
    value: {
      required: true
    },
    clearable: Boolean
  },

  methods: {
    open (evemt) {
      event.preventDefault()

      this.$refs.popup.show()
    },

    onKeyDown (event) {
      if (event.key !== 'Tab') event.preventDefault()
    }
  }
}
</script>

And the usage:

<my-date-input
  label="Date"
  clearable
  v-model="date"
/>

(It's a work in progress, it's still missing proxy props for QDate)

The major issue is that after closing the picker, the input gets the focus (hence the keydown method that blocks everything except the Tab key). On mobile devices, it triggers the virtual keyboard.

Another one is that I don't know how to display the value with a different format on the input. The old QDateTime had a useful displayValue prop to do this.

Here's how it looks before picking a date:

and after:

Suggestions for improvements are welcome.

[snowyu]

I've writen an Advance Input Compent for Quasar@v1: QInputEx. easy to create new input type from it.

But I have no time to make it as a library(PR welcome). and datetime is an ugly impl.

The usage like the QInput:

<q-input-ex type="color" value="#ff0000"/>

The project is here: https://github.com/snowyu/qinputex

[DaedalusDev]

Hello,

i up this post !

I've upgrade an application from 0.17 to 1.0 and i can't reproduce a DateTime picker :-/

Is it planned to design it soon ?

Thanks.

[NicksonYap]

I'd suggest there to have both the separated: QDate and QTime and a combined QDatetime

A lot of APIs use Datetime, especially when native browser supports Datetime input

The user experience having to key in the Date, and then Time, is not the best
This makes us want to other Vue components such as v-calendar or VueCtkDateTimePicker

Which is awkward when Quasar has something so close...

[CheyenneForbes]

I too miss the datetime component, in some cases having the date and time as separate fields breaks the UX/UI

[timhere]

An unusual issue title, but I agree!

It's a common scenario for date and time to be stored together as a string in a single database field, therefore APIs often return an ISO 8601 formatted UTC date and time string, i.e. 2019-03-25T12:00:00Z. Reflecting this, JS has the toISOString() method.

The v0.17 datetime picker fitted this situation and use-case nicely. And as others have said: the fluidity of moving the user from the date to the time input UI had many advantages.

Concatenating a date and time together from separate input fields is, of course, possible to implement, however I believe there is enough of a use-case to justify the inclusion of a combined date picker as before.

[smolinari]

I know someone, who is putting together an app extension with a full blown DateTime component. I privately pinged him and asked if he could say hello here and give an update.

I'd like to impress upon you all that this is going to be the future of Quasar. It will be developers (not just Quasar staff) offering developers their solutions to solving problems via app extensions, similar to the QMediaPlayer component.

You are all smart devs, so the take in the future will be, instead of asking for Quasar to build components for you, and waiting and waiting and waiting, you can and should be building them yourself and for everyone else. It's giving back to the Quasar community! It means the core devs can concentrate on the core and added features like this request become a community affair, and in the end, they will get much more love and attention. It means inevitably, the development speed of Quasar will increase exponentially.

It's a win-win! :smile:

Scott

[NicksonYap]

@smolinari You're right Scott, since this is an open source project

However it sounds like the Quasar team chose to avoid a combined Datetime component and favor a separate one instead, and it's not like they find it troublesome

Sorry if we sound demanding but we're just confused why we're avoiding a combined one when other standards are using it

It make it hard to integrate with APIs etc

I couldn't wait and have actually developed my own component using QDate and QTime and took some quite some time to get the experience right

I'm happy to submit a PR but I really doubt it's a method the Quasar team would accept (very hacky)

[timhere]

I'm in agreement with @NicksonYap. If this was a niche use-case then a community extension would be appropriate.

It doesn't appear logical that something so relevant would be actively excluded, where other far more niche components, QStepper for example, are an included part of the core framework.

[smolinari]

It make it hard to integrate with APIs etc.

It's a simple matter of data formatting and not hard at all. You can't win me personally on the "a DateTime component is better for API integration". What you can win me on is offering a more streamlined UX and I'd agree on that point.

And that doesn't change the point that this component can and should be made in devland now.

If this was a niche use-case then a community extension would be appropriate.

A lot of community solutions won't be just for niche problems. They will be for mainstream problems too. In fact, that will be the bigger win for many in the future. Trust me. You'll see. 😄

Scott

[TobyMosque]

a QDatetimePicker extension
github: https://github.com/TobyMosque/app-extension-qdatetimepicker
demo page: https://qdatetimepicker.netlify.com/#/

quasar ext add qdatetimepicker

[victorborgaco]

@TobyMosque Great stretch, exactly what I needed. Thank you !!!

[smolinari]

You see! I told you so! Great job @TobyMosque! 👍

Scott

[rstoenescu]

Closing this. We already got a series of app extensions which add components for this:

https://github.com/quasarframework/app-extension-qscroller
https://github.com/quasarframework/app-extension-qcalendar
https://github.com/TobyMosque/app-extension-qdatetimepicker