Active route tab doesn't update on reactivation when it's a descendant of <keep-alive>

[Foobartender]

What happened?

I have a router view as following. The actual component contains QTabs with QRouteTabs.

<router-view v-slot="{ Component }">
  <keep-alive>
    <component :is="Component" />
  </keep-alive>
</router-view>

When a route and its QTabs are reactivated, the active QRouteTab is the one to which was navigated to when leaving the reactivated route.

What did you expect to happen?

QRouteTab for the current route should be active.

Reproduction URL

https://stackblitz.com/edit/quasarframework-zj3yfq

How to reproduce?

1. Go to the provided reproduction link. There are route tabs in the layout header labeled "A", "B", and "C". Their corresponding route components display that label.
2. Visit each route at least once and then switch between them randomly.
3. Note that the active route tab doesn't match the current route. Or more precisely, it matches the route you left to the last time you were there (and thus clicking a route twice makes it match).

Flavour

Vite Plugin (@quasar/vite-plugin)

Areas

Components (quasar)

Platforms/Browsers

Firefox, Chrome

Quasar info output

No response

Relevant log output

No response

Additional context

I'd guess that QRouteTab lacks an onActivated hook with a call to $tabs.verifyRouteModel(), or maybe should use watchEffect instead of just watch.

By the way, the Stackblitz template is a bit outdated. 😉 It uses Quasar 2.9, but it happens with 2.16.10, too.

[yusufkandemir]

Hello, it works fine if you use the layout as a layout instead of making it a component and re-creating it on each route. When you use it as a layout, it will be rendered once per app (or group of routes). When you use it as a component like you use on every page you have, it will be created/calculated on each page you have. So, it will be 1 instance vs many instances. Let aside this specific case, you might run into many different unpredictable issues. This will at least cause performance problems, even if they are not so noticeable when your app is small.

See this StackBlitz where I used the usual layouts/pages routes approach:
https://stackblitz.com/edit/quasarframework-5eodnf?file=src/router/routes.js,src/layouts/MainLayout.vue,src/pages/ComponentA.vue

As you are following a non-standard, not performant, and not recommended way to manage the routes/layout/pages, and there is an existing way to achieve this, I don't consider this a bug. I have never seen something like this before. If you think you have a good reason, please share it and we can reconsider this. Thanks for your understanding.

By the way, the Stackblitz template is a bit outdated

Thanks for pointing that out, I've updated the template.

[Foobartender]

I have deliberately chosen that route (no pun intended), because I see no sane way to leverage the power of a QLayout with multiple slots with named router views instead without distributing business logic over multiple components in an insane way.

Now that Vue 3.5 allows deferred <Teleport> within the app, I might have an alternative approach, but it still imposes to much restrictions on URL path structure vs. router view structure.

But whatever, is it really such a big deal to add an onActivated hook to QRouteTab? If so, please turn this into a feature request to expose a method that does what $tabs.verifyRouteModel() does, so that I can implement a proper workaround.

[yusufkandemir]

Thanks for the explanation. I will see if handling it in onActivated is acceptable. Otherwise, we will try to expose it for you to handle.

[rstoenescu]

Fix will be available in Quasar v2.16.12