Allow Blazor components with [Parameter] attributes on properties to be aware of the required modifier.

[benjaminsampica]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Using EditorRequired for specifying whether a Blazor component has a required parameter or not seems redundant now with the C# 11 language feature required which can be put on properties.

Currently, you have to do something like the following in order to tell consumers of your component that it's a required parameter.

public partial class FetchData
{
    [Parameter, EditorRequired] public string City { get; set; } = null!;
}

I think it's confusing and verbose to have both a required attribute and modifier on a singular property that a developer wishes to do the same thing - make the parameter required.

Describe the solution you'd like

Simply put, the required modifier should invoke the analyzer warning.

RZ2012: Component FetchData expects a value for the parameter 'City', but a value may not have been provided.

public partial class FetchData
{
    [Parameter] public required string City { get; set; }
}

Backwards compatibility should be maintained on the existing attribute.

It would be nice to notify developers who move from earlier language versions to newer ones that EditorRequired is deprecated in favor of the required modifier.

Additional context

[javiercn]

@benjaminsampica thanks for contacting us.

We do not want to tie the required attribute to the editor support we offer via [EditorRequired]. They have different semantics:

• [EditorRequired] just signals the editor to issue a warning when a parameter has not been provided in a call-site.
  • There are many cases in which we can't guarantee this is the case, like when splatting parameters.
  • All that editor required does is "hint" that the ParameterView that gets created to call SetParametersAsync should contain that key.
• required means the property needs to be initialized right after object construction.

If we were to deprecate [EditorRequired] in favor of required that would have bigger implications that just issuing a warning.

• It will be confusing because only your component can truly enforce what parameters are needed.
• Using required will not prevent the parameter from being missing on a call to SetParametersAsync as you would expect.
  • (We are not going to be checking at runtime for its presence).
• You would no longer be able to construct a new instance of a component without initializing those parameters which is important for unit testing.

Components have a different lifecycle and required simply is not a good fit for them. Components do not receive parameters until the first call to SetParametersAsync happens and no parameter is required until the component author chooses so.

We do not want to tie ourselves to a language feature that does not exactly reflect the semantics of our component model. I understand it is tempting to do so, but there are many subtle nuances that make it a bad fit.

[benjaminsampica]

Makes a lot of sense! Thanks for the thorough answer. Cheers 🍺!

[BieleckiLtd]

While I understand the reasoning, I'm afraid required modifiers will be overused in this context, creating an easy pit-of-failure for a lot of Blazor developers. One would expect non-nullable [Parameter] public required object MyParameter {get; set;} to be initiated, but it easily might not be (no compiler warnings).

[Fabster1993]

While I understand the reasoning, I'm afraid required modifiers will be overused in this context, creating an easy pit-of-failure for a lot of Blazor developers. One would expect non-nullable [Parameter] public required object MyParameter {get; set;} to be initiated, but it easily might not be (no compiler warnings).

Totally agree. It will be possible to see Null Reference Exception without any compiler warning. IMHO, it should generate at least a warning if one uses required keyword on a blazor component parameter.