QuickGrid has a race condition with disposal during init

[SteveSandersonMS]

Discovered by @kg (thanks!)

QuickGrid's OnAfterRenderAsync logic looks like the following approximation:

protected override async Task OnAfterRenderAsync(bool firstRender)
{
    if (firstRender)
    {
        // First load the module, then call its "init" export
        var jsModule = await JS.InvokeAsync("import", ...);
        await jsModule.InvokeAsync("init", ...);
    }
}

However that logic contains a bug. If the component is disposed while the import async call is in progress, then the continuation will still try to call init, but by now the corresponding DOM elements have been removed so it will result in an error.

The fix is to check if we've already been disposed immediately before calling init, and skip it if so. That would make it not a race condition because the sync context is single-threaded and hence the scheduled init call would necessarily be delivered before any call that would remove the grid from the DOM.

Repro

Make a grid that takes multiple seconds to render (e.g., put Thread.Sleep inside a template column rendering body). While that is in flight, click on a navigation link to go elsewhere in the site. Because the init call still runs, you'll get a console error like:

TypeError: Cannot read properties of null (reading 'tHead')

Thanks for contacting us.

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

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.