refactor!: Centralize hierarchy management server-side #22019
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Test Results1 245 files + 4 1 245 suites +4 1h 11m 19s ⏱️ - 1m 50s Results for commit bdd8a15. ± Comparison against base commit eda19b9. This pull request removes 16 and adds 60 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
1 task
|
To be merged after 25.0.0-alpha4 release of platform. |
1 task
vursen
changed the title
|
mshabarov
approved these changes
Aug 22, 2025
|
This ticket/PR has been released with Vaadin 25.0.0-alpha8. |
32 tasks
Copilot AI
pushed a commit
that referenced
this pull request
Oct 1, 2025
The PR refactors HierarchicalDataCommunicator so that hierarchy management (expanded items, hierarchical cache) is centralized on the server side instead of being shared between client and server. This makes the client a simple consumer of flattened data lists, which significantly reduces the client-side complexity and opens the door for introducing flat data providers to support fetching flattened data directly from the data source. Key changes HierarchyMapper and HierarchicalCommunicationController have been replaced with the new concept, Cache. This new class provides a system for storing data in a hierarchical structure while enabling access in a flattened format for client-side consumption. setRequestedRange and setParentRequestedRange have been replaced with a single setViewportRange which spans all hierarchy levels. Caveats setViewportRange does not currently remove items from Cache and KeyMapper when they move out of the viewport. However, the previous version also only removed items from KeyMapper while keeping them in HierarchyMapper, so item instances actually continued to remain in memory. I feel this could be optimized separately if needed. setViewportRange currently always sends the full viewport to the client even when some items are already present on the client-side. I plan to address this separately, see #21989 refresh(T item) currently also sends the full viewport on every item refresh. I plan to address this separately, see #21989 Test coverage The PR aims at providing test coverage for all core functionality and public APIs. Individual tests for internal APIs such as Cache will be added separately. The refactoring successfully passes all TreeGrid ITs, see #7676 Depends on refactor: remove deprecated HierarchicalDataCommunicator APIs #21965 Fixes #21876, #21877
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Note
This PR is a reopen of #21966 after its unintentional merge and revert.
Warning
DO NOT MERGE until the related flow-components PR is approved.
The PR refactors
HierarchicalDataCommunicatorso that hierarchy management (expanded items, hierarchical cache) is centralized on the server side instead of being shared between client and server. This makes the client a simple consumer of flattened data lists, which significantly reduces the client-side complexity and opens the door for introducing flat data providers to support fetching flattened data directly from the data source.Key changes
HierarchyMapperandHierarchicalCommunicationControllerhave been replaced with the new concept,Cache. This new class provides a system for storing data in a hierarchical structure while enabling access in a flattened format for client-side consumption.setRequestedRangeandsetParentRequestedRangehave been replaced with a singlesetViewportRangewhich spans all hierarchy levels.Caveats
setViewportRangedoes not currently remove items from Cache and KeyMapper when they move out of the viewport. However, the previous version also only removed items from KeyMapper while keeping them in HierarchyMapper, so item instances actually continued to remain in memory. I feel this could be optimized separately if needed.setViewportRangecurrently always sends the full viewport to the client even when some items are already present on the client-side. I plan to address this separately, see #21989refresh(T item)currently also sends the full viewport on every item refresh. I plan to address this separately, see #21989Test coverage
Cachewill be added separately.Depends on
Fixes #21876, #21877
Type of change