flicker when first load

[akhmadhamzahs]

I don't think this is issue, but some people even my client think is it. When access page for first time, this page will refresh automatically like flicker. when i check at console there's something calling endpoint "/_auth/me".

https://github.com/user-attachments/assets/61a97a74-b861-48f3-9699-5b73fce54848

[arika0093]

I also encountered this issue, so I investigated it. The result shows that flickering occurs due to the following causes.

Conditions

• Blazor Server + Interactive application
• Using AuthorizeRouteView
• Using a layout other than the default layout (MainLayout) specified in Routes.razor

Behavior

Consider the case where we attempt to display a LoginPage using a BlankLayout.

1. The initially rendered LoginPage is displayed first
2. Authentication status verification begins
3. During verification, the AuthorizeRouteView's <Authorizing> is rendered “in the standard layout”
4. JavaScript from Blazor.Auth calls the authentication API /_auth/me from the frontend.
5. Authentication completes, and LoginPage is re-rendered using BlankLayout.

Cause

When performing asynchronous authentication, AuthorizeRouteView displays <Authorizing> until the authentication state is finalized. During this time, <Authorizing> renders using the default layout specified in Routes.razor. Therefore, pages like LoginPage that use a non-default layout will briefly flicker during authentication verification.

Solution

You can prevent <Authorizing> from displaying by initially returning a “temporary” authentication state and updating it to the correct state later. A PR to add this functionality is currently being prepared.

[YuriyDurov]

@arika0093 thank you for the in-depth analysis. I have also been investigating a similar issue in the last few days, but with AuthorizeView instead of AuthorizeRouteView.

I am thinking, an easier solution would be to notify AuthenticationStateProvider's subscribers upon the GetAuthenticationState task completion, instead of its start. This should not have negative effects anywhere else, as far as my understanding goes.

I will try to make the update today and release a new version.

[YuriyDurov]

After some additional consideration, my proposition of changing when the Task<AuthenticationState> cascading value subscribers are being notified seems not to be likely to affect the problem discussed here. It may be worth considering for the future updates, but not in the scope of the issue discussed here.

@arika0093, I am not sure if the solution of returning a dummy AuthenticationState is a great solution either. IMO, the AuthenticationStateProvider is the one expressing a completely reasonable behavior here, while the AuthorizeView/AuthorizeRouteView are the ones who are more "in the wrong" here.

To me, changing the AuthenticationStateProvider's behavior just to better accommodate "upper layers" being unreasonable, seems unintuitive and disruptive. However, I do not disagree that the problem discussed here is a serious one and is worth looking into. Just trying to figure out if there are better remedies for it.

Considering the aforementioned, I am thinking that maybe having the package provide custom, slightly modified versions of AuthorizeView & AuthorizeRouteView components would be a better, less disruptive solution? These modified components could provide more versatile functionality regarding configuring what they display while the authentication task is being processed.

[arika0093]

Thank you for your reply.

AuthorizeView/AuthorizeRouteView are the ones who are more “in the wrong”

changing the AuthenticationStateProvider's behavior just to better accommodate “upper layers” being unreasonable, seems unintuitive and disruptive

I have no objection to that view. Ideally, the page layout should be rendered even during <Authorizing>, and I agree this proposal is a somewhat hackish fix.

That said, I am curious about how we could provide a custom implementation of <AuthorizeView>. The simplest approach might be to avoid any update processing during authentication? (I'm not sure if that's even possible.)

In any case, thank you for your consideration!

[YuriyDurov]

@arika0093 Glad to see we share the same perspective on this!

It seems like this behavior was introduced to Blazor as part of a somewhat haphazard fix while fixing a different issue of the user being able to see page content before GetAuthenticationStateAsync has finished.

I have tried several things today but none of them have really worked out too well. I am still not exactly sure what the final solution should be, will try to come up with something soon!

Getting back to your proposed idea, I like how it only requires the developer to update the parts related to configuring Blazor.Auth and not changing their actual pages. But the potential for things to go wrong there is big...

I am thinking that, to get what you want, you could trying copying your NotAuthorized content into your AuthorizeRouteView's Authorizing parameter (assemble the content into a component if you want to avoid too much duplication).