Blazor: OnInitializedAsync with prerendering

[JDBarndt]

This was already mentioned in #13607, #14977, and #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 dotnet/AspNetCore.Docs#15271

[schmitch]

actually I'm not sure that the following is true:

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.

from logging the output the following happens:

1. data get's prerendered on the server
2. browser paints the prerendered data
3. the websocket connection forces a rerender.

Actually It's also really simple to debug. Just remove the <script> tag. and the OnInitialized, will only be called once with RenderMode.ServerPrerendered. Thus it is a bug.
Your description also does not make any sense, since Blazor actually won't know if it should rerender before the script tag gets executed (which in most cases, if it is at the end) happens after html is rendered.

--

this is somehow stupid, since the websocket connection is stateful. I would understand if everything with blazor is not stateful. unfortunatly the re-rendering is kinda something that makes no sense and there is also no way to work around it.

What should happen (if Blazor wants to be useful):

1. Prerender
2. Browser renders the component with an id
3. the id gets passed to the websocket
4. everything is retained (no double initialization)

btw. before 3.1 hits blazor is already kinda broken, with 3.1 this issue gets relaxed, by the fact that I can actually add parameters to the component which is a work around. but not a solution.

There are many JS/Typescript frameworks with prerendering and none of them has the same issue that blazor has. most of them are stateless, thus you need to actually put a variable with the complete state into your html. Blazor is stateful, it should not have had this problem in the first place.

---

Sorry if my tone is not correct, since I'm really sad because Blazor is such a great idea and even if the end design decision are good (Html.RenderComponentAsync, RenderMode.ServerPrerendered) they have some really bad flaws (this, #14433) that will hinder adoption.

Also this is not solved by adding something to the docs. It would be even more cringe if doing that.

[javiercn]

Actually It's also really simple to debug. Just remove the <script> tag. and the OnInitialized, will only be called once with RenderMode.ServerPrerendered. Thus it is a bug.
Your description also does not make any sense, since Blazor actually won't know if it should rerender before the script tag gets executed (which in most cases, if it is at the end) happens after html is rendered.

When the app is being prerendered it gets initialized and torn down after producing the HTML and then the client starts up a new application. You can validate this by implementing IDisposable on your root component and putting a break point on it, and you'll see how it gets called after the content has been prerendered.

You don't get a websocket connection until after the initial render of the page has happened and the SignalR connection gets initialized. Is at that point where the app gets started again and becomes stateful.

The goal of prerendering is not to reduce service calls, it is to render content for the user faster. If you want to reduce expensive service calls, use a cache.

What should happen (if Blazor wants to be useful):

1. Prerender
2. Browser renders the component with an id
3. the id gets passed to the websocket
4. everything is retained (no double initialization)

btw. before 3.1 hits blazor is already kinda broken, with 3.1 this issue gets relaxed, by the fact that I can actually add parameters to the component which is a work around. but not a solution.

Things are not that simple and every solution has trade-offs. We used to do it that way and we switched to the current approach. You can read the details on some of the challenges it involves here:
#12245 (comment)

[schmitch]

well if it is that challenging, to do it with a stateful approach, why not at least try to go the redux/react way. Stateful Prerender and preserving the state inside a:

<script>
          // WARNING: See the following for security issues around embedding JSON in HTML:
          // http://redux.js.org/recipes/ServerRendering.html#security-considerations
          window.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState).replace(
            /</g,
            '\\u003c'
          )}
        </script>

in 99.9% of scenarios people would prefer that over double initialization or something that is extremly hard (caching), it could even be configurable.

[javiercn]

On server-side blazor it is simpler and better to use the in memory cache for that.

• It avoids rountripping the state.
• It can be combined with a react/redux approach where you simply pass an id for the store and put the store in a memory cache with the id, which is then used to retrieve the store when the app reconnects and to produce an identical render to the one it was prerendered.

As an example below is a modified WeatherService that shows that it causes no flickering.

        public WeatherForecastService(IMemoryCache memoryCache)
        {
            MemoryCache = memoryCache;
        }
        
        public IMemoryCache MemoryCache { get; }

        public Task<WeatherForecast[]> GetForecastAsync(DateTime startDate)
        {
            return MemoryCache.GetOrCreateAsync(startDate, async e =>
             {
                 e.SetOptions(new MemoryCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromSeconds(30) });
                 var rng = new Random();
                 await Task.Delay(TimeSpan.FromSeconds(10));
                 return Enumerable.Range(1, 5).Select(index => new WeatherForecast
                 {
                     Date = startDate.AddDays(index),
                     TemperatureC = rng.Next(-20, 55),
                     Summary = Summaries[rng.Next(Summaries.Length)]
                 }).ToArray();
             });
        }

        private static readonly string[] Summaries = new[]
        {
            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
        };

[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 <notifications@github.com>:  Closed #15266<#15266>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#15266>, or unsubscribe<https://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?