not exactly speed up tip, but the v-cloak directive may be helpful (and it is of course working with Quasar):

https://vuejs.org/v2/api/#v-cloak

@alphaelf not that I want to interfere or something, but somehow I wonder if your solution is the right one.
I infer, that you want to have some dynamic modules/functionalities based on app state (isAuthorized)

If this is your scenario, then let me think, what I would do:

1. if this is webpacked SPA/PWA app, those modules are already bundled, so there’s no security issue or a real need to LOAD them AFTER authorization. They’re already there, so I suppose, what you really want is just INIT them with a new/updated context.
2. I assume, that those modules doesn’t need to be initialized sequentially. If that is the case instead of “await” I would use something like Promise.all([…]) instead.
3. From the architecture point of view, those modules should be rewritten to have some kind of init function, and you can call those functions (on already loaded modules) to switch to the new context. Ideally, those modules should only depend on vuex not on your actions, because thats what for vuex is - managing global state - and isAuthorized is obviously a global state.
4. In Vue there is a concept of “watchers”. In those modules, you could even “watch” for the changes in global vuex state, and let those modules init to default config themselfes.

@chyde90 Fun! Quasar rules!

And this is very nice image editor with possible quasar uploader integration:

https://github.com/nhn/toast-ui.vue-image-editor

It works even in Quasar dialog and has many useful features.

@Diamon well, it would be nice to have something like this as a part of a picture uploader. Sometimes it is useful to crop, adjust, filter even uploaded picture. Such preview would give a substantial edge for Quasar uploader in comparison to another frameworks. Anyway, bear in mind, that such functionality would have to work well on all Quasar supported platforms: spa, pwa, ssr, desktop, mobile, cordova, electron. In my opinion - nice to have, low priority.

@pureblood said in update badges in tabs:

@qyloxe ok understood - so still the vuex way
that I found out about in my second post (see above), I thought you meant that there was another way aside vuex or global bus events.

so for now, there are two ways. global (mystic) bus events and vuex
thanks!

Yep ALWAYS vuex when you have even a slightly smell of shared state. As a bonus you have reactive properties, namespaced state hierarchy, transactions (something like), version history (in chrome extension), debugging, easy persistence etc. The downside is that vuex is declarative BUT there are many extensions, tools, good practices as of yet. For example I recommend using this:
https://vuex-orm.github.io/vuex-orm/guide/prologue/what-is-vuex-orm.html
And a rule of thumb: if you think about using events in vue then probably there is another solution (reactive). Thinking in events is “old way”. Thinking in reactive data models is “vue way”. Of course events ARE useful, but when you need to communicate action (ie click, hide, move, ), not share state. When you think about event “change” - you are probably dealing with hidden state.

you can use such code as a mixin in both components and keep state in vuex. In both component you will have access to actual, reactive state from Vuex - without any mystic events:

import { mapGetters, mapMutations } from 'vuex'

export default {
  computed: {
    ...mapGetters(['getUILeftDrawerOpen']),
    leftDrawerOpen: {
      get () {
        return this.getUILeftDrawerOpen
      },
      set (value) {
        this.setUILeftDrawerOpen(value)
      }
    }
  },
  methods: {
    ...mapMutations(['setUILeftDrawerOpen'])
  }
}

There are few concepts which might be helpful:

1. computed setters:

https://vuejs.org/v2/guide/computed.html#Computed-Setter

2. @input event in QTabs API:

https://quasar.dev/vue-components/tabs#QTabs-API

@metalsadman @Mickey58
Well, I have a mixed feelings about incorporating virtual columns into q-table. This is obviously the preferred way for presentation of computed (on the client side) values - in this example it is the “is selected” column but it could be anything - the sum of two other columns, the abstract of the long text, the amount with added local tax etc.

IMHO the real problem is a concept of “data model”. Of course we could extend the q-table capabilities, BUT very similar capabilities should be possible for other components - list, tree etc. I consider it a bad design if every component would have his own “rules” and separate “data model” to deal with.

I think, that at this moment Quasar is in need of a separate non-visual component for data modelling. There should be column definitions (also virtual/computed), pagination, sorting, filtering, querying, events for data loading, server synchronization etc. This non-visual component (or maybe class?) should be attached by composition to visual components like q-table, q-list, q-tree etc.

So, I am sure, the computed/virtual columns are the way to go, but I’m not so sure, it should be implemented exactly into the q-table.

@Mickey58
in:
https://quasar.dev/vue-components/table#Defining-the-columns

this is actual column definition:

  {
    // unique id (used by row-key, pagination.sortBy, ...)
    name: 'desc',

    // label for header
    label: 'Dessert (100g serving)',

    // row Object property to determine value for this column
    field: 'name',
    // OR field: row => row.some.nested.prop

    // (optional) if we use visible-columns, this col will always be visible
    required: true,

    // (optional) alignment
    align: 'left',

    // (optional) tell QTable you want this column sortable
    sortable: true,

    // (optional) compare function if you have
    // some custom data or want a specific way to compare two rows
    sort: (a, b, rowA, rowB) => parseInt(a, 10) - parseInt(b, 10),
    // function return value:
    //   * is less than 0 then sort a to an index lower than b, i.e. a comes first
    //   * is 0 then leave a and b unchanged with respect to each other, but sorted with respect to all different elements
    //   * is greater than 0 then sort b to an index lower than a, i.e. b comes first

    // (optional) you can format the data with a function
    format: (val, row) => `${val}%`,

    style: 'width: 500px',
    classes: 'my-special-class'
  },

If you could define “virtual” columns, then you could sort/filter/select them also. In example:

  {
    // unique id (used by row-key, pagination.sortBy, ...)
    name: 'desc',

    // label for header
    label: 'Dessert (100g serving)',

    // (optional) alignment
    align: 'left',

    // (optional) tell QTable you want this column sortable
    sortable: true,

    value: (col, row) => this.selected.includes(row.id)

  },

the new column attribute “value” could be a “virtual”/“computed” column with parameters:
col - this col definition
row - actual row - based on other row values “value” function returns proper computed value

It would solve your problem and many others.

@metalsadman effectively it could be handled by some kind of computed/virtual table column.