Much like any other UI framework all UI operations have to be done on the main thread. You can think of it as setting a 'dirty flag'.īlazor will update the UI as soon as the render engine gets to run on its Thread again. StateHasChanged() by itself does not update the UI. How to make sure the UI is updated after calling StateHasChanged().You do need to call it when you use fire-and-forget ( async void) or when changes come from a different source, like a Timer or events from another layer in your program.

That means you usually don't need to call it, only when your method has several distinct steps and you want to update the UI in the middle do you need to call it. In addition to answer here I'd like to point out that there are two separate problems here, and it pays to separate them.īlazor will (conceptually) call StateHasChanged() after initialization and before and after events.

See Henk Holterman's answer with blazor internals explanation. Learn more about how to write nice spinner you can learn from open source project BlazorPro.Spinkit, it contains clever samples. Charbeneau published BlazorPro.Spinkit project enclosing long processes into task to don't block the thread:Įnsure your LongOperation() is a Task, if it is not, enclose it into a Task and await for it: async Task AsyncLongOperation() // this is an async taskĪwait Task.Run(()=> LongOperation()) // LongOperation()) //<-or Task.Delay(0) without Task.Run Option 2: Using Task.Run() (not for WebAssembly)

Option 1 is a simple solution that runs ok but looks like a trick. The trick!!Īwait Task.Delay(1) // changes are flushed again Private async Task AsyncLongFunc() // this is an async taskĪwait Task.Delay(1) // flushing changes.

Use await Task.Delay(1) or await Task.Yield() to flush changes.

Task force radio not working on server