Description
When parameters whose names end with "~Script" (e.g. HeaderTemplateScript, CellTemplateScript, etc.) are set on IgbGrid and/or IgbColumn, the framework repeatedly calls "igSendMessage" JavaScript function every time the hosting Blazor component triggers StateHasChanged.
This occurs even when:
- the value of the ~Script parameter has not changed, and
- no structural changes are made to the grid or columns.
As a result, excessive and redundant JS interop calls are generated, causing significant performance degradation, especially in real-world applications where StateHasChanged is triggered frequently (e.g. timers, parent state updates, cascading parameters, etc.).
Steps to reproduce
- Create a Blazor component that hosts an IgbGrid.
- Define one or more IgbColumns.
- Set at least one parameter whose name ends with Script on IgbGrid or IgbColumn (for example, a *TemplateScript parameter).
- In the hosting component, trigger StateHasChanged repeatedly (for example, via a timer, button, or any unrelated state update).
- Observe JavaScript interop activity in the browser’s developer tools or debugger.
Result
igSendMessage is invoked repeatedly on every StateHasChanged, even though:
- the ~Script parameter value is unchanged, and
- no relevant grid or column configuration has been modified.
This results in unnecessary JS interop traffic and noticeable performance issues.
Expected result
igSendMessage should only be called when the value of a ~Script parameter actually changes, or when a relevant grid/column update is required.
Re-rendering of the hosting Blazor component alone should not cause repeated JS updates for unchanged ~Script parameters.
Notes
This issue is not only about unnecessary JavaScript function invocations.
In many cases, the igSendMessage calls carry a large payload. When this happens repeatedly, the cost becomes significant.
This is especially problematic in Blazor Server scenarios, where each JS interop call and its payload are transferred over SignalR. As a result, repeated and redundant igSendMessage calls with a large payload can lead to excessive network traffic, increased latency, and serious overall performance degradation.
While the impact may be less visible in Blazor WebAssembly, in Blazor Server applications this behavior can become a critical performance bottleneck.
Attachments
A reproducible Blazor Server sample application is attached (BlazorServerApp1.zip).
📦BlazorServerApp1.zip
The sample contains:
- an IgbGrid with columns configured using EmptyGridTemplateScript parameters, and
- a simple button that increments a _count field in the hosting component.
The button click does not modify the grid, columns, or any related parameters. Its only purpose is to trigger StateHasChanged.
A small debugging mechanism is included in the page to count and display the number of igSendMessage JavaScript function calls. Despite no changes to the grid or columns, the displayed count increases every time the button is clicked, clearly demonstrating the repeated igSendMessage invocations caused solely by StateHasChanged.
Description
When parameters whose names end with "~Script" (e.g. HeaderTemplateScript, CellTemplateScript, etc.) are set on IgbGrid and/or IgbColumn, the framework repeatedly calls "igSendMessage" JavaScript function every time the hosting Blazor component triggers StateHasChanged.
This occurs even when:
As a result, excessive and redundant JS interop calls are generated, causing significant performance degradation, especially in real-world applications where StateHasChanged is triggered frequently (e.g. timers, parent state updates, cascading parameters, etc.).
Steps to reproduce
Result
igSendMessage is invoked repeatedly on every StateHasChanged, even though:
This results in unnecessary JS interop traffic and noticeable performance issues.
Expected result
igSendMessage should only be called when the value of a ~Script parameter actually changes, or when a relevant grid/column update is required.
Re-rendering of the hosting Blazor component alone should not cause repeated JS updates for unchanged ~Script parameters.
Notes
This issue is not only about unnecessary JavaScript function invocations.
In many cases, the igSendMessage calls carry a large payload. When this happens repeatedly, the cost becomes significant.
This is especially problematic in Blazor Server scenarios, where each JS interop call and its payload are transferred over SignalR. As a result, repeated and redundant igSendMessage calls with a large payload can lead to excessive network traffic, increased latency, and serious overall performance degradation.
While the impact may be less visible in Blazor WebAssembly, in Blazor Server applications this behavior can become a critical performance bottleneck.
Attachments
A reproducible Blazor Server sample application is attached (BlazorServerApp1.zip).
📦BlazorServerApp1.zip
The sample contains:
The button click does not modify the grid, columns, or any related parameters. Its only purpose is to trigger StateHasChanged.
A small debugging mechanism is included in the page to count and display the number of igSendMessage JavaScript function calls. Despite no changes to the grid or columns, the displayed count increases every time the button is clicked, clearly demonstrating the repeated igSendMessage invocations caused solely by StateHasChanged.