How long do you plan to support V1.x?

Wow thank you!

It can be done with Vue.compile(), but there are certain caveats you need to be aware of. This may point you to the right direction: https://stackoverflow.com/questions/46584301/vue-components-elements-in-v-html

@rstoenescu Glad you have recovered! All the best!

@Mickey58 Nice. I find websockets more fitting for UI update tasks than push notifications/service workers. The latter one are really only important if you need to notify users that are not currently using your app.

@dobbel

To listen to firebase messages you would setup somthing like:

firebase.js boot file

import * as firebase from "firebase/app"
import "firebase/messaging"

firebase.initializeApp({
    apiKey: process.env.FIREBASEKEY,
    authDomain: "my-app.firebaseapp.com",
    projectId: "my-app",
    messagingSenderId: "123456780",
    appId: "myappid"
})


export default ({Vue}) => {
    Vue.prototype.$messaging = firebase.messaging()
    Vue.prototype.$messaging.usePublicVapidKey(myPublicVapid)
}

In created hook on app level/main layout component:

this.$messaging.onMessage((msg) => { //listen to firebase
const ev = new CustomEvent(msg.data.identifier, { //msg.data is backend defined payload
                detail: msg.data, 
                bubbles: true,
                cancelable: true
             });
             const handled = !document.dispatchEvent(ev) //fire event
             if (handled) { 
                //event has been handled/consumed by another (child) component in the app
             } else {
                //handle event on app level if needed, e.g. fallback to generic browser notification
             }
})

@dobbel I send websocket messages first to “connected” users and firebase pushs to users not active for 5 minutes or so. For simple UI updates I only use websockets only (like updating counters and stuff)

On the client, I subscribe to the websocket messages (I use vue-wamp) and upon receiving, I fire a native browser event that can be handled by regular event listeners. This is set up in a “created” hook on app level or main layout, i.e. components that are always active when the app has been initialized and has focus.

$wamp is globally exported to my components by a Quasar boot file

this.$wamp.subscribe('myChannel', function (payload, args, event) {
             const data = payload[0]; //custom data sent from the backend via websocket
             var ev = new CustomEvent(data.identifier, { 
                detail: data, //pass the backend payload to the custom event also
                bubbles: true,
                cancelable: true
             });
             const handled = !document.dispatchEvent(ev) //fire event
             if (handled) { 
                //event has been handled/consumed by another (child) component in the app
             } else {
                //handle event on app level if needed, e.g. fallback to generic browser notification
             }
          }

In a component, I create event-handler like:

created() {
   document.addEventListener("my-event-identifier", this.eventHandler, false)
},
beforeDestroy() {
   document.removeEventListener("my-event-identifier", this.eventHandler, false)
},
methods: {
   eventHandler(event) {
      console.log(event.detail)
      //do stuff with event
   }
}

A nice thing is that you can implement event listeners on specific routes/components and a more generic event handling on app/main layout level to act as fallback in case the handler on the specific route did not trigger because the user is on another route. Just make sure you setup listeners onMounted() or onCreate() and remove them before the component is destroyed

@metalsadman Sorry, I must have missed that

Actually, you can use all techniques (service workers, websockets) in both PWAs and SPAs, it’s more a question of backend design imo.

In my app I have a comment system. I notify users when a new comment has been posted in a thread a user has posted to or is currently viewing
Here’s what I do:

• when new comment is posted, i generate a notification for every user that has subscribed to the thread in the backend

• push a message over websocket to all users that a new comment has been posted

• when a user is currently using the app (has focus), websocket push is received by the active browser instance

• generate a native browser event from the websocket message (new CustomEvent)

• set up a listener for the custom event on the route where the comment thread is displayed

• if the user is actually browsing the thread in question, just update it with the new comment

• if not (i.e. is somewhere else in the app) and has subscribed to thread, display a QNotification or generic browser notification. Or display a counter in your navigation/toolbar, depends on you app

• if the user reads the new comment (set up a scroll observer / intersection, Quasar has nice features for this), inform the backend about this and delete the notification on the backend if user has a subscription to thread

• setup cronjob on backend for notifications not “seen” by the user (like every 5 minutes)

• send a push message over firebase to subscribers

• service worker in my app listens to firebase messages and generates a push message

• when user reacts to push and navigates to the thread, this is handled by QIntersection and backend is informed that the user has “seen” the comment (like before)

• after 30 minutes, send out E-Mail notification from backend

This is probably overengineered for a simple “content updated” thing

The basic approach is: notify active user via websocket, inactive user via push, offline users via E-Mail. Don’t do it all at once, this is super annyoing. Keep track in your backend about notifications actually being read

Implement “priorities”. For example, I dont’t send push messages via firebase when someone has not actively subscribed to a thread. But I do of course update the UI when the user is browsing the thread currently

@stevebaer I think that the required index.template.html changes are not (yet) documented in the upgrade guide. I ran into the problem too. Since the error message gave no clue where the problem occurred I simply searched all my source files for a “.mode” property and luckily found it in the (now obsolete) htmlWebpackPlugin.options in index.html (amon a few others I knew they were my own code)

Basically, with service workers you can receive push messages without your app/website having focus on the user’s device (i.e. being in the background or even not running at all in case of native apps)

For a simple “content updated” message this is too much imo. For a simple web app you could simply do a setInterval checking the backend regularly for updates or set up a websocket connection.

Thank you

I have added quasar media player to my project with

quasar ext add @quasar/qmediaplayer

Everything runs smooth in dev and in ssr when I launch from the project folder. But when I build ssr and deploy to the production server, the module is missing.

I have npm’ed the dist/ssr folder on the production system, no luck, debug says: cannot find module ‘@quasar/quasar-ui-qmediaplayer’

Check your index.template.html.

Replace

htmlWebpackPlugin.options.ctx.mode

with

ctx.mode