LostBeard / SpawnDev.BlazorJS

Full Blazor WebAssembly and Javascript Interop with multithreading via WebWorkers
https://blazorjs.spawndev.com
MIT License
78 stars 6 forks source link

workerService.GetWebWorker() seems to reload the whole application #4

Closed Martin521 closed 1 year ago

Martin521 commented 1 year ago

Is that intended / necessary?

Martin521 commented 1 year ago

I see it doesn't do that in your demo. So I guess the problem is on my side.

LostBeard commented 1 year ago

No, the web page should not reload. I am willing to look at the problem if you can make a small project that reproduces the issue.

Martin521 commented 1 year ago

That would be great. It is F# though, based on Bolero. I took the Bolero demo, as contained in their dotnet new template and tried to add a WebWorker service. https://github.com/Martin521/WorkerTest

LostBeard commented 1 year ago

lol Wow. F#. Never used it... Always fun trying something new... 😃

So I loaded your project and clicked the + button on the Counter page (seems to be where you are testing the worker) and it loaded the worker and ran without reloading the page. I'm including the last few lines from my console output below.

blazor.webassembly.js:1 computing  
spawndev.blazorjs.webworkers.js?verbose=true:53 has DedicatedWorkerGlobalScope JSInterop  
spawndev.blazorjs.webworkers.js?verbose=true:53 has DedicatedWorkerGlobalScope DotNet  
blazor.webassembly.js:1 done  

Did I miss something? I will admit, I am having a little bit of a tough time following F#. I'm trying to spot something that might cause what you are seeing.

Martin521 commented 1 year ago

I don't see a visible page reload. But the console log says ( bit further up) blazor.webassembly.js:1 blazor Loaded 11.04 MB and I see those 11 MB going through the network.

Martin521 commented 1 year ago

If you remove the verbose flag from the GetWebWorker call, there is less clutter in the log.

LostBeard commented 1 year ago

Ah. You are seeing the output from the WebWorker you are starting. That is expected behavior. The app is loaded in the WebWorker in a similar way to how it is on the main page. Except no page rendering code is ran, it is bypassed in the BlazorJSRunAsync() call when running in a Worker context. The WebWorker shares the console with the main window. SharedWebWorkers do not share the console with the main window.

Yes, the verbose flag enables the worker startup logging. I may remove it at some point.

Martin521 commented 1 year ago

Ah, I understand. So the code is not shared between the app and the worker. I will see if the extra network traffic will be a problem for my app. Thanks for looking into it! And BTW I am still wondering why I don't see that blazor loaded message on your demo page. Maybe it is done in Bolero.

Martin521 commented 1 year ago

Yes, the verbose flag enables the worker startup logging. I may remove it at some point.

That's fine. I just meant the flag that I set as an argument when calling GetWebWorker(true, true).

LostBeard commented 1 year ago

"And BTW I am still wondering why I don't see that blazor loaded message on your demo page."

It is a debug message. The demo page is a release build.

"Thanks for looking into it!"

Not a problem. Glad to help!

LostBeard commented 1 year ago

"That's fine. I just meant the flag that I set as an argument when calling GetWebWorker(true, true)."

lol I honestly wasn't sure what you meant. I need another coffee lol.

"I will see if the extra network traffic will be a problem for my app."

I was about to say the browsers cache system should prevent redownloading but then I remembered I had used 'no-cache' in the worker loader. I will look into getting cache working.

Martin521 commented 1 year ago

Great. This is awesome stuff. I will let you know when I get it working in my larger project.