[✨] add serviceWorker$ about qwik

[seanperez-xyz]

like take a class for example... I cant serialize this class across $ boundries... and I dont need this class or module to run right now... but I do need it to run eventually... i can defer it , or like party-town I can just dump it to ?? some random fault ,,, and scoop it up later... but we already HAVE the service worker already its already doing things... but at the same time that its doing things it can do alllot more things... its no like the service worker is any different than any other thread...
it can pump out just as much work as any other thread... the key is not clogging up the main thread which is the UX ... but now think about the class barrier problem , its not that the class cant be broken across the $ barrier because I can make a type of string and call it type MyStringType= string;... and its going to complain ( bad example) but not really because all the web3 stuff complains because of a custom Hex type it cant serialize between that... for whatever reason... ( its a lint or w/e debacle) but they are both just strings

so the idea is okay forget about the hard part of figuring all that out ... lets just let the service worker to do it for us

class MyClass ... constructor...

its not going to serialize and there are 10000000s of libs like this that people spend 10000 of hours making but we cant use them in qwik ( we can the opt easy out no serialize method and useVisibleTask method ... but whats the point then...

but if we use the service worker it can hold alll that and it can hold it all in a stateful manner""

the page can change but the scope to the service worker doesn't
so it can run all that class madness back there in that thread.. while still being scoped to signals and all the serialized methods qwik uses, the difference is the SSR is not SSR but SWSR

[serbyxp]

• side note of the thought process
  how ever the server side handles QRL stuff needs to be “cloned” down to the service worker

so when the build happens you get a map with all the QRLs : chunks so anything in the serviceWorker$ would need to be parsed a second time to make a sub node with its own QRL : chunks

QRL/chunk1.js
Qrl/chunk2.js
QRL/swchunk1.js
…
swchunk1.js …
swchunk1/QRL/chunk3.js
swchunk1/QRL/chunk4.js

something along those lines, that it has its own map for what chunks it needs to handle..

I think by doing it in such a way would…
Create a ref or callback ref to the service-worker and more specifically the function that called it

This can lead to more exciting things like having the service worker act like a shared worker

ie executing more worker$ from the service-worker itself

serviceWorker$(worker$()=>…)

serviceWorker$(server$()=>…)

<input bind:value={z} />
<input bind:value={y} />
<button type=“submit” onClick$={[
  serviceWorker$(()=> {
    return y.value + z.value
  }),
  server$((x) => {
    return db.insert().values(x)
        return notification(x + “saved successfully“)
  }),
  // do a thing
]}>submit</button>

[JerryWu1234]

@PatrickJS
Maybe I can pick this.
looks a bit complicate,

[gioboa]

This is an enhancement, the service worker story is changed during this month
Here is the new implementation
The output to solve this issue should be a cookbook example and not a new core API.
@JerryWu1234 feel free to play with this. Thanks

[gioboa]

You can take inspiration from qwik-worker

[PatrickJS]

yeah @JerryWu1234 feel free to experiment. I was thinking we can pass make a fetch request and in the service worker detect this and run the code in service-worker and return the results rather than returning the code. I was planning on experimenting with this in a week or so but if you want to try then I'll be happy to help 🙏

[PatrickJS]

it would be better to have this which is similar to server$ but worker$ might be closer

const getDataFromServiceWorker = serviceWorker$((args) => {
  // do a thing
  return data
});

<button
  onClick$=[
    $(() => {

      const data = await getDataFromServiceWorker(args)
    })
  ]}
>
  Click
</button>

[seanperez-xyz]

You can take inspiration from qwik-worker

yeah the qwik worker$ last time i saw it did something similar... of event$
that is has a first arg and returns another function... ( if i remember correct)
...

but the worker$ is fine it can work universally ...
the only thing I remember * was that worker$ was using a ref off the q:container?? to "message"
but if we hone it down... that yes random worker$ ref whatever to spawn a new worker...
but IF qwik-city is the micro framework for routing THEN hook into that instead of q:container (or w.e it is) but thats not good enough... as worker$ should / could be worker$({...}:{type:'service-worker" | "worker" | "shared"; port?; , client?; etc..?; }

similar to worker$ it autos to q:container ?? as its ref, but for service-worker it refs off the qwik-city service-worker ? qwik-city[sw] : q:container

[seanperez-xyz]

its hard to explain, like if there is qwik city and there is a qwik city service-worker (throw it on there )... unless its specified to put it on a specific "port" or "client"or worker which behind the scenes would be an object of | worker , service-worker, shared-worker | whatever it is in "worker" lingo

so... its not changing anything to how it works now. its hooking into how it works now, and inject it as a ref based on the object its referencing

but all that has to happen behind the scenes ...

this is not helpful at all for normal I want to add this or that... but its helpful if I want to add a
"web API" like transitions or streaming API , storage API ( only one that works on main and worker threads is ? indexDB ? )... but its not so much yes I can add this to service-worker.ts but how can it be injected into the optimization process so that it can be a QRL in itself...
( QRL is handled by the service worker right... but a QRL that runs on the service worker) ... it can* fetch its own chunks/ bundles to run before the bundle needs to be fetched... its exactly what its doing now but a pre pre fetch that if you use the party-town method could be a pre-fetch to huge amounts of class methods that can serialize themselves in the background...( while streaming new qrl in..)

[seanperez-xyz]

probably should copywrite that SWSR ... thats the extra$ for the sause$

[serbyxp]

You can take inspiration from qwik-worker

Like worker$ is great as I mentioned serviceWorker$ doesn’t need to exist it worker$ just gets an “upgrade” to reference the type of worker and give it a name to reference it in other files, or if the service-worker from qwik-city is in the scaffold that it gets imported to it

But right now as it is worker$ can be used, if for example you have a section of code that is no serialize | has the issue with a lot of class methods , if you get

const serializedOnWorkerData = worker$(() => // implement class methods | no serialize here
);

now you got serializedOnWorkerData to pass around, the problem with plain “workers” vs “service-workers” is there life cycle it closed with the tab page scope changes so it needs to be re executed, so holding state there while navigating might not be ideal. But on the service-worker as you navigate the scope doesn’t change so any objects that were created there can be referenced still?

• just realized I’m logged in on a different GitHub account on my phone -Sean

— edit +
technically what can be done is you make a store, signal, and or context in the main thread where the data you get from the workers gets stored in like normal, so for example if the worker is calculating in the background and sends new data the on message or fetch listener can be ignored ? Since the data is going into the signal / store ? Which would trigger the re render of that component ?