I made a codesandbox to illustrate the problem: https://codesandbox.io/embed/codesandbox-app-5g21z

I would like the content in MyView to expand to fill the available space. That includes accounting for the variable sized controls on the parent view, which at the moment is done with a q-page-sticky (click the button to change its size), but I realise that will probably have to change. The 2 tabs show how not using any q-scroll-area means the entire page scrolls, and using a q-scroll-area with specific height ends up with cumbersome computed style="..." attributes.

I suspect the main page will have to become a flex-column, but that’s a lot of refactoring in my app, and I wanted to be sure that was the right way to go and that I wasn’t missing something easy inside MyView.

I’m really struggling to get q-scroll-area to work reliably, and I’m sure I’m Doing It Wrong. The pattern I’ve been using is something like this:

<template>
  <q-scroll-area class="fill-window">
    <div>
      <!-- Stuff here -->
    </div>
  </q-scroll-area>
</template>

<style scoped lang="stylus">
  .fill-window
    height calc(100vh - 160px)
</style>

This works, but (a) I’m hand tuning that offset (160px) to cater for the vertical position this component is rendered within the main layout, and (b) when I add something ‘optional’ to the component like this:

<template>
  <q-scroll-area class="fill-window">
    <div v-if="showControls">
      <!-- Controls here -->
    </div>
    <div>
      <!-- Stuff here -->
    </div>
  </q-scroll-area>
</template>

The value of 160px now depends on whether the parent passed true or false to showControls.

So, is there a better way to say “give as much height as possible without triggering the browsers own scrollbar”?

Dammit. Been pondering this for ages, and now having written the post, I realise I hadn’t properly initialised the properties of toolbarMenu. The fact they were working in QPage put me off the scent. Apologies for the noise.

I have a fairly complex application, with a few levels of components, and I haven’t been able to replicate this in CodePen, so presume it’s something I’m doing. The component tree is like this:

and the Vuex state contains a setting for whether certain items in toolbar menu should be visible. It’s an object like this:

To show the issue, I’ve included the Store Getter toolbarMenu, and put these 2 lines into the relevant templates. In Default.vue (which provides the QToolbar), and Page.vue (which provides the QTabs at the bottom of the component tree), I have:

    <pre>{{toolbarMenu.select}}</pre>

To begin with, all is good:

The problem is when this state is updated via an action within QPage triggered from the QTabs @input event. I can see via devtools that the Vuex state is indeed changed (all those trues become false), and the value in QPage updates, but the value in QToolbar does not:

If I make a simple source code change when running via quasar dev, the HMR update brings the QToolbar value in line. Similarly, if I pull all this code into a single file in CodePen, it works exactly as it should. So I’m a bit stumped—what might I have done that makes this getter non-reactive in the toolbar?

@rstoenescu Was https://github.com/quasarframework/quasar/commit/11f2e05146e1dfccb03504b36cfe84e3bd063863 designed to fix the warning that was generated in the console using this approach to ‘deselecting’ tabs? It seems to be still there in beta 21.

See original pen console: https://codepen.io/metalsadman/pen/zXyqyK

Nice. I was struggling trying to figure it out inside the event listener. Much cleaner to do it earlier :). I think Raz’s comment was that the warning will go away with beta-20. The final snag is that on first load, with Mails tab is open, but clicking the tab doesn’t close it, I guess because lastSelectedTab isn’t initialised on first render. For me, that doesn’t matter, because my app starts with no tabs selected, but for general use it would be important.

@rstoenescu is this something you’d consider implementing ‘properly’ within QTabs at some point? If so, I’m happy to write this up as a feature request…

Thanks @rstoenescu. @metalsadman do you have any ideas how to avoid the scroll arrows issue? I tried moving the logic into the tabs themselves, but it becomes quite unwieldy, and requires the directive and handler on every single tab… But it does have the potentially small advantage that individual tabs could be set to close on click—something like this, where the first 2 tabs would ‘close’ when clicked on again, but the others wouldn’t:

<q-tabs
  :value="tab"
  dense
  class="text-grey"
  active-color="primary"
  indicator-color="primary"
  align="justify"
  narrow-indicator
  v-tabs-deselect
>
  <q-tab v-tab-deselect name="mails" label="Mails"></q-tab>
  <q-tab v-tab-deselect name="alarms" label="Alarms"></q-tab>
  <q-tab name="movies1" label="Movies1" ></q-tab>
  <q-tab name="movies2" label="Movies2" ></q-tab>
  <q-tab name="movies3" label="Movies3" ></q-tab>
  <q-tab name="movies4" label="Movies4" ></q-tab>
  <q-tab name="movies5" label="Movies5" ></q-tab>
  <q-tab name="movies6" label="Movies6" ></q-tab>
</q-tabs>

But I think it needs both directives, and I got a bit lost in connecting together the various events that would be needed here…

Also, in the console in your original pen (and my fork), there are warnings about prop validation failing in QTabs whenever the tab is ‘deselected’:

"[Vue warn]: Invalid prop: type check failed for prop 'value'. Expected Number, String, got CustomEvent 

Thanks. It has a slight problem though which is that if there are lots of tabs and the scroll arrows show, clicking the scroll arrows also closes the currently active tab. I updated the pen for the first set of tabs to illustrate, but haven’t had chance yet to see what the fix for that might be… https://codepen.io/dsl101/pen/EJrVLw

Thanks—I actually had that in the code before, but was then convinced it should be ‘easy’ to tell if the clicked tab was the current one from the event, or at least get it’s key…