@Lou-Rectoret said in Use Plugin inside Vuex module action:
instead of this:
const BEARER = localStorageAuth === null ? ‘’ : ‘bearer’ + JSON.parse(localStorageAuth).token
it should be that:
const BEARER = localStorageAuth === null ? '' : 'bearer ' + JSON.parse(localStorageAuth).token
@metalsadman said in Drawer with splitter?:
@rubs here, also fixed some quirks when q-page-container is adding padding left same as q-splitter’s left width https://codepen.io/metalsadman/pen/YzPgKML
Wow! This is some non-trivial layout! It looks like Quasar needs some themes/layouts gallery with such contributions. Maybe in the future it will be possible to “add” layout/theme as one can now “add” app extensions?
@rab well, specialization is achievable rather by composition than inheritance. Of course, it could vary between developers, solutions etc. What I propose is just make anything what works in your specific project in this time, let it do what you need, and in future, when you will find a better solution then you can change your code to perfection. Now is better then never 
Yes, those specialized components are OK - for example - in terms of version 0.17 Quasar it is something I had somewhere:
<template>
<q-field>
<q-input v-bind="$attrs" ref="ifMyField" :float-label="label" :value="value" @input="updateValue" :after="getAfter">
<q-autocomplete ref="acMyField" :max-results="123" :min-characters="minSearchCharacters" :static-data="staticSearch" @search="searchMyField" v-if="issearchable" />
</q-input>
</q-field>
</template>
As you can see, it is a q-field wrapper with emedded autocomplete. Very useful at times and it worked OK.
Ach, about dynamic composition - maybe this would be helpful also:
https://vuejs.org/v2/guide/components.html#Dynamic-Components
@nobilik said in How to implement timezone selector? (Quasar best practice):
@qyloxe Thanks for suggestion! But 5 sec for 200 rows???
Yep - I like to test queries with so called “cold cache”. This gives me a “worst case” scenario. Of course, the next queries will return in ms, but in production, with high load, there is a possibility, that the cache will be cleared/overflowed and this specific query could take 5 secs again. Because I know that beforehand I could take some actions and not be surprised. This is a nice article:
https://madusudanan.com/blog/understanding-postgres-caching-in-depth/
@nobilik I would tend to use the same timezones as with my backend db.
For example: in Postgres it could be done like below. BUT - please see, that there are 200 of those, and this specific query is quite time consuming, so I would consider using cache for that tz data on client side:
Nice!
Are there plans for drag and drop?
@walfin said in Discussion on glossy appearance:
What about glossy only for buttons?
glossy === evil
@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.
@turigeza said in Things end users care about but programmers don't:
@qyloxe Interesting : ) Thank you!
So have you done UNDO / REDO before with a relational database ? Did it work well for you ?
yes, many times, BUT it of course depends on the definition of undo
The most “classic” undo/redo is in banking systems. There is a concept of transaction log, every event has a date, a money transfer, a source, destination and if you want to make a undo, then you just replay needed transaction (banking not db) with opposite value sign.
There were apps where in some domains the undo were beneficial and where this behaviour was implemented by record version history. It works very well when you do not need to undo many inter-table connections. As a matter of fact, I implement very, very often the record version history and operations log for almost every table. It is beneficial in long run.
And there are some tables, where it is possible to model the reality in such a way, where the actions and states of the records in those tables mimics the finite state machines. I do prefer and strongly recommend using this technique in relational tables. Imagine that you have a table “Users”. You can add a column “status” with such possible values: “N” - new, “P” - in process of registration, “C” - registration cancelled, “Z” - user active, “B” user blocked, “U” - user deleted. There are possible transitions (just as example):
N->P
P->C
P->Z
Z->B
Z->U
If you have a table with versions of this table, than every update to users table would insert last version (automatically by trigger) to your version table. You have full log, full operations register, full info about who did what and when and… undo/redo possibility.
FSM (finite state machines) gives you guarantee, that your system, as a whole, will always be in determined and correct state.
Oh, this is my main modelling/architecture concept which works in most situations. It is of course only a tip of the iceberg, but I’m sure it is somewhat obvious, because all this is described and known from many years.