To elaborate on my comments, with too much pontification:
In OOP, regardless of language (be it Java, C#, C++, Swift, etc), the purpose of a class's constructor is to initialize the object-instance's state from any parameters, and also to establish class invariants.
- (Btw, don't equate or confuse invariant with immutability: immutability is just a particular kind of invariant, it's perfectly acceptable for a class' objects to be mutable)
The principle of class-invariants is more-often-than-lot (in my opinion) lost on so-many (perhaps even most?) users of C#, specifically, because of how the C# language (and its associated documentation and libraries) has evolved towards preferring default (parameterless) constructors, post-construction initialization, and mutable properties - all of which cannot be reconciled with the CS-theoretical, not practical, limits of static analysis which the C# compiler uses for #nullable warnings.
- The simple fact is only a
class's constructor can make guarantees about the state of any of its instance fields (including auto-properties) - whereas (excepting required members in C# 11), a C# object-initializer is evaluated post-construction, is entirely optional, sets entirely arbitrary and non-exhaustive members.
Therefore, to make use of #nullable to the full-extent, one must simply get used to getting into the habit of writing parameterized constructors, despite their "expressive redundancy" in most cases (e.g. in a POCO DTO) having to repeat the class's members as ctor parameters and then assign each property in the ctor.
- Though at least
record types in C# 9 simplify this - but record types aren't as immutable as they seem: properties can still be overwritten with invalid values after the ctor has run in an object-initializer, which breaks the concept of class-invariants being enforced by the constructor - I'm really not happy with how that turned out in C# 9, grrr.
I appreciate that this isn't possible in many cases, such as with Entity Framework and EF Core, which (as of early 2023) still doesn't support binding database query results to constructor parameters, only to property-setters - but people often are unaware that many other libraries/frameworks do support ctor binding, such as Newtonsoft.Json supports deserializing JSON objects to immutable C# objects via [JsonConstructor] and attaching [JsonProperty] to each ctor parameter, for example.
In other cases, namely UI/UX code, where your visual component/control/widget must inherit from some framework-provided base-class (e.g. WinForms' System.Windows.Forms.Control, or WPF's Visual or Control, or in Blazor: Microsoft.AspNetCore.Components.ComponentBase) - you'll find yourself with seemingly contradictory precepts: you can only "initialize" the Control's state /data in the OnLoad/OnInitializedAsync method (not the constructor), but the C# compiler's #nullable analysis recognizes that only the constructor can initialize class members and properly establish that certain fields will never be null at any point. It's a conundrum and the documentation and official examples and tutorials do often gloss this over (sometimes even with = null!, which I feel is just wrong).
Taking Blazor's ComponentBase for example (as this is what the OP's code is targeting, after-all): immediately after when the ComponentBase subclass is created (i.e. the ctor runs), the SetParametersAsync method is called, only after that then is OnInitializedAsync called - and OnInitializedAsync can fail or need to be awaited, which means that the "laws" about constructors definitely still apply: any code consuming a ComponentBase type cannot necessarily depend any late initialization by OnInitializedAsync to be guaranteed, especially not any error-handling code.
- For example, if the ctor left the
List<User> Users { get; } property uninitialized (and therefore null, despite the type not being List<User>?) and OnInitializedAsync (which would set it to a non-null value) were to fail, and then if that ComponentBase subclass object were to be passed to some custom-error handling logic, then that error-handler itself would fail if it (rightfully, but incorrectly) assumed that the Users property would never be null.
- However this convoluted arrangement could have been avoided if Microsoft designed Blazor to support some kind of
Component-factory system whereby the OnInitialized{Async} logic could be moved into a factory-method or ctor with that all-or-nothing guarantee that we need for software we can reason about. But anyway...
So given the above, there exist a few solutions:
- If this were a system entirely under your control (which Blazor is not, so this advice doesn't apply to you) then I would recommend you redesign the system to use factory-methods instead of post-ctor object initialization.
- But as this is Blazor, it shares certain similarities in its databinding approach with WPF, "XAML", WinForms and others: namely its roots in having long-lived mutable view-models implementing
INotifyPropertyChanged.
- And this is the most important factor: because the view-model concept means that you shouldn't have
List<T> as the collection-type for a property that will be used for data-binding: you're meant to use ObservableCollection<T>, which solves the problem: ObservableCollection<T> is meant to be initialized only once by the constructor (thus satisfying the never-null problem), and is designed to be long-lived and mutable, so it's perfectly-fine to populate it in OnInitializedAsync and OnParametersSet{Async}, which is how Blazor operates.
Therefore, in my opinion, you should change your code to this:
class UsersListComponent : ComponentBase
{
private Boolean isBusy;
public Boolean IsBusy
{
get { return this.isBusy; }
private set { if( this.isBusy != value ) { this.isBusy = value; this.RaiseOnNotifyPropertyChanged( nameof(this.IsBusy); } // INPC boilerplate, ugh: e.g. https://stackoverflow.com/questions/65813816/c-sharp-blazor-server-display-live-data-using-inotifypropertychanged
}
public ObservableCollection<User> Users { get; } = new ObservableCollection<User>();
protected override async Task OnInitializedAsync()
{
await this.ReloadUsersAsync(); // Also call `ReloadUsersAsync` in `OnParametersSetAsync` as-appropriate based on your application.
}
private async Task ReloadUsersAsync()
{
this.IsBusy = true;
this.Users.Clear(); // <-- The ObservableCollection will raise its own collection-modified events for you, which will be handled by the UI components data-bound to the exposed Users collection.
try
{
List<User> users = await this.Context.Users
.Include(u => u.Address)
.ToListAsync();
// ObservableCollection<T> doesn't support AddRange for historical reasons that we're now stuck with, ugh: https://github.com/dotnet/runtime/issues/18087#issuecomment-359197102
foreach( User u in users ) this.Users.Add( u );
}
finally
{
this.IsBusy = false;
}
}
}
Notice how, if the data-loading in OnInitializeAsync, via ReloadUsersAsync, fails due to an exception being thrown from Entity Framework (which is common, e.g. SQL Server timeout, database down, etc) then the class-invariants of UsersListComponent (i.e. that the Users collection is never null and the property always exposes a single long-lived object-reference) always remain true, which means any code can safely consume your UsersListComponent without risk of a dreaded unexpected NullReferenceException.
(And the IsBusy part is just because it's an inevitable thing to add to any ViewModel/XAML-databound class that performs some IO).
