Why? The PWA offline capability is broken because of this.
How? Here's a step by step UX example:
- A user lands on an offline capable Blazor WebApp through their usual browser
- The user starts interacting with the WebApp without reaching yet any page/component that does use the libraries components/DI
- Suddenly the user doesn't have any internet connection, but it's not a problem, the WebApp has cached so far what it does need to resolve
*.jslibraries(and other assets) from the cache
- (offline) The user reaches a part of the WebApp that does rely on the library that does dynamically load JS modules
- (offline) The WebApp breaks, DI is broken, components break everywhere, the offline experience is broken and the user leaves the WebApp unhappy
serviceWorker is used to cache all the necessary framework resources/assets so when there's no network the locally cached resources/assets can be used and the web app can continue to work, more or less feature-full, as if it's still online, making it behave more as an actual app than simple website.
When runtime importing/loading comes into play and the web app didn't reach that point of use of that library then the call for
import will fail given that there's no connection, and you leave the user with less features or simply a breaking app.
If you offer offline capabilities in your web app the main simple solution that worked for me is to simply disable the actions/pages/modals that trigger the DI(dependency injection) of the components that rely on this offline uncapable libraries ¯\_(ツ)_/¯
Quite a turn-off for the end user but better than unleashing hell and leave the web app in a broken or unstable state.
Coming from Blazor WebAssembly the runtime loading/importing of libraries seems like a nice optimization from the point of view of less bandwidth needed and quicker first time web app loading but for me I find the user-experience coming first, and leaving those features blocked or disabled when they could be totally fine offline is a loss.
[Update] I figured out that there's a workaround and it can be possible to load those libraries without the need to change the external libraries, just put the js module as a normal module script in the
index.html like belowe and you're good to go!
<script src="_content/Some.Blazor.Library/jsFunctions.js" type="module"></script>
Unfortunately there are out there libraries that use quite many modules without putting all of them in the documentation, so here goes your free chore to source code scavenging for
*.js import references that could've been totally avoidable in primis.