Create an animation or wait until the subpage is properly loaded in balzor server side

Alerinos commented 1 year ago

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.

Blazor is very fast, if we use asynchronous methods and change a subpage, it's a moment of hop. It works like this: 1.) The website we are on has content 2.) We change the page 3.) Takes us to the page, if it is asynchronous, it remains empty 4.) Loads content asynchronously

Example: https://gyazo.com/5488676de28613ee5660213173f77213 Page:

https://graj.se/Guide/cod-wz2/misja-nawiazanie-kontaktu

Currently I have done this:

model _model = null;

if(model is not null null){

 if(model.Id != Guid.Empty){
  Content
 }else{
  Not found
 }
} else {
  Loading... (Skeleton)
}

Even if we do the skeleton right, it causes an ugly jump with a fast internet connection. With a slow connection (e.g. mobile) the skeleton elements will be displayed nicely

Describe the solution you'd like

There are several solutions, the first one is to make a loading animation for something that is already in wasm.


    <Router>
        <Found Context="routeData">
        </Found>
       <Loading>
       </Loading>
        <NotFound>
        </NotFound>
    </Router>

Another option is not to destroy the state of the previous page until you receive a new result. The best option without maintenance only has one downside. We won't be able to handle the skeleton.

The best option in my opinion is to add a release handler. The system waits until the programmer calls a function that will show the elements of the loaded page. Something like a smoke grenade. You can make an additional limit, if, for example, the method is not triggered within, for example, 3 seconds, the grenade disappears and shows the content of the rendered page.

Let me know what you think, I've already created a few designs for blazor and unfortunately this problem is very annoying when pages are flickering.

Additional context

No response

ghost commented 1 year ago

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

ghost commented 1 year ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

dotnet / aspnetcore