Sorry for no codepen—really struggling to recreate this one due to router complexities, but I’m trying to make this app load the last active tab when the user navigates to a new ‘event’. Relevant bits of router:

}, {
  path: ':event',
  name: 'Event',
  component: () => import('pages/Event'),
  children: [{
    path: 'dashboard',
    name: 'dashboard',
    components: {
      tab: () => import('components/event/Dashboard')
    }
  }, {
    path: 'members',
    name: 'members',
    components: {
      tab: () => import('components/event/Members')
    }
  }, {

Navigation and display works fine, apart from the tabs at the top of the Event component. I’ve duplicated their functionality with regular router-link components in Event.vue like so:

<template>
  <div>
    <q-tabs>
      <q-route-tab label="Dashboard" to="dashboard" />
      <q-route-tab label="Members" to="members" />

      <router-link tag="q-btn" to="dashboard" active-class="text-red">Dashboard</router-link>
      <router-link tag="q-btn" to="members" active-class="text-red">Members</router-link>
    </q-tabs>
    <router-view name="tab" />
  </div>
</template>

<script>
  const loadTab = (to, from, next) => {
    if (to.name === 'Event') {  // We landed on the event 'home', so move to whichever tab was last active
      const lastTab = store.getters.lastTab(to.params.event) || 'dashboard'
      next(`/${to.params.event}/${lastTab}`)
    } else {
      next()
    }
  }

  export default {
    beforeRouteEnter: loadTab,
    beforeRouteUpdate: loadTab,
    data: () => ({
  .
  .
  .

What I see on the Event page is the correct content (i.e. the Dashboard or Members component loads), but the q-route-tab has the ‘wrong’ tab higlighted, whereas the router-link button is correct:

Event with ‘Dashboard’ as the last tab:

Event with ‘Members’ as the last tab:

See how the red router-link buttons match the component, but the q-route-tab ‘active’ state doesn’t. It’s ‘one-behind’, like it didn’t update when the route changed—i.e. if I navigate to a series of Events that were all last on Dashboard, the Dashboard tab is active after the second navigation.

I’ve tried and failed to reproduce this in a codepen, but with vuex, router, and firebase all involved in my actual app, I’m not 100% sure I’m really reproducing my scenario. Any ideas where to start figuring this out?

In my app, showing a page with 150 items is pretty quick, but then the browser locks up for several seconds. If I comment out the QPopover, all is well, as is the case with just the menu button connected to showing an action sheet. I’ll stick with Action Sheet for now, and then look again in v1.0.

The item data is coming from firebase, so I’m not sure how much adding an infinite scroll would help me either—I know you were just using that for generating the list, but it did make me think whether that might help streamline things.

It’s tricky to tell, as I can’t seem to run the Vue Perf plugin on jsfiddle—not sure if it’s possible to get a non-production version of Quasar from a CDN… I’m still seeing the issue in my app though. I will try to put some timing in the code to see if it’s possible to highlight it. However, as per the discussion on Discord, it may (hopefully) be a moot point now, as all this looks set to change in v1.0 anyway.

And, it looks like this may radically change in v1.0 from what I can see in the codebase, so perhaps the performance issue will just magically go away :). Roll on Jan!

I have an SPA which creates potentially large numbers of ‘items’ on a page, and each item is a component with a number of sub-components, one of which is a clickable menu button which should then display a popup menu of actions. This was all working fine, with Item.vue making use of QPopover so that each item had it’s own popover ready to use. However, as the number of items grew, the performance of this approach has rapidly decreased to the point where there is a noticeable lag displaying the page.

I posted some early metrics on the Quasar discord channel here, summarised below.

I installed Vue Performance and set up a test page with 20 items. I see this in the page performance report:

Component  Count  Total
QPopover    26    618ms
QList       23   1007.4ms

compared to this when the menu button / popover is removed from the Item.vue template:

Component  Count  Total
QPopover     6   154.2ms
QList        3   113.7ms

You can imagine how bad this gets with 200–300 items on a page. So creating the popover ‘on demand’ seems like a good solution, and in the discord chat it was suggested this could be done on mouse hover over an item, before a user gets chance to click the menu button, so there’d be minimal delay between the button and the popover appearing. I used the approach here, but hit a snag I haven’t been able to solve. The code is:

const QPopoverClass = Vue.extend(QPopover)
const qPopoverInstance = new QPopoverClass({
    propsData: { anchor: 'bottom right', self: 'top right' }
})
qPopoverInstance.$mount()

and the error I see in the console is:

[Vue warn]: Error in nextTick: "TypeError: Cannot read property 'removeChild' of null"

Tracing that down, the mounted() hook in QPopover refers to this.anchorEl, which is null when the element is created in code as above, and I’m not sure whether it just needs initialising differently, or whether this approach is just never going to work, and there’s a better solution.

I did consider putting the popover in the page, but that would mean splitting code out from Item.vue and putting it where it doesn’t really belong, and I would also need lots of props and event-handlers to connect the 2 components.

What I really want is something like QActionSheet but which displays as a popup near the click position, rather than at the bottom of the screen.

Any advice / ideas gratefully received!

Not exactly the same content as you, but I got extra stuff on cards to ‘float to the bottom’ using style="flex-grow: 1":

    <q-card-title style="flex-grow: 1" @click="handleSelect">
      {{item.text}}
      <span v-if="!pageSettings.anonymous" slot="subtitle">{{subText}}</span>
      <q-icon v-if="isMine(item) || isAdmin()" slot="right" name="more_vert" >
     .
     .     
     .
      </q-icon>

    </q-card-title>

    <comment
      :id="id"
      :active="activities.includes('comment')"
      :pageSettings="pageSettings"
      :activitySettings="activitySettings.comment"
    />

The output of the comment component is now anchored at the bottom of the card, however tall the card is.

OK - here’s my solution. I’m still not 100% sure why this works and making setOption() return a function doesn’t, but hey ho. I’m sure it’s tied up inside template compilation:

@input="val => { setOption(setting.key, val) }"

I have a list of QItems generated using v-for, and that list is made up of QOptionGroup components each offering a set of choices. The problem is that I would like to bind the @input handler of the QOptionGroup to a function which would receive 2 parameters - the key from the list, and the value of the option the user clicked on. So the template looks something like this:

<q-item v-for="setting in toolSettings" :key=setting.key
  <q-field :label="setting.label">
    <q-option-group
      type="radio"
      :value="page[setting.key"
      :options="setting.options"
      @input="setOption"
    />
  </q-field>
</q-item>

That all works fine, but the setOption() function only receives the value, and if that value is valid for more than one of the toolSettings, it’s impossible to determine which item was clicked. So I tried this:

      @input="setOption(setting.key)"

But now all I get is the key, not the value. I was hoping it would appear as a second parameter, but it doesn’t, and I just can’t figure out how to pass both the key and the value to the handler. I also tried making setOptions() take 2 parameters (key and value), and using partial application, but that doesn’t seem to be supported directly in event handlers.

I can imagine :). I know it’s probably not top priority, but the alternatives are definitely sub-optimal.

I also tried vuedraggable - it’s better in that its interaction with q-list works, but it defeats the highlight class, so still not right. @rstoenescu I know you were resistant to this being a part of quasar, but I suspect all the other libraries will show undesirable behaviour like this, since they are all interacting so closely with the DOM.