perf(react-tree): avoid processing hidden subtrees #35198
Merged
+70
−19
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
toerndev
force-pushed
the
master
branch
3 times, most recently
from
2629ffc to
5254266
Compare
This PR makes FlatTree support large data sets with good performance as long as most items are not rendered at once, which should be the common case. This is done by optimizing two key functions. The first deals with multiselect state, and simply batches all updates instead of calling `ImmutableMap.set()` in a loop over the entire subtree, which had a big performance impact due to each call copying the entire Map. When toggling the checkbox for a branch with a 2800 item subtree, the delay went from an unusable 1800 ms to 8 ms. The second fix is to avoid processing of invisible subtrees when generating the visible tree based on open items. This one requires a larger tree to be noticeable, but at 35k items, the generator took 600 ms before and 10 ms after the fix. An easy way to test is to modify the story "TreeSelection", changing the `items` array so that it's generated with a loop.
Contributor
Author
|
@microsoft-github-policy-service agree |
bsunderhus
approved these changes
Nov 7, 2025
Contributor
bsunderhus
left a comment
bsunderhus
left a comment
There was a problem hiding this comment.
LGM, next time let's open one PR per modification here, those two modifications are not related, but since both are small changes I don't mind in this case ✅ Thanks for the contribution!
...act-components/react-tree/library/src/components/FlatTree/useFlatControllableCheckedItems.ts
Show resolved
Hide resolved
packages/react-components/react-tree/library/src/utils/createHeadlessTree.ts
Show resolved
Hide resolved
📊 Bundle size report
Unchanged fixtures
|
|
Pull request demo site: URL |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This PR makes FlatTree support large data sets with good performance as long as most items are not rendered at once, which should be the common case.
This is done by optimizing two key functions.
The first deals with multiselect state, and simply batches all updates instead of calling
ImmutableMap.set()in a loop over the entire subtree, which had a big performance impact due to each call copying the entire Map.When toggling the checkbox for a branch with a 2800 item subtree, the delay went from an unusable 1800 ms to 8 ms.
The second fix is to avoid processing of invisible subtrees when generating the visible tree based on open items.
This one requires a larger tree to be noticeable, but at 35k items, the generator took 600 ms before and 10 ms after the fix.
An easy way to test is to modify the story "TreeSelection", changing the
itemsarray so that it's generated with a loop.