You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In v1, when a user instantiates a TestContext (v2 this will be named BunitContext), it creates a shared TestRenderer (v2 this will be BunitRenderer), that is used with every call to TestContext.Render(). For v2, I still want a shared BunitContext, but each call to RenderAsync will get its own BunitRenderer instance.
Looking at existing test suites, by far most tests will just have a single call to TestContext.Render() so I don't expect that the overhead of creating a renderer per Render call will have a perf impact for most.
The primary motivation is that a renderer will share a service provider with all components it renders, and that does have some impact on a few things, such as supporting "shallow rendering". My thinking is that when RenderAsync is called on a BunitContext, it creates a new service scope from the service provider it has, such that singleton services are shared between render calls, but scoped services are not.
If users still want to render multiple top-level components, they should just wrap them in a RenderFragment, e.g.:
Another reason to make this switch is that, as far as I can tell, the various Blazor renderer Microsoft has created does this. So while there does not seem to be any negative impact currently, it may be an assumption the Blazor team will leverage in the future.
The text was updated successfully, but these errors were encountered:
In v1, when a user instantiates a
TestContext
(v2 this will be namedBunitContext
), it creates a sharedTestRenderer
(v2 this will beBunitRenderer
), that is used with every call toTestContext.Render()
. For v2, I still want a sharedBunitContext
, but each call toRenderAsync
will get its ownBunitRenderer
instance.Looking at existing test suites, by far most tests will just have a single call to
TestContext.Render()
so I don't expect that the overhead of creating a renderer per Render call will have a perf impact for most.The primary motivation is that a renderer will share a service provider with all components it renders, and that does have some impact on a few things, such as supporting "shallow rendering". My thinking is that when
RenderAsync
is called on aBunitContext
, it creates a new service scope from the service provider it has, such that singleton services are shared between render calls, but scoped services are not.If users still want to render multiple top-level components, they should just wrap them in a RenderFragment, e.g.:
Another reason to make this switch is that, as far as I can tell, the various Blazor renderer Microsoft has created does this. So while there does not seem to be any negative impact currently, it may be an assumption the Blazor team will leverage in the future.
The text was updated successfully, but these errors were encountered: