Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared BunitContext, one BunitRenderer per Render() call #1018

Closed
Tracked by #962
egil opened this issue Mar 6, 2023 · 0 comments
Closed
Tracked by #962

Shared BunitContext, one BunitRenderer per Render() call #1018

egil opened this issue Mar 6, 2023 · 0 comments
Milestone

Comments

@egil
Copy link
Member

egil commented Mar 6, 2023

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

RenderAsync(
  @<text>
    <FirstComponent />
    <SecondComponent />
  </text>);

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant