I have to add that I have often received great help in this forum from folks like @s-molinari or @metalsadman and others. It is often difficult to get into the deep details of a particular problem, given the broad range of functionality offered by Quasar and Vue. I’m really impressed how you folks often come up with the right answers or at least pointers to the right solutions. Keep going!

After realizing that Heroku as the deployment environment for my Quasar app has restrictions with uploading/downloading of files, I’m now looking for some sample code how to use q-uploader to upload files to Amazon S3..

I’m not familiar with S3 yet and have used q-uploader so far only in a simple way, to upload files to the file system of the Quasar frontend app.

All I found so far as a boilerplate to start from is a tiny code snippet on the old Quasar site (https://forum.quasar-framework.org/topic/5382/how-to-use-q-uploader-in-quasar-app-deployed-on-heroku ) that uses q-uploader with so called signed S3 URLs.. It uses a q-uploader prop :url-factory=“getSignedUrl”, but I can’t find that prop in the API documentation of the current version of q-uploader on https://quasar.dev/vue-components/uploader#QUploader-API.

Is there another sample or Codepen how to use q-uploader to upload a file to Amazon S3?

Would greatly appreciate some advise.

All the best for Ravzan, get well soon. Your work is incredible, in terms of innovation, quality, and quantity.

As a first step, I tried a flex box as suggested by @metalsadman to align the q-toggles. Here is a code snippet that shows the concept, using class=“col-2” for each q-toggle, which means 2/12 of the available space in the row:

<div v-if="$q.screen.gt.xs" class="row full-width">
        <div class="col-2">
                <q-toggle
                      v-model="visibleColumnsMaterialEigenschaften"
                      val="schallSchutz"
                      label="Schallschutz"
                 />
        </div>

It took me a few attempts to find out that it needs class=“full-width” to work properly.

The result has up to 6 toggles per row that are aligned nicely:

@Jordan

The script section of my SPA on Heroku looks like this:

  "scripts": {
    "build": "quasar build",
    "start": "node front-end-server.js",
    "heroku-postbuild": "npm install --only=dev --no-shrinkwrap && npm run build"
  },

Wow…so I tried this combination of v-model=“toggleAllNormkategorienState” and @input=“toggleNormkategorien”…which is in my view a bit “creative”…at least not what I would have expected from the docs

On the first try, I got disappointed because it did not immediately work for me (neither control for table column visibility nor the ticking of q-toggle, worse than my original combination of @input= and value=).

But the additional trick to get this combination to work was to REMOVE the inverting of the toggleAllNormkategorienState from the toggleAllNormkategorien method. So, with that super-creative combination, it seems to WORK!!! Still need to a bit more testing to be 100% sure.

Thanks a lot for your always competent and quick help.

I compared your code again with mine, and have been able to find the cause why my q-table did not show up as “dense”. It was kind of a user error: I had put “dense” attributes on all checkboxes in my q-table, but not on the first Quasar related checkbox, which does the selection of a row in the table:

<q-td :auto-width="true">
        <q-checkbox v-model="props.selected" dense />
 </q-td>

With that “dense” property on the row selection checkbox and “dense” properties on all other checkboxes, my table is now “dense” as well:

@metalsadman - thanks a lot, I would not have caught the root cause without your Codepen!

I figured it out, but as part of testing, realize that I would prefer such a context menu to select a new node in the tree on the header slot, not the body slot of my q-tree.

In the body slot of my q-tree,

<q-menu touch position context-menu>
  <q-list dense>
    <q-item clickable @click="selectedKeyMyTree = prop.node._id">
      <q-item-section>Select node</q-item-section>
     </q-item>
  </q-list>
</q-menu>

does the above job to change node selection to the node under the context menu.

Is it possible to have such a context menu on the header slot that is able to change the selected node (and also offer some other actions)?

I did one more experiment, and got a context menu also working on the header-slot. Strangely, in the header slot I had to change the code that assigns the new node in the context menu to

<q-item  clickable @click="selectedKeyTreeBaustoffe = node._id">

The code I used in the body slot, if used in the header slot, results in an error that prop and node are undefined:

<q-item  clickable @click="selectedKeyTreeBaustoffe = prop.node._id">

Not sure why this works differently, the API doc looks the same for header and body.

Anyway, my last question is: How can I change the selected node in the context menu and subsequently trigger some other method when the user right clicks the context menu?

@FrankM - agree completely. Web sockets (compared to push notfications/service workers):

• are more powerful, given the richness of the socket.io API (except this “notify disconnected users” which is not important to me)

• are easier to set up

• can be used with http for dev environments

• can be easily integrated with Quasar. I now put the web socket setup into a Quasar boot file, so I have them available in all components through $socket.

• are not dependent on experimental browser functions (push notifications still are classified “experimental”, afaik)

Thanks for your advise.

To add an icon after the label in the header of a QTree node, you need to use a header v-slot for your q-tree:

Sample: https://codepen.io/mickey58/pen/wvzYgbO?editors=1010

Docs: https://quasar.dev/vue-components/tree#Example--Default-header-and-body-slots

@machadoug - I have given up on using the Auth Token based app extension, as I had too many problems to get it working.

Instead, I changed my code to use JWT with Passport and local Mongoose strategy for authentication. The latter (local Mongoose strategy) is of course only relevant for you, if you use Mongoose at your backend.

The following tutorials helped me:

1. https://chunkbytes.com/2019/02/user-authentication-with-passport-express/
2. https://blog.jscrambler.com/vue-js-authentication-system-with-node-js-backend/
3. https://codebrains.io/add-jwt-authentication-to-an-express-api-with-passport-and-es6/

It required about 1 week of work, as everything was new to me…

@Jordan

The script section of my SPA on Heroku looks like this:

  "scripts": {
    "build": "quasar build",
    "start": "node front-end-server.js",
    "heroku-postbuild": "npm install --only=dev --no-shrinkwrap && npm run build"
  },

@FrankM - agree completely. Web sockets (compared to push notfications/service workers):

• are more powerful, given the richness of the socket.io API (except this “notify disconnected users” which is not important to me)

• are easier to set up

• can be used with http for dev environments

• can be easily integrated with Quasar. I now put the web socket setup into a Quasar boot file, so I have them available in all components through $socket.

• are not dependent on experimental browser functions (push notifications still are classified “experimental”, afaik)

Thanks for your advise.

@dobbel - thanks, good hint. It looks like I hadn’t seen the forest (frontend solution) for the trees (socket APIs at the backend).

@dobbel, @FrankM - I have now prototyped web sockets. Using socket.io on backend and frontend. The code is much simpler than the code for push notifications. And web sockets are easier to integrate with Quasar, because you can listen and handle socket events triggered by the backend in the frontend main component code (my-layout.vue) and directly react to such a socket event e.g. through a Quasar QNotify notification with a refresh action.

The only little caveat I have with these web sockets is this: It looks like it is not straightforward to exclude the client that created the new content from a “new content” notification. There is a so called “broadcast” feature in socket.io which excludes the “initiator”, but, unless I misunderstand the concept, the “initiator” is always the backend server, and it is up to the programmer to relate it to a user on a client, and exclude that client from the notfication. Not sure yet how to do that with web sockets.

@dobbel - thanks, Workbox is one of those powerful PWA specific features that aren’t available yet to me because I’m still reluctant to make the move from SPA to PWA

@dobbel, yes, I see an app.use for a service worker in the code at https://github.com/smolinari/quasar-docs/blob/master/src-ssr/index.js, but couldn’t find the service-worker.js itself yet.

@dobbel - yes, I had overlooked initially that these push notifications are from server to individual clients. If you want them for all clients, it is on you to to loop through all subscriptions and send push messages to every single client.

I think @FrankM 's solution is the most powerful one, but probably even more complicated than my prototype for push notifications (which needs web-push package on the server).

I hope web sockets can do what I need.

@metalsadman - do you happen to know how Quasar has implemented the notifications that new content is available on the Quasar docs site?

@FrankM, @dobbel - I have been prototpying push notifications for my existing SPA app.

It has been a bit tedious to set everything up, but I got it working. It consists of 3 pieces:

• Registering a service worker and subscribing to push notifications - currently this resides in the created() part of my Quasar main layout (my-layout.vue)
• Service worker - I placed this temporarily in the /statics folder of my frontend code. This piece of code receives the push notifcations and does showNotification()
• Backend code: This piece of code is still experimental, it fires a push notification using the NPM web-push package

I got the overall mechanics working.

I’m a bit disappointed to learn that it is only for a single user. In order to notify all or selected groups of users, the subscription details would have to be stored for every user in my backend database. In order to notify all users, I would have to iterate through these details and create a push notification for every user.

This web push mechanism is pretty complicated for what it delivers.

I will probably experiment next with web sockets,