Blazor: OnInitializedAsync with prerendering
See original GitHub issueThis 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!
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:10 (4 by maintainers)
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 #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.
On server-side blazor it is simpler and better to use the in memory cache for that.
As an example below is a modified WeatherService that shows that it causes no flickering.