Compile-time warning/errors when passing unknown parameters to components that don't accept AdditionalAttributes

[pgillett]

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

We sometimes get caught by errors in tags, properties etc.

Using the new project sample code and converting the counter p tag to a component

<p>My counter count: @Current</p>

@code {
    [Parameter] public int Current { get; set; }
}

Which we then erroneously reference in our page:

<MyCounter Current="@currentCount" />   -- runs fine
<MyCounter CurrentValue="@currentCount" />   -- browser error without attribute splatting, unexpected behaviour with splatting
<MyCount Current="@currentCount" />   -- no errors, unexpected behaviour

(I appreciate the third would show a warning, but in the event of a rename/move/refactor this may go unnoticed, especially as you sometimes get false errors that are ignored).

In more complex cases you can end up with a compile error in the render tree, which feels almost completely disconnected from the source of the error.

The beauty of Blazor is that it's all in C# and benefits from type safety etc., so frustrating that these errors can slip through to runtime.

Describe the solution you'd like

It would be good to use another syntax that isn't tangled up with html to tell the compiler/parser that you are clearly working with a component so enforces type safety, such as prefixing the tag with a @. Something like:

@<MyCounter Current=currentCount />
or
@Render<MyCounter>(Current: currentCount)

This would then fail if you used this syntax on lines 2 and 3 above.

Only issue would be attribute splatting, which you could then either use the less safe html format, or maybe have a field where you have to pass the extras in some form of dynamic array.

I understand the familiar use of tags with respect to broad development teams of designers and coders, but as a coder I'd appreciate the added robustness.

Blazor is already doing this under the hood, just not tying loose ends.

Additional context

Not sure this is correct syntax for the render tree (other than it works), as a simple proof of concept I put a static Render method in MyCounter

public static RenderFragment Render(int current) => rt =>
    {
        rt.OpenComponent<MyCounter>(1);
        rt.AddAttribute(2, nameof(Current), current);
        rt.CloseComponent();
    };

Appreciate I'm passing my parameter in the method call (which isn't a bad thing because in this case it's required), but I can use

@MyCounter.Render(currentCount);

From my page. Compile error checked and safely survives renames, refactors etc.

[ghost]

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.

[ghost]

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.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

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.

[ghost]

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.

[gabephudson]

This is really starting to bite us developers. When a Blazor component renames or removes a parameter, we get no warnings at compile time. This is incredibly frustrating when working with newer versions of third-party components that have removed or renamed parameters. Often, we only get exceptions at runtime. :(

Can we please enable a compiler warning when a Blazor component is given a parameter that is invalid?

[meziantou]

@gabephudson While waiting for this rule to be builtin, you can use Meziantou.Analyzer to detect invalid parameters in Blazor (and a few other things):

• https://github.com/meziantou/Meziantou.Analyzer/blob/main/docs/Rules/MA0115.md
• https://www.meziantou.net/new-rules-for-blazor-in-meziantou-analyzer.htm#detect-unknown-compo
• https://www.nuget.org/packages/Meziantou.Analyzer

[gabephudson]

@gabephudson While waiting for this rule to be builtin, you can use Meziantou.Analyzer to detect invalid parameters in Blazor (and a few other things):

Thank you! The MudBlazor team pointed me to this fantastic package yesterday, as they have a lot of breaking changes in their new release. Many of their parameters have changed and it is difficult to track down all of these in our large codebase.

That said, I have added this to our project and while it has highlighted internal components with this issue, it does not seem to be catching this on instances of the MudBlazor components. (Note MudBlazor is a NuGet package in the project). Any idea of why this might be. (It's probably just my ignorance).

Either way, it's a fantastic tool and thank you for sharing!

[meziantou]

@gabephudson Please open an issue: https://github.com/meziantou/Meziantou.Analyzer/issues/new/choose

[gabephudson]

@gabephudson Please open an issue: https://github.com/meziantou/Meziantou.Analyzer/issues/new/choose

Done: meziantou/Meziantou.Analyzer#717