Quasar and Keyboard issues



  • Hi. I dont know if I’m asking the wrong questions, or asking on the wrong place, or just asking for something beyond this framework scope, but here I go again…

    Sometimes, for some reasons, some projects demands that you do things a little different. I my case I must OWN the ENTER and ESC keys and do a lot of things as the end user goes trough the form. I have to criticise and change the flow based on several factors that MUST be evaluated as he hits ENTER o ESC at EACH component on the form.

    This means: QInputs, QSelects, QCheckbox and virtually all and any component I put at the form, either Quasar’s or third parties ones.

    Surprisingly (in a real bad way) Quasar is fighting furiously against that, as it is doing two things that at least one (IMHO) is very wrong:

    1. The components lacks for a common set of functions to do the very basic about navigation: I need “focus”, “blur”, “click”, etc… to be present on every component, because if I get a QCheckbox running on my way how can I focus it in or blur from it as it is no longer a simple checkbox anymore? If the comp is a fancy and nice combination of things that offers me a great and evolved form of the basic one, thats super, but I still need the basics present on it.

    2. And please, (thats the one I find wrong) the native events should not be blocked from the developer! Here is the keydown event for QCheckbox for example, as it is on checkbox.js mixin:

        __onKeydown (e) {
          if (e.keyCode === 13 || e.keyCode === 32) {
            stopAndPrevent(e)
          }
        },
    
        __onKeyup (e) {
          if (e.keyCode === 13 || e.keyCode === 32) {
            this.toggle(e)
          }
        }
    

    How can I listen to a key event now?

    As a simple example of what I need, when the user arrives at a component (a checkbox, or a select for example) and hit ENTER I need to decide based on some logic:

    • if that key hit will toggle the checkbox
    • if the toggle should be blocked (no, its not the case for disable the checkbox, the decision MUST be made while it is on focus)
    • leave it without any changes right to the next comp,
    • or redirect it to another comp at the form.

    As such it would be heaven if each component that “do” something, i.e, opens a popup, flip something, check something, etc… had a pre event where you could set a common block prop to false and then prevent the normal behaviour to happen. But that would be heaven.

    I do love Quasar, but that has been almost a month by now of frustrating hacks trying to achieve those goals and missing them by simple func/props miss or maybe wrong (IMHO again) design decisions.

    It is reasonable to expect at least the firing of the standard events on some upcoming upgrade?

    Thanks.



  • @labs20 said in Quasar and Keyboard issues:

    It is reasonable to expect at least the firing of the standard events on some upcoming upgrade?

    Quasar is at the level where some fundamental decisions are inevitable. The problem you encountered is the symptom of such a state. Those decisione will probably seal the fate of this framework. What are those decisions?
    Well, Quasar needs to allow (or not - and provide a mechanism to implement it by user) the composition of components. It is not a “hard” problem, but it is the one, where when you decide something it will stick for to the end of life.
    What is composition of components? You for instance want to have a global behaviour processing. This behaviour of components (for example validation, presentation, custom actions) depends on the source of native events - from keyboard. Quasar desperately needs to allow process global keyboard events in terms of bahavioral actions which have semantic meaning.
    What are semantically meaning behavioral actions? This are actions, fired from external sources (keyboard in your example) but recognised, processed and finished at right components.
    What is a right component? In the context of keyboard behaviours, the native browser has a concept of “focused element”. But this “element” can be a single DOM node so it is not useful at the framework level. In the context of framework, Quasar needs a concept and definition of “active” component. This is the one where such actions could be performed (maybe even on “focused” DOM node, but - you want to change that - and now you can’t).
    There is more such semantic concepts - let’s take bahaviours of “drag’n’drop”. As for now, it is almost impossible to have a global, consistent DND actions between Quasar components.
    Another one is a clipboard - we have VueX but the state of components is as for now not “serializable” or “marshalable”, so in some situations your app can have a “clipboard” with specific Quasar component in some you will hit a wall.
    Another concept of global behaviour is “data sources” - as for now, QTable, QList, QTree etc. have specific needs for source of their data. You cant easily just plug this source to axios, or rest or graphql and hope that everything will just work.

    OK - let me be clear - this is NOT a rant. Quasar is IMHO the best framework - at this specific level of development. I do admire and I’m in awe of what those guys created and how much good work they put into this. BUT there are always another levels. If you have a local national champion then you will have an opportunity to play in champions league, and this is a whole new game. The decisions I mentioned above are inevitable and there is one element which is preventing from put Quasar in one direction. It is a fear of a wrong decision. BUT - I am sure, and based on actual, so elegant Quasar architecture, that there is nothing to fear. Please just allow us to have keyboard, DND, data sources and we will be happy, and even if it will not be perfect at the first incarnation - it surely will be at one of the next.


Log in to reply