Description
When the ResourceStrings parameter is set on IgbGrid, igSendMessage is invoked on every StateHasChanged of the hosting Blazor component, even if the ResourceStrings object has not changed.
Each invocation includes the full JSON representation of the ResourceStrings object as part of the JavaScript interop payload. This leads to repeated transmission of a large payload with no effective state change.
This behavior is essentially the same as the issue observed with parameters whose names end with Script (see also #189), but the impact is often much larger for ResourceStrings because:
- practically, it is always specified by non-English users, and
- it tends to dominate the JS interop payload size.
Steps to reproduce
- Create a Blazor component hosting an IgbGrid.
- Set the ResourceStrings parameter to a resource object.
- Do not change the grid or the ResourceStrings object afterward.
- Trigger StateHasChanged repeatedly in the hosting component (e.g. via a button click or timer).
- Observe that igSendMessage is called on every render, always including the serialized ResourceStrings object.
Result
igSendMessage is invoked every time StateHasChanged runs. The full JSON representation of ResourceStrings is sent each time. This happens even though:
- the grid configuration is unchanged, and
- the ResourceStrings reference remains the same.
In Blazor Server scenarios, this causes repeated SignalR traffic with a large payload, resulting in serious performance degradation.
Expected result
igSendMessage should be invoked for ResourceStrings only when an actual change needs to be propagated to the client. At a minimum, re-sending resource strings should be avoided when the same ResourceStrings reference is provided.
Notes
On change detection strategy for ResourceStrings
There is room for discussion on how changes to ResourceStrings should ideally be detected. From a practical standpoint, it is sufficient to re-send resource strings only when the reference passed to the ResourceStrings parameter changes. This approach means:
- Mutating properties of the same ResourceStrings instance would not be detected.
- Developers who intentionally need runtime updates must replace the entire object reference.
This trade-off is entirely acceptable for ResourceStrings, because:
- Resource strings are rarely mutated partially at runtime.
- Replacing the reference is a reasonable and explicit requirement for such advanced scenarios.
- Implementing deep or structural comparison for resource strings is effectively overkill for the overwhelming majority of users.
While a full structural (deep) comparison could theoretically provide more correctness, it comes with:
- higher CPU cost,
- additional memory pressure, and
- more complex implementation.
From a user perspective, especially given the severe performance impact of the current behavior, a quick fix based on reference comparison is strongly preferred, even if it is not theoretically perfect. If a future release later introduces deep comparison as an optional or refined optimization, that would be more than sufficient. However, delaying the fix in order to implement deep comparison upfront would not be a desirable trade-off for users.
Scope considerations
Similar issues may exist for other parameters that accept reference types; however, this has not been fully investigated. It is understood that some parameters may legitimately require deep comparison. That said, addressing the ResourceStrings parameter first, where the impact is especially large due to payload size and guaranteed usage by non-English users, would already provide significant real-world benefits. Incremental improvements for other parameters can reasonably follow in subsequent releases.
Attachments
A reproducible Blazor Server sample application is attached (BlazorServerApp1-Issue-190.zip).
📦BlazorServerApp1-Issue-190.zip
The sample contains:
- an IgbGrid configured using ResourceStrings 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, the displayed count increases every time the button is clicked, clearly demonstrating the repeated igSendMessage invocations caused solely by StateHasChanged.
Description
When the ResourceStrings parameter is set on IgbGrid, igSendMessage is invoked on every StateHasChanged of the hosting Blazor component, even if the ResourceStrings object has not changed.
Each invocation includes the full JSON representation of the ResourceStrings object as part of the JavaScript interop payload. This leads to repeated transmission of a large payload with no effective state change.
This behavior is essentially the same as the issue observed with parameters whose names end with Script (see also #189), but the impact is often much larger for ResourceStrings because:
Steps to reproduce
Result
igSendMessage is invoked every time StateHasChanged runs. The full JSON representation of ResourceStrings is sent each time. This happens even though:
In Blazor Server scenarios, this causes repeated SignalR traffic with a large payload, resulting in serious performance degradation.
Expected result
igSendMessage should be invoked for ResourceStrings only when an actual change needs to be propagated to the client. At a minimum, re-sending resource strings should be avoided when the same ResourceStrings reference is provided.
Notes
On change detection strategy for ResourceStrings
There is room for discussion on how changes to ResourceStrings should ideally be detected. From a practical standpoint, it is sufficient to re-send resource strings only when the reference passed to the ResourceStrings parameter changes. This approach means:
This trade-off is entirely acceptable for ResourceStrings, because:
While a full structural (deep) comparison could theoretically provide more correctness, it comes with:
From a user perspective, especially given the severe performance impact of the current behavior, a quick fix based on reference comparison is strongly preferred, even if it is not theoretically perfect. If a future release later introduces deep comparison as an optional or refined optimization, that would be more than sufficient. However, delaying the fix in order to implement deep comparison upfront would not be a desirable trade-off for users.
Scope considerations
Similar issues may exist for other parameters that accept reference types; however, this has not been fully investigated. It is understood that some parameters may legitimately require deep comparison. That said, addressing the ResourceStrings parameter first, where the impact is especially large due to payload size and guaranteed usage by non-English users, would already provide significant real-world benefits. Incremental improvements for other parameters can reasonably follow in subsequent releases.
Attachments
A reproducible Blazor Server sample application is attached (BlazorServerApp1-Issue-190.zip).
📦BlazorServerApp1-Issue-190.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, the displayed count increases every time the button is clicked, clearly demonstrating the repeated igSendMessage invocations caused solely by StateHasChanged.