Components render too many times with SetParametersAndRender

[Jcparkyn]

In certain cases, calls to StateHasChanged behave differently in BUnit than in regular Blazor WASM (I haven't tested server-side, but I'd expect it to have the same problem). This means that components in BUnit render too many times, and RenderCount values in BUnit are often higher than they should actually be. I have observed this when using SetParametersAndRender, but I'm not sure if there are other scenarios where this happens.

This is a problem in my case, because I care a lot about the number of renders, but I have no way to reliably assert the RenderCount in tests.

Example:
Testing this component:

<p>Hello world!</p>

@{
    Console.WriteLine("Rendering RenderCountDemo");
}

@code {

    [Parameter]
    public int X { get; set; }

    protected override void OnParametersSet()
    {
        base.OnParametersSet();
        StateHasChanged();
        StateHasChanged();
        StateHasChanged();
    }
}

With this test:

[Fact]
public void Should_have_correct_RenderCount()
{
    var cut = Render<RenderCountDemo>(@<RenderCountDemo X="1" />);
    cut.SetParametersAndRender(); // This should only trigger one additional render.
    cut.RenderCount.Should().Be(2);
}

Results in this output:

Expected cut.RenderCount to be 2, but found 5

Expected behavior:

The test passes. Using the same component in a Blazor WASM app results in one render each time the parameter changes, but in BUnit I get three (edit: four). This is not just a problem with the "RenderCount" property, the actual render method is being called four times as well (confirmed with a breakpoint).

Version info:

• bUnit version: 1.20.8
• .NET Runtime and Blazor version: .NET 6.0
• OS type and version: Windows 10

Additional context:

I am obviously not calling StateHasChanged() multiple times in succession like the example above, but there are lots of dependencies etc. which can result in redundant calls to StateHasChanged. In a normal Blazor app, the calls would get "batched" into a single render, so long as they occur synchronously.

[egil]

Hi @Jcparkyn,

Thanks for reaching out. We have tried to stabilize bUnit the last few months related to blocking the renderer when triggering asynchronous renders. A side effect of that may be what you are observing here. I will try to replicate and see what options we have.

[egil]

@linkdotnet this is a case we should also support in V2 code path.

[linkdotnet]

By any chance can you elaborate how you counted the render cycles in the WebAssemblyRenderer?

[Jcparkyn]

By any chance can you elaborate how you counted the render cycles in the WebAssemblyRenderer?

I counted the render cycles by using the Console.WriteLine inside the render function (and by counting how many times a breakpoint in the render function was hit). In my case, one line was written to the console each time the component parameter changed.

Here's a minimal repro which can be pasted into the "Empty Blazor Webassembly" template:

RenderCountDemo.razor:

@{
    Console.WriteLine("Rendering RenderCountDemo");
}

X: @X

@code {

    [Parameter]
    public int X { get; set; }

    protected override void OnParametersSet()
    {
        base.OnParametersSet();
        StateHasChanged();
        StateHasChanged();
        StateHasChanged();
    }
}

Index.razor:

@page "/"

<button @onclick="() => count++">Click me</button>

<RenderCountDemo X="count" />

@code {
    int count = 0;
}

I should also mention that the problem occurs in BUnit 1.12.6 as well (that's what I was originally using), so I don't think it was a recent regression.

[egil]

I've tried this locally, and I am not sure what our options are, if any.

My test looked like this:

public class MultipleStateHasChangedInOnParametersSet : ComponentBase
{
  protected override void OnParametersSet()
  {
    base.OnParametersSet();
    StateHasChanged();
    StateHasChanged();
    StateHasChanged();
  }
}

[Fact]
public void Multiple_calls_to_StateHasChanged_from_OnParametersSet()
{
  var cut = RenderComponent<MultipleStateHasChangedInOnParametersSet>();
  cut.RenderCount.ShouldBe(1);
  
  cut.SetParametersAndRender();
  cut.RenderCount.ShouldBe(2); // fails, cut.RenderCount == 5.
}

Some notes:

• During the initial render, e.g. triggered by RenderComponent, the OnParametersSet method is called, and all the StateHasChanged calls are batched up as you say is the normal experience.

• OnParameterSet is also called after cut.SetParametersAndRender() is triggered, however, here each StateHasChanged call runs synchronously through a full render cycle. before returning, and the next one does the same.

  I think this happens because when the first StateHasChanged call is triggered, there is no other ongoing render happening, which the StateHasChanged calls can be batched up with, so the Blazor runtimes prefer to just run everything synchronously if it can. This means that one StateHasChanged call completes after the other, resulting in a full render cycle.

Interestingly, if we trigger an update to parameters in the following way:

@* TriggerChildContentRerenderViaClick.razor *@
<button @onclick="() => counter++">Count = @counter</button>
<MultipleStateHasChangedInOnParametersSet Value="counter" />
@code {
    int counter;
}

public class MultipleStateHasChangedInOnParametersSet : ComponentBase
{
  [Parameter]
  public int Value { get; set; }
  
  protected override void OnParametersSet()
  {
    base.OnParametersSet();
    StateHasChanged();
    StateHasChanged();
    StateHasChanged();
  }
}

[Fact]
public void Multiple_calls_to_StateHasChanged_from_OnParametersSet_with_event_dispatch_render_trigger()
{
  var cut = RenderComponent<TriggerChildContentRerenderViaClick>();
  var child = cut.FindComponent<MultipleStateHasChangedInOnParametersSet>();
  
  child.RenderCount.ShouldBe(1);
  
  cut.Find("button").Click();
  
  child.RenderCount.ShouldBe(2); // this assertion passes
}

The expected number of renders does occur.

So, I think we need to investigate if we can change our cut.Render and cut.SetParametersAndRender methods to behave similarly to what happens when a parent component passes down new parameters to a child component as part of an existing render cycle.

[egil]

Pushed a branch with my (failing tests) for this issue to https://github.com/bUnit-dev/bUnit/tree/bug/1119-Components-render-too-many-times-with-SetParametersAndRender if somebody wants to take a look. Otherwise, I will see what I can do later during the summer.

[Jcparkyn]

Thanks @egil, I think I'll be able to get by with your workaround (or something similar) for now. I'll update this thread if I find anything useful. Here's another workaround that seems to work:

@* RenderCountWrapper.razor *@
@ChildContent
@code {
    [Parameter] public RenderFragment? ChildContent { get; set; }
}

[Fact]
public void Should_have_correct_RenderCount() // passes
{
    var x = 10;
    var cut = Render<RenderCountWrapper>(@<RenderCountWrapper><RenderCountDemo X="x" /></RenderCountWrapper>);
    var component = cut.FindComponent<RenderCountDemo>();
    component.MarkupMatches("X=10");
    x = 20;
    cut.Render();
    component.RenderCount.Should().Be(2);
    component.MarkupMatches("X=20");
}

[linkdotnet]

Pushed a branch with my (failing tests) for this issue to https://github.com/bUnit-dev/bUnit/tree/bug/1119-Components-render-too-many-times-with-SetParametersAndRender if somebody wants to take a look. Otherwise, I will see what I can do later during the summer.

Interesting - will have a look in the upcoming days.

[linkdotnet]

Okay - here the reason for the different behavior between an initial render and a re-render.
The initial render is triggered in our TestRenderer. the Blazor Renderer has the following line:

if (!_isBatchInProgress)
{
    ProcessPendingRender();
}

In AddToRenderQueue. In the initial case _isBatchInProgress is true - therefore all StateHasChanged calls are packed together and only one render cycle happens.

In the second case (i.e. cut.Render() or cut.SetParameteresAndRender()). _isBatchInProgress is false as ProcessRenderQueue is never called. We are calling this directly:

var result = renderedComponent.InvokeAsync(() =>
			renderedComponent.Instance.SetParametersAsync(parameters));

This bypasses ProcessRenderQueue completely. RenderComponent does not do that.

[egil]

That's what I thought, @linkdotnet. Do you see a way we can get around that? Using reflection to flip the _isBatchInProgress before calling renderedComponent.Instance.SetParametersAsync(parameters)?

[linkdotnet]

That's what I thought, @linkdotnet. Do you see a way we can get around that? Using reflection to flip the _isBatchInProgress before calling renderedComponent.Instance.SetParametersAsync(parameters)?

Well I still have to think a bit longer about that, but here is my current view:
Blazor renders in batchmode in @Jcparkyn example. But there is a big difference between the test and:

<p>Hello world!</p>

@{
    Console.WriteLine("Rendering RenderCountDemo");
}

@code {

    [Parameter]
    public int X { get; set; }

    protected override void OnParametersSet()
    {
        base.OnParametersSet();
        StateHasChanged();
        StateHasChanged();
        StateHasChanged();
    }
}

This component gets updated by the parents onclick event. And of course DispatchEventAsync (that is used when event handlers get invoked) will trigger ProcessRenderQueue. So if I would create the test where the parent is the cut and "just" click the button - I also would see only 2 render cycles for the component in question.

That brings me to the point of whether or not this should be "fixed". In a normal Blazor application, you don't have a way to just retrigger the Render method from the RenderHandle (when inheriting from ComponentBase). That we allow this, leads to side-effects. Just for the full picture StateHasChanged also doesn't force a render but more or less informs the renderer that the component would like to be re-rendered.