Aspnetcore: Required parameters to blazor components

[montyclt]

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

I'm building a component where optional parameter doesn't make sense.

Describe the solution you'd like

Add required parameter to Parameter attribute

[Parameter(required = true)]
protected string Name { get; set; }

[Andrzej-W]

This is an old idea. It was moved from original Blazor repository to this #5455. Unfortunately it is now closed.

[montyclt]

Thank you @Andrzej-W. I close it as duplicate.

[Andrzej-W]

@montyclt Maybe you shouldn't close. As I wrote above issue #5455 was closed a few months ago but I'm afraid [Parameter(required = true)] hasn't been implemented yet and I cannot find any other tracking item for this.

[rynowak]

Reopening this. We do plan to do a feature like this but it won't happen in 3.0.

[mikewodarczyk]

The implementation of this may need to mix with the #nullable variable feature in c# 8. The null checks will flag [Parameter(required = true)] protected T myVar {get; set;} as uninitialized, but in fact this attribute is saying that the variable must be initialized; but it is initialized elsewhere.

[danroth27]

Clearing the milestone as I'd like to consider this for 5.0 now that we have a bunch of components that have required parameters.

[buddyfavors]

This could have came in handy for me too, for now I just wrapped the property.

        [Parameter]
        public string MessageText
        {
            get => _MessageText ?? throw new NotImplementedException();
            set => _MessageText = value;
        }

        private string _MessageText { get; set; }

[kattunga]

Is not possible to add this to 3.1?
now we to set #nullable disable in each params section to disable nullable warnings.

[ZimM-LostPolygon]

now we to set #nullable disable in each params section to disable nullable warnings.
@kattunga

Use null! instead, much more nice:

    [Parameter]
    public UserEditViewModel UserEdit { get; set; } = null!;

[chucker]

Use null! instead, much more nice:

That works, but it really just tells the compiler to ignore the problem.

It'd be nicer if we can have the compiler surface the problem on the component _consumer_'s end:

<MyComponent /> <!-- compiler warning: UserEdit isn't set -->
<MyComponent UserEdit="@foo" /> <!-- no warning! -->

[MarkusRodler]

It would be nice if there is a possibility to tell the components, that some arguments are mandatory to function like in HTML.
For example it is from an html view totally ok to not specify an alt-tag, but an img-tag without src would not work.

[montyclt]

It would be nice if there is a possibility to tell the components, that some arguments are mandatory to function like in HTML.
For example it is from an html view totally ok to not specify an alt-tag, but an img-tag without src would not work.

@MarkusRodler The idea of required parameters is that should throw an error when building the project if some component is called without its required parameter.

[msftbot[bot]]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

Moving this out of 5.0 given the cost.

[pranavkm]

Splitting this work in to two parts. For 5.0, we'll introduce the property on ParameterAttribute. This should allow us to scavenge this metadata at a later point when tooling can support it. Tooling work tracked via https://github.com/dotnet/aspnetcore/issues/25055.

[pranavkm]

The implementation in https://github.com/dotnet/aspnetcore/pull/25054 would have implemented a Required property on the ComponentParameter. The implementation verified that a value for each required component parameter was specified as part of SetParametersAsync. When we discussed this implementation, a few issues came up:

• The runtime check could not be guaranteed in the event SetParametersAsync is overridden. We may recommend overriding this method for certain kinds of components, which makes the benefit of the runtime check a bit lax.

• The runtime check does not guarantee non-nullness of reference types. Often components may need to indicate that a parameter is specified and not null.

Given these limitations, it seems the benefit of the runtime check is questionable. Instead, we think could focus on the tooling aspects of this. Tooling can look for an attributed on parameters that indicates if a parameter is required. We can look up such attributes by name, so it would not require a runtime feature and we could enable it any point before 6.0:

[Parameter]
[UIRequired] // Name is TBD
public string MyRequiredParameter { get; set; }

[msftbot[bot]]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[msftbot[bot]]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[msftbot[bot]]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mrpmorris]

I believe the purpose of the request is for some kind of analyzer to output an error if we don't set a required parameter's value when consuming the component in a razor file.

Am I correct @montyclt ?

[stefanloerwald]

FYI: https://github.com/excubo-ag/Generators.Blazor/ has experimental support for this kind of feature.

[pranavkm]

The way we interpreted this was to have a design time gesture that indicated that parameters that were marked as required were not specified. There's a risk there are false positives (particularly with splatting) that could not be statically inferred so we think treating it as a nudge-in-the-right-direction sort of feature is less bothersome.

[montyclt]

I believe the purpose of the request is for some kind of analyzer to output an error if we don't set a required parameter's value when consuming the component in a razor file.

Am I correct @montyclt ?

Yes, but if it is possible, I would like to analyze OpenComponent method of BuildRenderTree

[stefanloerwald]

Yes, but if it is possible, I would like to analyze OpenComponent method of BuildRenderTree

This is exactly what the experimental analyzer in https://github.com/excubo-ag/Generators.Blazor/ does. See https://github.com/excubo-ag/Generators.Blazor/blob/main/Blazor/RequiredParameterAnalyzer.cs