Aspnetcore: Blazor: OnInitializedAsync with prerendering

[JDBarndt]

This was already mentioned in https://github.com/aspnet/AspNetCore/issues/13607, https://github.com/aspnet/AspNetCore/issues/14977, and https://github.com/aspnet/AspNetCore/issues/13448. OnInitializedAsync will fire twice, once during pre-rendering and once after the app bootstraps. This is apparently by design.

Is there any recommendation on how to avoid requesting the data for the page/component more than once?

An example of why this could be problematic is with the Blazor demo's weather forecast page:

FetchData.razor:

protected override async Task OnInitializedAsync()
{
    forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
}

When loading into this page with prerendering, you'll see the initial grid loaded with weather data. Then, the app bootstraps and the component re-initializes a second time and sends an updated grid back to the client, replacing the initial grid with a new one. That's easily visible to the end-user because GetForecastAsync returns randomized data.

That particular data set is generated in-memory and has no meaningful performance impact, but if it instead was the result of a database, external API, or other call, you certainly wouldn't want to do that more than once. Obviously caching of some kind can and likely would be a solution, but I'm wondering if there is some other way within Blazor to avoid multiple requests.

I would almost expect that between prerendering and the app bootstrapping, the initial component state is "shared" so that it knows it doesn't have to regenerate, especially after reading https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.0#stateful-reconnection-after-prerendering:

The client reconnects to the server with the same state that was used to prerender the app. If the app's state is still in memory, the component state isn't rerendered after the SignalR connection is established.

Must be missing something here? Thanks!

[javiercn]

@JDBarndt thanks for contacting us.

Unfortunately the doc is obsolete. I've filed an issue to get it fixed.

We understand the scenario and will be looking into ways to improve the situation in the future, whether it is with specific guidance or enhancements to the framework.

The main issue arises because during prerendering the renderer waits until the application has completed the first render to produce the initial HTML, while the renderer tries to produce an initial render and update the UI as soon as possible, resulting normally in a render before the data is present and a render after the data is present.

This is a trade-off between the flash on the UI and making the application interactive. There are ways to design around it, like passing the query results to the component so that upon rendering it again it simply re-renders the cached results.

We could in the future investigate if we can do something to make the initial render on the client wait until the first meaningful content paint at the cost of delaying the app becoming interactive.

I've file this to keep track of the docs issue https://github.com/aspnet/AspNetCore.Docs/issues/15271

[javiercn]

Is there any recommendation on how to avoid requesting the data for the page/component more than once?

For server-side blazor the recommendation is to pass in an identifier that can be used to retrieve the state you want to preserve as a parameter and to use that identifier within your services to cache the state in memory.

[schmitch]

The recommendation, is extremly complex, does not work automatically and also is extremly annoying when combined with authentication. It would be way easier to use the script tag approach (which also works with multiple Servers),
also caching is always the worst solution and will most often lead to more problems than the previous renderer had.
Not sure why it is even a suggestion...

Von meinem iPhone gesendet

Am 23.10.2019 um 17:15 schrieb Javier Calvarro Nelson [e-mail]:



Closed #15266https://github.com/aspnet/AspNetCore/issues/15266.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/15266?email_source=notifications&email_token=AAMQXOOV4JS2LZO3Z7CPKPTQQBTBBA5CNFSM4JDSKTLKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOUMVJV5Y#event-2737478391, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMQXOLRIDJOWJ2ZB7FKM33QQBTBBANCNFSM4JDSKTLA.

[Grauenwolf]

I have been using this to detect pre-rendering:

    /// <summary>
    /// Gets or sets a value indicating whether this instance is connected.
    /// </summary>
    /// <value><c>true</c> if this instance is connected; <c>false</c> if it is pre-rendering.</value>
    protected bool IsConnected { get; set; }

    protected async override Task OnInitializedAsync()
    {
        try
        {
            var result = await JSRuntime.InvokeAsync<bool>("isPreRendering");
            IsConnected = true;
        }
        catch (NullReferenceException)
        {
        }
    }

In my _Host.cshtml file:

<script>
    isPreRendering = () => {
        return false;
    };
</script>

[Karluzo]

@Grauenwolf How to use this to avoid flashing UI when using RenderMode.ServerPrerendered?

[Grauenwolf]

I haven't figured that out yet.

Jonathan Allen
619-933-8527
Scholars of Alcala
scholarsofalcala.org

---

From: Karluzo [e-mail]
Sent: Friday, December 13, 2019 1:22:17 AM
To: aspnet/AspNetCore [e-mail]
Cc: Jonathan Allen [e-mail]; Mention [e-mail]
Subject: Re: [aspnet/AspNetCore] Blazor: OnInitializedAsync with prerendering (#15266)

@Grauenwolfhttps://github.com/Grauenwolf How to use this to avoid flashing UI when using RenderMode.ServerPrerendered?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/AspNetCore/issues/15266?email_source=notifications&email_token=ACRCUTLX53Z3SKOTWUJPPTDQYNH4TA5CNFSM4JDSKTLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGZM4BA#issuecomment-565366276, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACRCUTPDTFFDR7OBCRSDGHTQYNH4TANCNFSM4JDSKTLA.