Should I be using SetParametersAsync() for all [Parameter] properties?

I am now using SetParametersAsync() for a [Parameter] that is not set when OnInitializedAsync() is called. But that led to my thinking...

Even a property as simple as Visible, while usually set to "true" or "false" could sometimes be set based on a DB query and therefore get set after OnInitializedAsync() is called.

So... should I handle every [Parameter] only in SetParametersAsync() and not in OnInitializedAsync()

Or, should I handle them in OnInitializedAsync() if they're non-null and also watch for them being changed in SetParametersAsync()

And associated question. For each parameter I handle in SetParametersAsync(), do I need to keep a local copy of what it was last set to, to determine if the new value is a change? Or is there a way I can ask ParameterView if the value is changed? (I can't find anything in my searching.)

This is a difficult question (did it change) as in this case, it's a List<User> and so getting a "new value where list.Count == prevList.Count does not mean that the list didn't change.

Consider this code

<h3>TestComponent</h3>

<div class="bg-dark text-white m-2 p-2"> 
    <pre>State : @this.State</pre>
</div>
@code {
    [Parameter] public string? State { get; set; }

    public override async Task SetParametersAsync(ParameterView parameters)
    {
        // emulate doing something async to get something before assigning the parameters
        await Task.Delay(1);
        parameters.SetParameterProperties(this);
        await base.SetParametersAsync(ParameterView.Empty);
    }
}

Looks plausible, but it will generate an error:

InvalidOperationException: The ParameterView instance can no longer be read because it has expired. ParameterView can only be read synchronously and must not be stored for later use.

Why, because the Renderer has moved on and the ParameterView instance is potentially stale. You have yielded back to the Renderer and all sorts of sync code may have run that changed data in the ParameterView instance.

I use the following rule of thumb:

OnInitialized-:

Here I will get things ready for the component, and very rarely do anything related to component parameters. Very often I will set internal or private parameters/fields for UI based logic or other defaults not set on the parameter/field. Things like rendering of a loading modal, EditContext etc. If I have a component that does not have parameters, I will add all starting logic here.

OnParameterSet-:

Here I will add all my component parameter logic and do hash checking to identify whether a parameter updated. Useful when working with your List<T> example and it's much cheaper storing a hash string instead of a whole list.

OnAfterRender-:

I usually reserve this for JavaScript. In my ~4 years of Blazor, I've only called JavaScript here.

EDIT:

Apologies, I misread the initial question and confused SetParametersAsync with OnParameterSet-.

SetParametersAsync

I've never needed to use this in the early stages. If you need to use this, ask yourself why. Rather see how can you improve or change the component to remove this dependency. Though I would use this on components if they are rendered in the thousands or have a lot of parameters, but then again, why render one component a thousand times? A high parameter count usually tells me that my component needs to be split into multiple components.

On simple components (which I believe all components should be), the performance gain from using SetParametersAsync is not worth the time to code. On the other hand, if I want to squeeze out as much performance as I can (usually late in the project), I will start updating my components. But then again, you might save 100ms of rendering time on large pages.

Blazor is very powerful in this way. I see many component libraries creating Jack-of-all-trade components when you can use wrapper components that bring in functionality as it's required.

For example, if you have a data table, make your filters a wrapper since not all data tables require filters. This can count for many types of components and saves massively on complexity and performance.

Your question brings up an interesting point in Component implementation.

If you are using local variables to track state then you should consider setting and tracking them in SetParametersAsync and dispensing with the automatic setting.

This MS article describes this strategy to optimize components - https://learn.microsoft.com/en-us/aspnet/core/blazor/performance?view=aspnetcore-7.0#implement-setparametersasync-manually

The important point here is it may be more costly in dev time to code this manually, but in execution time it's quicker and less expensive: the automated code uses reflection which isn't quick or cheap. You only code it once, but is could get executed millions of times!

I also beg to differ with @HH on SetParametersAsync() is pretty tricky to use, but that's a personal opinion. Once you know the pattern to use, I don't see an issue.