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



  • 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



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



  • 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



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



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



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

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

    Scott



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



  • 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



  • [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.



  • 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>


  • 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]’…


Log in to reply