[Blazor WASM] Don't apply hot reload deltas if Blazor has not been initialized #33122
Conversation
ghost
added
Area-AspNetCore
|
Thanks for your PR, @MackinnonBuck. |
| .then(response => { | ||
| if (response.status == 200) { | ||
| const etag = response.headers['etag']; | ||
| window.sessionStorage.setItem('blazor-webasssembly-cache', { etag, deltas }); |
There was a problem hiding this comment.
There was an extra 's' here, meaning we never used the cached hot reload deltas 🙃
Even with this fix, the caching mechanism is broken because session storage stores its values as strings. So we'll need to stringify the deltas here and parse them when they get read back in.
There was a problem hiding this comment.
Opened https://github.com/dotnet/sdk/issues/33123 to track this.
There was a problem hiding this comment.
Good catch. I'm surprised this has lived for so long. I'm now desperately waiting for the next fix which should hopefully give noticeable perf boost.
mkArtakMSFT
left a comment
mkArtakMSFT
left a comment
There was a problem hiding this comment.
Thanks @MackinnonBuck!
Do we have to backport this change now to .NET 7 & 6 ?
|
@mkArtakMSFT Yes, this should probably be backported. I'll go ahead and do that. |
[Blazor WASM] Don't apply hot reload deltas if Blazor has not been initialized
Fixes an issue where if Blazor hot reload deltas are received before Blazor is initialized, hot reload fails. VS interprets this case as a fatal error, requiring the customer to restart the app to get hot reload working again.
Description
This fix works by added a check to see if
window.Blazor._internal.applyHotReloadis defined before attempting to apply hot reload deltas. Upon first glance, it might seem that this means Blazor won't ever receive the skipped deltas, but this is not the case because Blazor applies all existing deltas after it boots.Another possible fix for this would be for VS to not interpret the "delta not applied" case as fatal. However, I think it's preferable to apply the fix in
WebSocketScriptInjection.jsbecause there still might be cases where exceptions thrown from Blazor's JS implementation are "fatal" in nature. I think it's natural forWebSocketScriptInjection.jsto differentiate between cases where deltas were intentionally skipped vs. deltas could not be applied.We could alternatively report the "skipped" case differently from the "success" case so that we can get insight via telemetry about how often this happens.
Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1779975