Consider using C#9 Source Generators for implementing SetParametersAsync

[ChristianWeyer]

The performance best practices here talk about a custom implementation of SetParametersAsync instead of using reflection:
https://docs.microsoft.com/en-us/aspnet/core/blazor/webassembly-performance-best-practices?view=aspnetcore-5.0#implement-setparametersasync-manually

@stefanloerwald has built a lib that uses C#9 source generators that shows significant perf improvements:
https://github.com/excubo-ag/Generators.Blazor

Could that be an approach to include into the Blazor framework?

[stefanloerwald]

Thanks for the flowers @ChristianWeyer. Just for the record: the perf improvement I measured was in a very narrow benchmark, which doesn't fully reflect the performance improvement in the context of the entire blazor framework.
That said, I think a lot can be done with source generators. Given that there is the idea out there to rewrite the razor compiler using source generators, there's a good opportunity to integrate such things by default.

[javiercn]

@ChristianWeyer thanks for contacting us.

We looked at this as part of 5.0. It does improve perf a bit (@SteveSandersonMS has the data) but we didn't see any significant improvement and there were a few things we were concerned about, which is why we didn't do it.

• It comes at the risk of introducing behavior changes over the stock implementation.
• It introduces servicing issues (what happens if there's a security issue in the generated code).
• We didn't have a way in the Razor compiler to do this in a reasonable way. (Since we couldn't know when a component was overriding SetParametersAsync in component base).

/cc: @SteveSandersonMS am I missing something here?

[ghost]

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.

[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.

[TanayParikh]

We looked at this as part of 5.0. It does improve perf a bit (@SteveSandersonMS has the data) but we didn't see any significant improvement and there were a few things we were concerned about, which is why we didn't do it.

• It comes at the risk of introducing behavior changes over the stock implementation.
• It introduces servicing issues (what happens if there's a security issue in the generated code).
• We didn't have a way in the Razor compiler to do this in a reasonable way. (Since we couldn't know when a component was overriding SetParametersAsync in component base).

Thanks Javier for the details. Closing this as answered.

[javiercn]

@TanayParikh I believe Mackinnon wrote a prototype for this.

We might want to re-open this topic, so leaving it open.

[egil]

I like the idea of optimizing parameter setting. No reason not to lean into the fact that C# is a statically typed language.

In bUnit, we are able to stub/mock components during testing, due to the fact that parameters are assigned in a "duck typing" fashion at runtime. Essentially, we are able to replace one component with another (type), as long as it has the same parameters as the original, or a "capture all unmatched parameters" parameter.

If I read the ideas in this issue correctly, that should still work, i.e. the basis is still that a component has a SetParameterAsync method that will still be called by the renderer with a ParameterView, but a source generator may generate an optimized overridden version of said method.

[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 9 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.