Web workers - how to use in Quasar

dobbel

but does this apply to web workers as well as service workers?

I don’t know…

Instead of restarting you could try clearing the site data every time you change the worker file in chrome and then (hard) reload… not ideal but could be faster then app restart.

chrome dev tools -> application > application > Clear storage -> Clear site data

qyloxe

@ssuess said in Web workers - how to use in Quasar:

@qyloxe Another problem I am having is that I have to fully restart quasar dev after every change to my worker file. Hot reloading is happening, but no changes are being picked up…any suggestions there? Thanks!

Yeah, we are just clearing the path with web workers in Quasar. And even Vue. It is advanced technology, magical even, so we will have problems with debugging, testing, developing. I consider web workers as a browser technology not meant for general public, hence the mischievous support between browsers, mystic documentation and labyrinthical code samples. BUT if one will master the obstacles, and build something working in another browser thread, I assume one would achieve … OK I don’t know what will be achieved, because I haven’t achieved it myself ha ha

Anyway, this is a start. I would VERY much want to have a web workers support in Quasar, BUT i do know, that it is a BIG task. So, my proposal is to just include some web workers support in the most data intensive components (q-table, q-tree, etc), and go from there. In the process we will probably learn how to test them, debug them and live with them. What I wanted to achieve with this post, is to create a hunger for inclusion of web workers in Quasar framework

ssuess

Something I just discovered that solves the reload problem for me:

build: {
  parallel: false,
  ...
}

Set this and now when I make changes to my worker.js file, it will properly reload without restart.

qyloxe

@ssuess nice!

ssuess

I wish it was nice, but it only kinda sorta sometimes seems to have an effect. I have wasted most of today trying to get web workers to play nice with quasar, and it has been a bust. There are many issues with this (at least for me):

Random failures to compile. The exact same code will compile and run fine once, then another time not
Missing/non existent/ or useless errors such as failed to compile with 0 errors, so kinda impossible to debug
Exceedingly difficult to configure with quasar.config.js. I have tried chaining, I have tried pushing rules, I have tried comlink, comlink-loader, workerize, worker-loader…none of it works very well. Just when I think I have it working, it fails suddenly.
I can’t find any docs on the web that really fit the use case of quasar with web workers.
The sometimes HMR works, sometimes not dilemma

Giving up for today. Maybe tomorrow will be luckier.

qyloxe

@ssuess said in Web workers - how to use in Quasar:

… useless errors such as failed to compile with 0 errors, so kinda impossible to debug

ach, the lovely passive-aggressive compiler messages. What the life of developer would be, without them?

Giving up for today. Maybe tomorrow will be luckier.

I’m inclined to somehow wait with Quasar till it upgrades to webpack 5. In webpack 5 there’s some kind of support for worker bundling. The idea is from here:

https://github.com/GoogleChromeLabs/worker-plugin

This parallel hack comes probably from here:
https://stackoverflow.com/questions/52086438/cant-use-worker-loader-with-vuejs-and-webpack

And there are some more “hints”, for example, I will definitely try with that:

config.module.rule('js').exclude.add(/\.worker\.js$/)

This also is somehow reassuring, that the guy knows what he writes about:

https://www.programmersought.com/article/3801650530/

Please don’t give up

ssuess

FYI, just added this as a feature request: https://github.com/quasarframework/quasar/issues/7980

qyloxe

@ssuess hmm, I didn’t tested it, but there is this project:

https://github.com/vitejs/vite

There’s even FR for Quasar:

https://github.com/quasarframework/quasar/issues/7815

It looks VERY interesting because it is tightly coupled with Vue. I wouldn’t of course abandon webpack BUT having vite as another devserver/bundler would be very, very nice. Vite is conceptually modern in places where webpack was based on jquery/bootstrap apps. I like that. There’s first class support for web workers and initial support for WASM. Definitely worth looking for.

For Quasar it would be ideal to specify another option in dev/build mode for example:

quasar dev -m spa --devserver=[vite|webpack]

or

quasar build -m spa --bundler=[vite|webpack]

Vite works ONLY with Vue3 so from Quasar perspective it is yet another possible milestone to perfection.

aislan

Right now I’m just struggling with Quasar to place my worker files in another place not in statics folder.
I would like to put them next my actions folder, etc.

Someone knows how to achieve it?

And related to workerize-loader, how could we test them with Jest, for example ?

qyloxe

@aislan said in Web workers - how to use in Quasar:

Right now I’m just struggling with Quasar to place my worker files in another place not in statics folder.
I would like to put them next my actions folder, etc.

with the method described on top, you can put them anywhere - as long as they have an extension .worker.js. The webpack will do his job and properly inline/bundle your code.

And related to workerize-loader, how could we test them with Jest, for example ?

Don’t know carefully??? This should be asked to the author/users group, probably.