Remove/update enhanced nav remark

[guardrex]

Fixes #31117
Addresses #28161

Mackinnon ...

• I don't understand the use case/description for the dev's example in the PU issue. The use case is too contrived to understand the actual business scenario, and the behavior doesn't match the description, namely that OnAfterRender/firstRender does not execute a second time when the SubPage button is clicked.
• WRT the remark that Javier calls out, which seems like an aside from that dev use case, I don't have a replacement in mind for that sentiment. I felt that adding remarks on the relevance (2nd+3rd sentences) made your original remark (1st sentence) meaningful.

Three questions ...

• If you understand what the dev's example is doing and think we're missing coverage, what should we add? Thus far, I don't have anything obvious to add or revise.
• Shall we proceed to remove the paragraph in question? Thus far, the PR removes the whole paragraph.
• WRT Javier's TL;DR remarks, I don't see what that has to do with state passed by parameters during navigation. We cover that subject in detail. We don't say anything in particular about losing parameter state for any type of navigation. What are we missing on that subject, or what's wrong with what we currently have? Let's ping Javier for more information if we need to. Keep in mind that we have an article on state management; so if we want to get into the weeds on state preservation with component params and nav/routing, that's probably a better spot than taking a deep dive into complex subject matter here in the "fundamentals of routing" article. We'd open a new issue for the State Management article and discuss what we should add separately from this PR.

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/blazor/fundamentals/routing.md	ASP.NET Core Blazor routing and navigation

[MackinnonBuck]

Shall we proceed to remove the paragraph in question? Thus far, the PR removes the whole paragraph.

Yeah, that sounds good to me. That scenario was already pretty obscure, so it would probably just create confusion by leaving it in there.

WRT Javier's TL;DR remarks, I don't see what that has to do with state passed by parameters during navigation...

Interactive root component instances can be preserved between enhanced navigations under certain conditions:

• The component stays in the same place on the document between navigations
• And either:
  • The component's parameters are identical between the last and current static server render
  • The component has a @key whose value matches between the last and current static server render

If these conditions are not met, then an interactive component will get disposed when an enhanced navigation occurs.

The customer in the linked issue was experiencing their interactive page component losing state (getting disposed and re-initialized) because their component read from route parameters. Since the component's parameters changed between enhanced navigations, the interactive component instance got disposed and a new one got initialized in its place.

The workaround I suggested to them was to not mark the page as interactive, but define a separate interactive component rendered by a static page, and specify a constant @key for it so its state gets preserved. However, I would suggest we don't document this until we get feedback that this is a common requirement for customers.

If you understand what the dev's example is doing and think we're missing coverage, what should we add? Thus far, I don't have anything obvious to add or revise.

I don't think we need to add anything specific for the customer's scenario. If we start getting feedback that there's a common need to be able to preserve a page component instance as its route parameters change, we can document it.

[guardrex]

However, I would suggest we don't document this until we get feedback that this is a common requirement for customers.

I don't think we need to add anything specific for the customer's scenario.

Very well. At least now, we have your remarks here and on their issue. If we need to cover this later, it will be easy to address.