Aspnetcore: ViewComponentTagHelper: Allow optional parameters

Agreed. No idea how feasible it is, but I agree with the sentiment :smile:

This seems pretty feasible. We need to teach this code about default values. Currently it says that each parameter is a required attribute

@rynowak candidate for preview2?

I'm going to move it in and mark it up for grabs. At this point locking down our public APIs and completing the tooling story needs to take priority.

Really looking forward to this fix. As things stand, using the VC tag helper is very dangerous. Add a new parameter to an existing and widely used tag helper and miss updating one of the places it is called and it _silently fails while emitting server side markup to the browser_. I guess we're too far along now for this to make it in to 2.0.0?

This is not going to make it for 2.0.0. We don't have time to update tooling at this point.

I believe it should be marked as a bug.

This is working:

@await Component.Invoke(typeof(MyViewComponent));

This is not working

<vc:My />

It is expected behavior and since you do not show any warning, error, debug message, nothing, it upsets a lot of people wondering why the hell the view component is not rendered

So will this make it into the next release?

Looking for an update on this issue. Will this be added any time soon? Rather frustrating one to deal with.

Came here to say same thing after finding this issue and spending some time tracking down why on of my tag helper called VC's wasn't presenting any output.

Hey @rynowak:

I thought I would give this a shot and after reading the source code here (your link is dead), it seems pretty easy to fix. However, there are at least two ways ( either create a replica of RequiredAttributeDescriptor and friends, or move to a base clas/interface) to do this and it's a substantial amount of code changes.

@rynowak and/or @DamianEdwards, please tell something to @CamiloTerevinto as we want to see this improved.

Updated View components in ASP.NET Core with

All view component parameters are required

Each parameter in a view component is a required attribute. See this GitHub issue. If any parameter is omitted:

• The InvokeAsync method signature won't match, therefore the method won't execute.
• The ViewComponent won't render any markup.
• No errors will be thrown.

Just got bitten hard by it (the notice was not there at the time I implemented it in my app)

Is there a planned solution or will it stay like this for the foreseeable future? As this can be really dangerous, especially that it fails silently... Could there at least be a warning or something like that at compile time?

Yeah, I agree with the last comment. I also got bitten hard by this recently and the fact that it simply fails silently is not good.

@rynowak is it possible to generate an error?

@rynowak Will there be any support for this in the future?

It's been over two years, and honestly, it is a pain to have to duplicate default parameters everywhere a view component is used.

@rynowak what's the correct line number in

This seems pretty feasible. We need to teach this code about default values. Currently it says that each parameter is a _required_ attribute

this code : updated link but maybe not correct line

Thanks @Rick-Anderson for updating the docs, but it's ridiculous that you should even have to. This makes the tag helper UNUSABLE for serious projects. To have code fail _silently_ when you refactor or add features should be completely unacceptable. I'm stunned that this is still open almost three years after first being reported. Is any fix planned?!

Has anyone from the aspnetcore team looked at this and given an ultimate answer as to whether or not this will be implemented? I personally think it's something that makes view components actually useful and would reduce redundant code. At bare minimum, I would like to see someone from the team take ownership and make a decision on the fate of this feature.

@mkArtakMSFT @rynowak please review and @rynowak can you check

@rynowak what's the correct line number in

This seems pretty feasible. We need to teach this code about default values. Currently it says that each parameter is a _required_ attribute

this code : updated link but maybe not correct line

so in 3 years this @rynowak guy didn't come on top of this issue

@brgrz have you come up with a solution? Because if "this @rynowak " can't come up with one, maybe you could come and help (trying to be constructive maybe instead of destructive, your comment brings nothing to the table here IMO...)

I must agree it is sad to realize there's no proposed solution yet and that this problem has been reported a long time ago, but never forget they are not 1000 working on it and they have lots of areas to cover... so I'm not surprised some issues are left unresolved for long periods, it's the same for every open source project out there.... (almost)

We'll add support for this in 5.0!

@brgrz have you come up with a solution? Because if "this @rynowak " can't come up with one, maybe you could come and help (trying to be constructive maybe instead of destructive, your comment brings nothing to the table here IMO...)

I must agree it is sad to realize there's no proposed solution yet and that this problem has been reported a long time ago, but never forget they are not 1000 working on it and they have lots of areas to cover... so I'm not surprised some issues are left unresolved for long periods, it's the same for every open source project out there.... (almost)

@os1r1s110 Oh, please... cut the contributor bullshit, rynowak posted "This seems pretty feasible" 3 years ago. I bet this single issue cost developers worldwide hundreds of wasted debugging hours and head banging in the meantime.

Also, ASP.NET Core is not my product nor is it community product, it is MS product. Even if I wanted I highly doubt they'd accept my solution and MS employees are paid to do it.

@brgrz As I said, I was also sad that it was not fixed sooner, but I think there's still a way to present things and not consider everyone working on open source projects owes you something (paid or not). Yes, they are paid to work on asp.net core and related projects, but that doesn't mean they have enough resources to fulfill all the needs in a timely manner (and I'm not even talking specifically about open source projects here, there's a need for qualified staff in every freaking domain nowadays).

Sorry if I offended you by replying to your post, but I still think that's not the way to make things move (and I don't consider it being "contributor bullshit"), even though it looks like it did make things move.... :)

Moving back to the Next sprint planning as we didn't get to this in this milestone.

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.

We'll add support for this in 5.0!

Is this going to make it in the end?

@guitax considering the number of times it has been delayed plus the fact that it has been put back on the backlog, I'd say chances are really really low 😕 It seems like the new priority now is blazor.

Let's just hope this will end up being implemented as it's a really irritating problem. 😂

At the very least it would be nice if this requirement were made much more clear in the documentation. Missing attributes defaulting to a standard value are the norm in HTML; the idea that they would be required for view components did not occur to me until I stumbled upon this thread.