bUnit-dev / bUnit

bUnit is a testing library for Blazor components that make tests look, feel, and runs like regular unit tests. bUnit makes it easy to render and control a component under test’s life-cycle, pass parameter and inject services into it, trigger event handlers, and verify the rendered markup from the component using a built-in semantic HTML comparer.
https://bunit.dev
MIT License
1.12k stars 104 forks source link

feat: Add flag to actively wait for async disposal #1415

Closed linkdotnet closed 6 months ago

linkdotnet commented 6 months ago

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).

egil commented 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.

linkdotnet commented 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 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.