LostBeard
commented
8 months ago I have references I need to use that rely on IJSRuntime in the scope. Code that relies on IJSRuntime seems to fail and/or work in a different sand box than the rest of the website. Any insight into this or workarounds wasm apps?
IJSRuntime works exactly the same in a WebWorker context as it does in a Window context. I recommend you do some reading on Web Workers on MDN to get a better idea of what the limitations and differences are between the 2 contexts.
Example would be using Blazored.LocalStorage within a SpawnDev Web Worker.
localStorage is only available in a Window context and not in a Web Worker. Blazor WASM follows the same rules and limitations as Javascript. Using a storage layer like Cache or IndexedDB is a good alternative to localStorage as they are both available in Web Workers and Window contexts.
When I write to storage it will be wiped with the service, after the service is disposed.
No data is wiped. localStorage simply is not available in a Web Worker in Javascript. If it is not available to Javascript it is also not available to Blazor WASM.
This may be a bit confusing if you do not have much experience working with Web Workers in Javascript. I personally use MDN for a lot of my research. Hopefully it can help you also.
If you have any more questions let me know.
jbrown29
I have references I need to use that rely on IJSRuntime in the scope. Code that relies on IJSRuntime seems to fail and/or work in a different sand box than the rest of the website. Any insight into this or workarounds wasm apps?
Example would be using Blazored.LocalStorage within a SpawnDev Web Worker. When I write to storage it will be wiped with the service, after the service is disposed.