Blazor Render Ratelimiter

[ReinoutWW]

Scenario & Problem:

In Blazor Server, we’ve seen scenarios where a child component and its parent can get into a “ping-pong” rendering cycle. For example, the parent triggers a render in the child, which in turn triggers a state change in the parent, ad infinitum. This can quickly chew up CPU and server resources, especially in Blazor Server where each render has a round-trip.

I’m wondering if there’s a way to:

1. Rate-limit renders (or throttle them) at a framework or component level, so that repeated calls to StateHasChanged() within a short timespan don’t cause an explosion of re-renders.
2. Alternatively, inject a service into the internal Blazor pipeline that can observe (or intercept) lifecycle events (e.g., IComponent.Attach(RenderHandle), SetParametersAsync, or post-render events) without having to rely on a custom ComponentBase subclass. I’m aware you can do something similar by subclassing ComponentBase or by hooking into circuit events for Blazor Server, but it would be great if there were a more direct extensibility point on the framework side to do this globally.

Questions:

• Is there any existing mechanism or recommended approach for rate-limiting or buffering multiple StateHasChanged() calls?
• If not, are there known workarounds or patterns (besides rewriting the components themselves to avoid the ping-pong scenario)?
• Could the framework expose an official extensibility point (like a “lifecycle service” or “render interceptor”) so we can inject custom logic globally, rather than requiring every component to share a single base class or each developer to remember to avoid infinite re-renders?

Motivation:

• We’d like to prevent infinite re-renders (or extremely frequent re-renders) that degrade performance.
• We also want to explore hooking into Blazor’s lifecycle for advanced scenarios—logging, metrics, etc.—in a centralized way.
• Right now, inheriting from a custom ComponentBase or using _Imports.razor is an option, but it’s easy to forget or bypass it in large teams and large codebases. A more global approach might be beneficial.

Are we heading in the wrong direction?

Perhaps we’re overcomplicating. If the recommended best practice is simply to refactor components to avoid mutual dependencies, I’d love to hear from others who’ve encountered (and solved) the infinite render problem. Also, if the community has alternative strategies or patterns for hooking into the lifecycle globally—without modifying the Blazor source or requiring a base class for all components—I’d love to get your insights.

Reference:
I’ve created an issue on this topic here: #59875.

Thanks in advance for any guidance or perspectives!

[ReinoutWW]

Additionally, as stated on https://blazor-university.com/components/multi-threaded-rendering/ a component could be caused to re-render for many reasons, including (but not limited to).

• A callback from a System.Threading.Timer
• An event triggered by another thread on a Singleton instance shared by multiple users
• A data push from another server we've connected to via a Web Socket.
• StateHasChanged

This can make it complex to always prevent infinite renders from the start, in the development process.