Add StateHasChanged(async: true) that guarantees never to run synchronously

[arivoir]

The StateHasChanged method is supposed to flag the component to be re-rendered, so if you call this method multiple times from the same call, it should render the component only once.

Actually, this is working ok when the call is performed from a Blazor event callback.

If I have a component names Component1 and the following markup in Index.razor

@page "/"

<Component1 @ref="component1" />
<button class="btn btn-primary" @onclick="UpdateComponent">Update Component (From Blazor)</button>
@code {

    Component1 component1;

    private void UpdateComponent()
    {
        component1.UpdateTheComponent();
    }
}

and the component code is the following

<h3>Component1</h3>

@{
    System.Diagnostics.Debug.WriteLine("ComponentRendered");
}
@code {

    public void UpdateTheComponent()
    {
        for (int i = 0; i < 100; i++)
        {
            StateHasChanged();
        }
    }
}

The text written in the output of visual studio is

"ComponentRendered"

Only one time.

If instead of calling the UpdateTheComponent() method from the Blazor button handler, it is called from JavaScript, the component is updated multiple times.

To call the UpdateTheComponent() method from javascript, I will alter the component to pass the component reference to a JavaScript method.

@inject IJSRuntime JS

<h3>Component1</h3>

<button @ref="button" class="btn btn-primary" onclick="window.Component1.updateComponent(this)">Update Component (From JS)</button>

@{
    System.Diagnostics.Debug.WriteLine("ComponentRendered");
}
@code {
    ElementReference button;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            var ComponentReference = new Component1Reference(this);
            await JS.InvokeVoidAsync("Component1.init", button, DotNetObjectReference.Create(ComponentReference));
        }
    }

    public void UpdateTheComponent()
    {
        for (int i = 0; i < 100; i++)
        {
            StateHasChanged();
        }
    }

    public class Component1Reference
    {
        private Component1 Component1;

        internal Component1Reference(Component1 scrollViewer)
        {
            Component1 = scrollViewer;
        }

        [JSInvokable]
        public void UpdateTheComponent()
        {
            Component1.UpdateTheComponent();
        }
    }

}

and the scripts.js javascript having the following

window.Component1 = {
    init: function (elementReference, componentReference) {
        elementReference.Component1 = componentReference;
    },
    updateComponent: function (element) {
        element.Component1.invokeMethodAsync('UpdateTheComponent');
    }
}

When I press the button, the javascript obtains the component reference and call to the Blazor method one time.

But this time, the component is rendered multiple times

ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered
ComponentRendered

In many scenarios this causes dramatic performance degradation, as the rendering is executed multiple times unnecessarily.

BlazorApp8.zip

[pranavkm]

You likely have to switch to the UI context prior to invoking StateHasChanged - https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.1#invoke-component-methods-externally-to-update-state. Nevermind, I didn't read through this correctly.

[mrpmorris]

Well, I really wasn't expecting that. Good find!

[SQL-MisterMagoo]

The reason for the different behaviours is that the call from JS is asynchronous and so is the renderer, so the component can render between iterations of the loop.

You can prove this by changing your call from Blazor to be asynchronous like this in Index.razor

    private async Task UpdateComponent()
    {
        await Task.Delay(1);
        component1.UpdateTheComponent();
    }

If you make this change you will see the same behaviour for both buttons.

[arivoir]

The reason for the different behaviours is that the call from JS is asynchronous and so is the renderer, so the component can render between iterations of the loop.

I don’t get this. The JavaScript invocation is async, but not the c# method I’m calling. Can you clarify? The async call continues in the same thread it started, so I don’t see why it is different

[mrpmorris]

@SQL-MisterMagoo StateHasChanged is called directly from a C# loop

[SQL-MisterMagoo]

@arivoir The Blazor button calls UpdateTheComponent synchronously, blocking the renderer so it cannot re-render the component until the loop completes.

When you change the button click handler to be async, the renderer can continue to process even while the loop is iterating - and so you get a number (between 1 and 100) of re-renders.

Original:
--- Renderer ---| Blocked by looping code |--- Render ---
....Looping Code...SHC..SHC...SHC...SHC...SHC...
As per previous comment
--- Renderer ------Render---Render---Render--- Render ---
....Looping Code...SHC..SHC...SHC...SHC...SHC...

[SQL-MisterMagoo]

It might help if you provided a reason why you want to call SHC that many times in a loop - it seems odd and the contrived example doesn't indicate any real-life intent

[mrpmorris]

It's a proof of principle.

In order to save processing time
When calling StateHasChanged many times
Then the component should only be marked as needing to be rerendered
And should render only once when the next render process occurrs

Here is a more simple demonstration of the problem

In _Host.cshtml add

  <script>
    window.callBackBlazor = function (blazorComponent) {
      blazorComponent.invokeMethodAsync("ExecuteStateHasChangedInALoop");
		}
  </script>

Then click the button in the following component

@page "/"
@inject IJSRuntime JSRuntime

@{ 
	System.Diagnostics.Debug.WriteLine(DateTime.UtcNow + " Rendering");
}
<button @onclick=CallJs>Call JS</button>

@code
{
	DotNetObjectReference<Index> ObjRef;

	protected override void OnAfterRender(bool firstRender)
	{
		ObjRef = DotNetObjectReference.Create(this);
	}

	private async Task CallJs()
	{
		await JSRuntime.InvokeVoidAsync("callBackBlazor", ObjRef).ConfigureAwait(false);
	}

	[JSInvokable]
	public async Task ExecuteStateHasChangedInALoop()
	{
		for (int i = 0; i < 3; i++)
			StateHasChanged();
	}
}

It seems that neither void or async/await or await Task.Delay(1) make any difference.

[SQL-MisterMagoo]

I'm sorry I don't understand why you are creating these loops to call StateHasChanged over and over?
I'm not suggesting you "tweak" the code but stop writing loops that call StateHasChanged, especially from JS

[arivoir]

@SQL-MisterMagoo

When you change the button click handler to be async, the renderer can continue to process even while the loop is iterating - and so you get a number (between 1 and 100) of re-renders.

The fact that the method, where the loop is called, is async shouldn’t change anything, the loop is still synchronous. No rendering should happen between StateHasChanged invocations, as this method is supposed to flag the rendering and it shouldn’t execute the rendering directly. That’s how UI invalidation works in any platform and what the documentation claims Blazor should do.

The case you are describing, where renderings happen between the calls to StateHasChanged, correspond to a code like this

public async Task UpdateTheComponent()
{
     for (int i = 0; i < 100; i++)
     {
         StateHasChanged();
         await Task.Delay(1000);
     }
 }

The repro sample I created is obviously not real, but calling StateHasChanged multiple times in the same call it’s something normal in UI development, and it should work, otherwise it introduces serious performance problems.

[SQL-MisterMagoo]

@arivoir I don't think I am explaining this well

• your button click handler in Blazor is synchronous and invoked on the main "thread" where the renderer executes - so it blocks the renderer, and hence you can only get a render after the code completes.
• your JS invoked method is async, not blocking the renderer, so every time you call StateHasChanged it flags the component for re-rendering in the next render batch. That can happen during the timespan of the execution of the loop, so you can get multiple renders before the loop completes - but they are not synchronous and not 1-1 with the calls to StateHasChanged. You will get between 1 and 100 renders - depending on how quickly each render happens. This is possible because the renderer is not blocked.

Changing your Blazor button handler to be async is the right thing to do - you should not block the renderer - and if you do that then the behaviour is the same in both Blazor code and JS invoked code.

Why are you calling StateHasChanged more than once ? That is the real problem as far as I see it.

You have stated it is "normal" to call it multiple times - but the only time I would do that is precisely because I have a long-running async process that is updating the component state and I want it to re-render - what other reason is there to call it multiple times?

[mrpmorris]

Calling StateHasChanged in a loop isn't the goal, it just demonstrates that the component is being rendered immediately rather than simply being flagged.

For example, if a single operation causes multiple changes to shared state that a component is subscribed to then it will receive multiple notifications to rerender itself.

[arivoir]

@SQL-MisterMagoo, all your reasoning is based on a mistake, it isn’t calling the StateHasChanged in an asynchronous method. It is synchronous. It’s a synchronous for, there is no await, therefore it shouldn’t execute the rendering multiple times. It should flag it and execute it just one time. Other behavior not obeying this is a major design failure in the platform and should be the priority 1 of the team because this affects the performance tremendously.

When developing any component with a relative degree of complexity, the ui can be invalidated for diverse causes, coming from different parts of the code, if the component can’t rely in the platform to invalidate the ui correctly without causing a massive numbers of renderings, the component itself needs to do it, which is frankly inviable.