Closed linkdotnet closed 6 months ago
It seems DisposeComponents should be async going forward, indicating the awaiting is possible, and then await by default. If folks want to skip awaiting, they simply do not await the returned task.
That said, I think it may be wasteful to always store tasks in the list in the renderer. I have been considering a change that affects other things, but also this:
Have RenderedComponent
inherit from ComponentState, and override the CreateComponentState returning our RenderedComponent
.
It seems to give us several benefits, i.e. more direct access to the component tree, no additional type needed to capture details about rendered component, access to the components DisposeAsync with option of overriding it.
It does also expose a bunch of properties from the pubternal stuff in Blazor's ComponentState type, which may be confusing to bUnit users, in particular:
It could also be a problem if users call DisposeAsync()
expecting it to be correctly disposed, when that method should probably only be called by the renderer.
Unfinished thoughts. Let me know what you think.
It seems DisposeComponents should be async going forward, indicating the awaiting is possible, and then await by default. If folks want to skip awaiting, they simply do not await the returned task.
That is fair for me.
Have RenderedComponent inherit from ComponentState, and override the CreateComponentState returning our RenderedComponent.
At first sight, it could bring some advantages (not for this feature, though. Unfortunately also, here, a lot of the stuff is internal.
This Pull Request tackles and closes #1232
The idea is to hook into the queue and "collect" the disposal tasks in our renderer. I would like your opinion on the API design. I went back and forth and settled on the current shape (with an optional boolean flag).