Component lifecycle and disposal concepts

[guardrex]

Fixes #32209

Thanks @kjkrum! 🚀 ... I've edited and merged your suggested text with Mackinnon's feedback. It was a busy release cycle for .NET 9 late last year. Sorry that it took a few months to get back to this! 😅

IMPORTANT

• Some of the remarks reference the existing section on IDisposable/IAsyncDisposable. We can take another look at that now (and to make it easy for you to see what it says, here's the link): https://learn.microsoft.com/en-us/aspnet/core/blazor/components/lifecycle?view=aspnetcore-9.0#component-disposal-with-idisposable-and-iasyncdisposable
• BTW ... I feel like we have so much content on this subject (there are NINE subsections to that H2 section) 🐘 that we might want to pull it out of the Lifecycle article into its own dedicated article. I'm asking DR about this offline right now. 👍 Approved by DR! The work is tracked by Move component disposal section into a dedicated article #34883.
• @kjkrum mentioned Invoke in the second paragraph, but I thought it should be InvokeAsync, so I changed it to that. Let me know if it should be reverted back to Invoke.
• I'm mirroring some of the remarks we're adding to the Sync Context article in the Lifecycle article, so you'll need to see if I translated the guidance correctly for the Component initialization (OnInitialized{Async}) and After parameters are set (OnParametersSet{Async}) sections.
• I searched the embedded examples and the sample app examples, and I only have a concern about one example in this section. Please 👀 that example to see if we need to enhance it with a cancellation token.

Noting Mackinnon's feedback here for visibility, which was taken into account for this PR ...

The content that @kjkrum produces appears largely correct, although I don't think it needs to be so detailed. We could probably remove and reword some parts of it, especially some of the more opinionated remarks, such as:

It is strongly recommended that components implementing IDisposable or IAsyncDisposable call async methods using a CancellationToken from a CancellationTokenSource that is canceled when the component is disposed.

This really depends on the scenario. It's up to the component author to determine whether that's the correct behavior. For example, if I'm implementing a SaveButton component that persists some local data to a database, I wouldn't want the changes to be discarded if I click the save button and quickly navigate to another page (which could dispose the component before the asynchronous save completes).

It also looks like the essence of what they're saying is already captured in other places in the docs. For example, this section here explains how OnInitializedAsync may not complete before the component re-renders, so it's important to ensure that the rendering logic accounts for this.

I wonder if it would be sufficient to make a slight change to the existing wording:

Disposal can occur at any time, including before the completion of asynchronous lifecycle events like OnInitializedAsync and OnParametersSetAsync.

I'd be curious if Javier agrees with this, or if he instead thinks we do in fact need more extensive guidance here.

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/blazor/components/lifecycle.md	aspnetcore/blazor/components/lifecycle
aspnetcore/blazor/components/synchronization-context.md	aspnetcore/blazor/components/synchronization-context