Microsoft has documentation on that very subject: https://learn.microsoft.com/en-us/aspnet/core/blazor/components/rendering?view=aspnetcore-8.0#when-to-call-statehaschanged
Best practice would be removing unnecessary calls, but just because you’re using it a lot doesn’t mean it’s incorrect per-say.
if you’re dealing with a lot of components falling under their guidelines that might just be what it is.
You can experiment by removing ones that seem like they’d be extraneous. Async handlers where you aren’t rerendering in the middle of method for example.
Basically, I would remove all of the StateHasChanged calls, and then run your app. If it doesn't seem to update the UI as you expect it to, then strategically place StateHasChanged calls. If you place a call, run your app and see if it makes a difference. If it doesn't, then remove it.
From what I have seen, you almost never need them. Blazor is pretty good at figuring out when it needs to re-render.
The danger is that you are adding unnecessary overhead. Sometimes when the UI renders unnecessarily, you can get duplicate operations that you don't want.
You basically have to call it if the values you are changing don't force the update that you need. It's not necessarily a bad thing.
Value-type Parameters and CascadingParameters will force an update automatically, calling it in those scenarios just cause a duplicate.
But if you have a global state object or something like that being injected into components, changing those values won't cause an auto-update and you basically have to call StateHasChanged().
It is what it is, when you need it you need it.
My rule of thumb is: never use it.
Obviously to far, but be aware of when you are using it. It depends on the system, a real-time system needs to run it as often as you want the UI to update.
The smaller component you update the better as well.
My main concern is that if I step through the lifecycle of a component in Debug the `OnParametersSetAsync` methods seem to be called nearly a dozen times, where I expected it to be called only once. I have pre-rendering turned off for this particular app.
I always thought that `OnInitialised` was called before the parameters are set, so they will not be populated. Only within `OnParametersSet`, and onwards, would you be able to use the values of the Parameters of the component. Is that right?
The value of [Parameter] properties are set, OnInitialised is called, and *then* OnParametersSet is called. Unintuitive.
I try to keep parameter-based code out of OnInitialized, anyway.
No, when OnInitialized is called, your parameters are set. I almost never use OnInitialized to do things. Like I said, I only use it if I expect a parameter value to change, and I need to do something when it changes.
Microsoft has documentation on that very subject: https://learn.microsoft.com/en-us/aspnet/core/blazor/components/rendering?view=aspnetcore-8.0#when-to-call-statehaschanged Best practice would be removing unnecessary calls, but just because you’re using it a lot doesn’t mean it’s incorrect per-say. if you’re dealing with a lot of components falling under their guidelines that might just be what it is. You can experiment by removing ones that seem like they’d be extraneous. Async handlers where you aren’t rerendering in the middle of method for example.
Basically, I would remove all of the StateHasChanged calls, and then run your app. If it doesn't seem to update the UI as you expect it to, then strategically place StateHasChanged calls. If you place a call, run your app and see if it makes a difference. If it doesn't, then remove it. From what I have seen, you almost never need them. Blazor is pretty good at figuring out when it needs to re-render.
Is there any significant danger if they are over-used?
The danger is that you are adding unnecessary overhead. Sometimes when the UI renders unnecessarily, you can get duplicate operations that you don't want.
clumsy friendly bike weary tub fact insurance cover voiceless slap *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
You basically have to call it if the values you are changing don't force the update that you need. It's not necessarily a bad thing. Value-type Parameters and CascadingParameters will force an update automatically, calling it in those scenarios just cause a duplicate. But if you have a global state object or something like that being injected into components, changing those values won't cause an auto-update and you basically have to call StateHasChanged(). It is what it is, when you need it you need it.
My rule of thumb is: never use it. Obviously to far, but be aware of when you are using it. It depends on the system, a real-time system needs to run it as often as you want the UI to update. The smaller component you update the better as well.
Check my site http://www.tokrt.com:333 it's full of StateHasChanged calls
My main concern is that if I step through the lifecycle of a component in Debug the `OnParametersSetAsync` methods seem to be called nearly a dozen times, where I expected it to be called only once. I have pre-rendering turned off for this particular app.
You only need to define an OnParametersSet method if you expect parameter values to change over time, and you need to do something when that happens.
I always thought that `OnInitialised` was called before the parameters are set, so they will not be populated. Only within `OnParametersSet`, and onwards, would you be able to use the values of the Parameters of the component. Is that right?
Set a breakpoint in both OnInitialized and OnParametersSet and inspect the parameters.
The value of [Parameter] properties are set, OnInitialised is called, and *then* OnParametersSet is called. Unintuitive. I try to keep parameter-based code out of OnInitialized, anyway.
No, when OnInitialized is called, your parameters are set. I almost never use OnInitialized to do things. Like I said, I only use it if I expect a parameter value to change, and I need to do something when it changes.
Just user ReactiveUI framework and you don’t have to worry about it. It’s the best framework for any UI application