[Blazor] Cascading RouteData in Layout causes OnInitializedAsync to be called twice when navigating to another Layout

[Charnock]

Describe the bug

When navigating between pages with two different layouts, if the page you're navigating from has a CascadingParameter for RouteData, OnInitializedAsync will be called twice on the page you're navigating to.

To Reproduce

I've included a minimal repro here. I've added logging to OnInitializedAsync of the Index, Counter, and Fetch Data pages.

• Start the project and navigate from the Index page to the Counter page.
• Then navigate from Counter to either the Index or Fetch Data
• Observe that OnInitializedAsync is called twice for Index or Fetch Data

This behavior does not occur when Navigating between Index and Fetch Data.

Additionally, I've commented out a second CascadingValue in App.razor which cascades a string. Uncommenting that CascadingValue appears to resolve the issue, even when that value isn't being used on any of the pages. Also, only using the cascading string doesn't appear to reproduce the issue.

Further technical details

.NET Core SDK (reflecting any global.json):
Version: 3.1.300-preview-015048
Commit: 13f19b4682

Runtime Environment:
OS Name: Windows
OS Version: 10.0.18362
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.300-preview-015048\

Host (useful for support):
Version: 3.1.3
Commit: 4a9f85e9f8

Microsoft Visual Studio Community 2019
Version 16.5.3

[captainsafia]

Thanks for posting the issue and providing the repro, @Charnock!

I was able to reproduce the same behavior you saw. There's some funkiness with how the cascading parameter after the processing of the components. The component is initialized before the layout and the re-initialized again after the layout is initialized.

| Switch page | --> | Initialize FetchData |--> | Initialize MainLayout |  --> | Initialize FetchData |

As opposed to

| Switch page | -->  | Initialize MainLayout |  --> | Initialize FetchData |

Marking this as a bug for now. I suspect that we will have to look into the logic in the CascadingValue component a little bit closer.

[dazinator]

Just a hit a similar problem, we were navigating from a page with a non default layout, to one that was missing the layout directive (and so using the default layout), and seeing OnInitAsync called twice, in a blazor wasm application.

We didn't use cascaded values on either page, but we do have a cascaded value surrounding the app.

[ghost]

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.

[jofford]

The title is also misleading because it doesn't call OnInitializedAsync twice, it constructs two separate components and calls OnInitialized once on each.

Any updates or workarounds for this? This is a major flaw considering most data is retrieved during OnInitialized and there's no way of knowing if it's the duplicate component.

[jofford]

Here's a minimal sample to prove duplicate components are being created by Blazor.
https://github.com/jofford/BlazorWasmRouteDataBug

[jofford]

This workaround appears to fix the issue.
https://stackoverflow.com/questions/70716550/blazor-wasm-navigation-away-from-layout-using-routedata-creates-duplicate-comp/70758615#70758615

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 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.

[javiercn]

Tracking in #44781