fix: Prevent refreshViewport from reloading data from data provider#24895
Conversation
DataCommunicator#refreshViewport used to set the same flag as reset(), which made the flush re-query the item count and re-fetch the viewport range from the data provider. Now it only regenerates and resends data for the items that are already active, matching the behavior of HierarchicalDataCommunicator#refreshViewport. The former resendEntireRange flag is renamed to reloadViewportRange, and the new resend-only behavior is driven by a separate resendViewportRange flag. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
tltv
left a comment
There was a problem hiding this comment.
LGTM, one case to think about with Grid is how Column.setPartNameGenerator or Column.setTooltipGenerator are affected. Looks like it could now require additional DataProvider.refreshAll() to keep it function exactly same as before. But considering how JavaDoc never said refreshViewport() to reload data, approving.
|
For reference regarding last review comment: Grid.Column.setPartNameGenerator calls |
Yes, that's actually the expected behavior. Part name and tooltip generation shouldn't trigger another data provider call if the data is already there. |



Description
DataCommunicator#refreshViewportused to set the same flag asreset(), which made the flush re-query the item count and re-fetch the viewport range from the data provider. Now it only regenerates and resends data for the items that are already active, matching the behavior ofHierarchicalDataCommunicator#refreshViewport.Changes:
resendEntireRangeflag is renamed toreloadViewportRange(it reloads the viewport range from the data provider and resends it).resendViewportRangeflag drives the resend-only path used byrefreshViewport: the active range is regenerated through the data generators and resent viaupdate.setwithout any data provider queries, using the same wire format as before.Type of change
Checklist
🤖 Generated with Claude Code