SSR async components $q.screen reactivity

[Evertvdw]

trafficstars

Describe the bug When using SSR and some conditional class based on $q.screen.something in an async component this conditional class is not updated.

Example component:

<template>
        <q-input outlined bg-color="red" label="test" :class="$q.screen.gt.xs ? '' : 'fit'"/>
</template>

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  created() {
    console.log(this.$q.screen.gt.xs);
  },
  mounted() {
    console.log(this.$q.screen.gt.xs);
  },
})
</script>

Upon initial load this input field will still have the fit class applied to it until you interact with the input.

Codepen/jsFiddle/Codesandbox (required) There is no Codesandbox available yet for SSR in Quasar v2.

To Reproduce Steps to reproduce the behavior:

1. Create new quasarv2 project
2. Add the a component AsyncComp.vue to the components file with the content above.
3. Add AsyncComp: defineAsyncComponent(() => import('src/components/AsyncComp.vue')) to Index.vue's components declaration. Also add import {defineAsyncComponent} from 'vue' to this file.
4. Add the <async-comp/> somewhere in the html.
5. Run with SSR mode quasar dev -m ssr
6. F5 on the index page and see.

Expected behavior Upon hydration the $q.screen.something should be reactive and the conditional class updated. At the mounted() hook this property already has the correct value, I don't know why it won't update.

Screenshots If applicable, add screenshots to help explain your problem.

Platform (please complete the following information): Quasar Version: v2.0.0-rc.3 @quasar/app Version: v3.0.0-rc.3 Quasar mode:

• [ ] SPA
• [x] SSR
• [ ] PWA
• [ ] Electron
• [ ] Cordova
• [ ] Capacitor
• [ ] BEX

Tested on:

• [ ] SPA
• [x] SSR
• [ ] PWA
• [ ] Electron
• [ ] Cordova
• [ ] Capacitor
• [ ] BEX

OS: Node: NPM: Yarn: Browsers: iOS: Android: Electron:

Additional context Add any other context about the problem here.

[Evertvdw]

Any comment on this issue? This used to work in QuasarV1 so it should also work in V2.

[hawkeye64]

@Evertvdw I would suggest putting your $q.screen test in a computed and return the proper class. Then use that in your html. There could be an issue with reactivity and inline code like the way you have it.

[rstoenescu]

Is this still happening for you while using latest Quasar (v2.2.0)?

[Evertvdw]

@rstoenescu Yes, I just created a new starter project and followed the reproduction steps and it still does not work correctly. It has the fit class still applied when hydration is done even though the console.log of $q.screen.gt.xs is true on both the created and mounted hook client side. Once you click on the q-input the class is removed.

[Evertvdw]

I checked to see if this issue still persists, I can still reproduce it. Here is a reproduction example: https://codesandbox.io/s/async-surf-ftpfs?file=/src/components/AsyncComp.vue

To reproduce:

1. Make sure the browser window in the sandbox is above the xs breakpoint
2. Refresh the page, the red input field now has full width (has 'fit' class applied)
3. Click inside the input field, the input field will now shrink ('fit' class removed)
4. Notice in the console that the value of $q.screen.gt.xs is correct on created and on mounted client side but the dynamic classes are not updated correctly

[JeRabix]

In quasar v 2.7.5 I always have the same console.log() in SSR mode, regardless of the device xs: true width: 0 height: 0

Is this how it should be? q.screen doesn't work in SSR or is it a bug?

[pdanpdan]

It is run in the create phase, so on the server you'll get always the same thing

[JeRabix]

It is run in the create phase, so on the server you'll get always the same thing

Can I somehow get the width/height of the device on the server side?

[pdanpdan]

Never on first request/response cycle When all the planets align, something might work:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Viewport-Width https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Width https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH

So as a short answer: no

[JeRabix]

Never on first request/response cycle When all the planets align, something might work:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Viewport-Width https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Width https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH

So as a short answer: no

Thanks!