dotnet / dotnet/aspnetcore

Blazor Download Progress Should Take Into Account Bundle Size And Expose Real Download Information

Open
#46,549 3 comments 0 reactions 0 assignees View on GitHub
area-blazor enhancement feature-blazor-wasm
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 10h
Merged PRs (30d)
281

Description

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

I was very excited to see that with .NET 7 Blazor team has introduced download progress. Bundle size is known limitation of Blazor client, nice and informative progress bar is essential for any serious web app to mitigate this problem. To achieve this essential goal our team has to use custom loader. DIY solutions in such sensitive area are quite dangerous - each error or bug in this area means potentially lost customer. Therefore we were about to drop our custom loader with new .NET but soon realised that blazor progress shows completely bogus data.
I don't know how Blazor computes total progress but here's what we encountered with:
Total AOT bundle size is 137 Mb (which is much, but we can put up with) dotnet.wasm occupying the largest part of that:
![Screenshot 2023-02-09 at 11 05 41](https://user-images.githubusercontent.com/3992180/217791641-819de078-5bcf-4740-a6ed-b2665c869500.png)
So, real download progress is 19%, whereas here's what Blazor shows:
![Screenshot 2023-02-09 at 11 09 07](https://user-images.githubusercontent.com/3992180/217792641-b67d5672-25f7-4ef9-bd1e-d1c1f4350fb5.png)

It got stuck at 98% for the rest of 100Mb of download. Such user experience is even worse than indefinite spinner because it misleading that application is frozen and nothing happens at all. At current state I find this feature useless or even harmful.

### Describe the solution you'd like

Bundle download state should be explicitly exposed. Developers should have access via JS to bundle size, total progress, eventually to a flag that progress is not responding.
Ideally all pieces of information related to bundle should be available to developers for providing the best user experience:

- Total bundle size
- Current progress
- Individual item size
- Individual item progress
- Download speed
- Estimated time

### Additional context

_No response_

Contributor guide

Open the contributing guide

Research direction

Start by tracing the existing Blazor download-progress implementation described in the issue, comparing its reported progress with the full AOT bundle download. Done would require an agreed design for exposing accurate bundle and item metrics, including total size, current progress, speed, and estimated time, followed by validation against the reported 98% stall.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
22/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.