[v1] QDate & QTime does not have ok/cancel button to dismiss the dialog

[prathabk]

The Date and Time picker does not have ok/cancel button to dismiss the dialog. Either user has to change focus by clicking outside the dialog or pressing Esc button.

Sometimes user might be clueless what to do after making the selection, so it would be better to show an Ok button to acknowledge that the user has completed the selection.

Or is there a workaround to add a button to the QDate component?

[s.molinari]

If you click a date (make a selection), the dialog closes. Why should the user be clueless after that?

Scott

[DevinH]

What if the user opens the dialog, but then decides not to make a change? I’d still think that clicking outside the dialog would suffice, but that’d be problematic for a full screen dialog. Unless clicking on the already-selected date would also close the dialog… not the most UX friendly.

[DevinH]

Reviewing the Material Design specs, this type of dialog is what’s known as a Simple Dialog.

Simple dialogs without actions
Simple dialogs allow users to act on selected elements, without action text. For example, users can simply select a list item to take action on it.

I think a good future enhancement would be if we could pass a bool (probably named ‘simple’) to convert to/from a Simple Dialog

[prathabk]

@s-molinari The dialog does not close after selecting the date and that is the issue. The user has to click outside the dialog to dismiss it. https://codepen.io/kali123/pen/BbarYZ

So it would be better to provide an action button to dismiss the dialog. Or even if the dialog closes after selecting the date/time that would be better.

[s.molinari]

@prathabk - I could swear the closing of the dialog after a date selection (the day) was the normal behavior. You are right, without that behavior, it’s not good UX.

There is a way to get it done. Found in the dev examples in the Quasar source code.

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

Now you can argue, the date picker shouldn’t hide, when a year or month is selected. Theoretically, you can create that logic yourself, but maybe there could be an @input-year, @input-month and @input-day events to catch what is needed outside the component?

Scott

[prathabk]

@s-molinari Thanks for the workaround. Will try it out.

[s.molinari]

Actually, it’s not a workaround. The methods you’d normally find in QDialog or QMenu for showing and hiding them aren’t there anymore in v1.0. They are in QPopupProxy.

https://v1.quasar-framework.org/vue-components/popup-proxy

You can also control the transition of the popup with it.

Scott

[prathabk]

@s-molinari The issue is about the UX of dismissing the dialog. In the earlier version, the QDatetime (https://quasar-framework.org/components/datetime-input.html) had the Cancel and Set buttons which are missing in the v1 QDate & QTime. If those buttons are included in v1 that would be better.

[s.molinari]

I believe the idea is to pull back on those features from a framework standpoint and let devland decide to build them out (or not). Which, is possible to do fairly easily.

Scott

[prathabk]

@s-molinari I am not a Javascript expert. I tried adding a button, but it always appending to the q-date dialog. https://codepen.io/kali123/pen/drYwbL

Is there a way we can set the button inside the q-date dialog like in the previous version? Or dismiss the dialog only in the case selecting the day and not during month/year selection?

[lucasfernog]

@s-molinari Actually, QDate does not have slots, so I don’t know if it’s that easy

[s.molinari]

I found a couple of ways to do what you are looking for. QPopupEdit being the easiest.

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

Scott

[metalsadman]

can’t complain, but many features removed which is kinda sad, i don’t understand the regression. gotta stick to 0.17 for now or back to native.

[s.molinari]

I would guess the decision to pull back on features is because with too many features added, a framework actually paints the devland devs into a corner. Yes, many will like the features being there, like everyone here asking for them. But, a lot more will want something different. If a framework has given a certain feature a certain way, it’s then “baked in” and it’s hard to change or customize. So every request after making that feature for something different has to be ignored or we have to tell developers, “It is what it is. Lump it or like it.” Or, the feature is changed and we have feature churn. All of that can and most likely will be a source of frustration for everyone.

A framework should make smart decisions for developers. It shouldn’t make all of them and not even most of them. If you want a system that makes a lot more decisions and does a lot of the work for you, then you either need a framework that offers extensions (like Quasar), where devland devs share their “decisions” and work with others. Or, you need to find a platform that uses Vue and makes a ton of decisions (and does a lot of work up front) for you. Vue in and of itself is also built with the extensibility idea in mind. Vue CLI and plug-ins is ingenious and a step above what React has.

Quasar has taken a parallel track to Vue’s extensibility now.

And, a platform hasn’t been built yet on Vue, and yes Quasar, with a good bit of work and a lot of additional decision making, could become a platform too.

Scott

[Eelke]

[upvote this issue]

Someone find a sollution allready? It is annoying that the QDate-dialog does not close after selecting.

The sollution:
<q-popup-proxy ref=“qDateProxy” …
<q-date @input="$refs.qDateProxy.hide()"…

is ugly and, indeed, close the dialog at year or month selection.

[mKomo]

This is kind of hacky however I used the following although this uses a dialog instead:

<q-dialog v-model="date">
     <q-date v-model="post.date" today-btn @click="date=false" />
</q-dialog>

[Eelke]

Yes, a quick and dirty workaround…

It’s such a normal and predictable kind of functionality… it should be a property of the component: ‘closeonselect = [true/false]’…