Additional loading indicator scenarios #35126
Conversation
|
@guardrex I am a bit unsure about the example. How would |
|
Yes ... that's right. 🤔 I think Javier must be suggesting that a JS initializer be used ... or some approach involving Still tho ... even if that's the case ... I think what I did isn't bad for displaying a loading indicator while long-running work is taking place after the app loads. It also dovetails with what we show for kicking off long-running cancelable background work. |
|
I've moved the post-runtime-loading approach to the Cancelable background work section in the Lifecycle article, where it most appropriately goes. I left a placeholder in the Startup article for a JS initializer (or |
|
BTW ... Even if I don't hear back from Javier, I'll take a shot at it with a JS initializer-based approach. I do have a vague idea how it might work that way to immediately show a loading indicator while the WebAssembly .NET app/runtime bundle comes down and the app starts. I'll see if I can get back to this by EOD ... but if not, I'll see if I can work it out tomorrow (Friday) morning. |
🦆This looks good using a JS initializer approach ...
export function beforeWebStart(options) {
var progress = document.createElement("progress");
progress.id = 'progressBar';
progress.ariaLabel = 'Blazor loading…';
progress.style = 'position:absolute;top:50%;left:50%;margin-right:-50%;transform:translate(-50%,-50%);';
document.body.appendChild(progress);
}
export function afterWebAssemblyStarted(blazor) {
var progress = document.getElementById('progressBar');
progress.remove();
}That one isn't designed to track actual progress, but it would get devs going in the right direction with a progress indicator that updates progress based on boot resources arriving. ANDIt requires the workaround in the <script src="_framework/blazor.web.js" autostart="false"></script>
<script>
Blazor.start({
webAssembly: {}
});
</script>I'll consider if I want to work up a full-blown percentage (%) progress indicator tomorrow morning. In the meantime, give that a try and see what you think. |
🦖 NOTE TO SELF
|
|
@divvjson ... This looks good. I have the following on here ...
... that should do the trick 🐇🎩🪄 for now. I'll read all of this one more time and then merge it. Let me know if you think I missed anything. |
|
I didn't get a clear understanding on why the approach with removing the progress indicator in the |
|
Correct, it's not a good centralized solution to the problem like the However ......I did just notice that the
export function removeIndicator() {
var progress = document.getElementById('progressBar');
progress.remove();
}
@implements IAsyncDisposable
@inject IJSRuntime JS
<Router AppAssembly="typeof(Program).Assembly">
<Found Context="routeData">
<RouteView RouteData="routeData" DefaultLayout="typeof(Layout.MainLayout)" />
<FocusOnNavigate RouteData="routeData" Selector="h1" />
</Found>
</Router>
@code {
private IJSObjectReference? module;
protected async override Task OnAfterRenderAsync(bool firstRender)
{
if (firstRender)
{
module = await JS.InvokeAsync<IJSObjectReference>("import",
"./Routes.razor.js");
await module.InvokeVoidAsync("removeIndicator");
}
}
async ValueTask IAsyncDisposable.DisposeAsync()
{
if (module is not null)
{
try
{
await module.DisposeAsync();
}
catch (JSDisconnectedException)
{
}
}
}
}I think I'll mention both in the issue and in the article's paragraph. Again, I'd like to take feedback on the use and stability of these before actually placing them into the article. |
|
Cool. Do you need to create |
|
Yes, you must adopt the normal module pattern with The general pattern is covered with the |
|
BTW ... I'm going to change the code example naming away from "progress" bar because all of the examples are really just loading indicators. There won't be actual "progress" displayed with the article's examples. Devs can make their own real "progress" indicators if they want following the client-side boot resource loading guidance with a few lines to update a progress indicator as files come down to the client. |
|
OK ... all good. Thanks for the issue @divvjson. This led to a lot of nice content updates and additions. I'll merge this into the live doc set immediately, and it should appear on the live site within ten or twenty minutes. FYI @Rick-Anderson @wadepickett ... I'm also fixing in passing here a bunch of broken Azure Redis Cache cross-links ( |
Fixes #35111
Addresses dotnet/aspnetcore#49056
Thanks @divvjson! 🚀 ... I'll leave this up overnight to give you a chance to compare notes with what you may have done based on Javier's advice and what I came up with. The scenario that you're working with on the DIFF is in the Global Interactive WebAssembly rendering without prerendering section.
Internal previews