[BLAZOR WASM] Massive UI lag when typing in an input of a complex component

[Flaflo]

Describe the bug

This bug is known since 2019 but nothing was done against it. It was reported here #17951 and added into the .NET 5 sprints but was closed and locked without actually fixing the bug or providing an acceptable workaround. To be honest, this makes me a little bit upset because clearly this is a critical performance issue.

To Reproduce

This should not be that hard, but I think the best way to reproduce is to use some component library such as https://mudblazor.com/ and create a dialog with many input fields inside.
Any other information can be taken out of the closed issue all of it is already there.

Further technical details

• ASP.NET Core 5.0.2
• Blazor WASM
• Basically everything on 5.0.2

Please fix this and dont ignore this issue. I am not the only one having problems with this. It is mandatory for Blazor to be used in bigger business applications. The current performance in complex environments is not acceptable.

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

[Flaflo]

The discussion in #18919 is about the same topic and also worth reading.

[danroth27]

@TanayParikh What is this issue blocked on?

[TanayParikh]

We have a few parallel efforts (#30289, #21877, #27885) we're currently tackling which should give us the tools necessary to make this process more efficient & performant.

[TanayParikh]

Tracking the fix for this issue in #30291. We'll be implementing a new component LargeInputTextArea which allows for async retrieval of the text area content without support for validations/binding (as those would require sending the entire textarea's content to the server everytime).

[ChristianWeyer]

Are you really addressing the original poster's issue? @TanayParikh
He was not talking about Blazor Server, AFAIK.

[TanayParikh]

Are you really addressing the original poster's issue? @TanayParikh
He was not talking about Blazor Server, AFAIK.

I wasn't able to repro the UI lag for Blazor WebAssembly, I only encountered it on Blazor server using a text area with 20k+ chars. This was due to the added overhead of JS->.NET interop on 20k+ chars on each key press, alongside the network overhead. Reducing the JS->.NET interop overhead will have performance benefits for Blazor WebAssembly as well.

If you're encountering this issue specifically in complex components, I'd encourage you to review the Blazor WebAssembly Performance Best Practices which details rendering optimizations to resolve the issue. In that case, I'd say this issue is a duplicate of/resolved via #18919.

[ChristianWeyer]

FYI @Flaflo

[Flaflo]

Are you really addressing the original poster's issue? @TanayParikh
He was not talking about Blazor Server, AFAIK.

I wasn't able to repro the UI lag for Blazor WebAssembly, I only encountered it on Blazor server using a text area with 20k+ chars. This was due to the added overhead of JS->.NET interop on 20k+ chars on each key press, alongside the network overhead. Reducing the JS->.NET interop overhead will have performance benefits for Blazor WebAssembly as well.

If you're encountering this issue specifically in complex components, I'd encourage you to review the Blazor WebAssembly Performance Best Practices which details rendering optimizations to resolve the issue. In that case, I'd say this issue is a duplicate of/resolved via #18919.

Yes, its related to #18919 but my problem here is specifically that a re-render is triggered if a text input event is happening. This makes no sense.
We temporarily fixed this by a shouldRender bool as described in the related issue.

[TanayParikh]

Yes, its related to #18919 but my problem here is specifically that a re-render is triggered if a text input event is happening. This makes no sense.
We temporarily fixed this by a shouldRender bool as described in the related issue.

I believe https://docs.microsoft.com/en-us/aspnet/core/blazor/webassembly-performance-best-practices?view=aspnetcore-6.0#avoid-rerendering-after-handling-events-without-state-changes may be what you're looking for in that case.