Conversation
The FileManager tree has no row virtualization, so mounting tens of thousands of rows on first paint blocks the main thread and the page appears empty (fixes vxcontrol#403). Above LARGE_LIBRARY_PROMPT_THRESHOLD (5000) entries, prompt the user to search instead of eagerly rendering the whole library; once a query is active the existing FileManager render path is unchanged.
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
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.
Summary
Fixes #403.
With ~100k resource entries, the Resources page fetches the full recursive library (already the intended REST behaviour) and then mounts every entry into the
FileManagertree in one go.FileManagerhas no row virtualization, so building and rendering tens of thousands of DOM nodes blocks the main thread on first paint — the page freezes and appears empty, matching the report exactly.This PR adds a small guard rather than a full virtualization rewrite (which would touch the tree-building, keyboard nav, selection, and DnD code paths and deserves its own focused PR/discussion): above
LARGE_LIBRARY_PROMPT_THRESHOLD(5000) entries, if there's no active search query, the page shows a "Large resource library — search to narrow it down" prompt instead of mountingFileManagerwith the full unfiltered set. Once the user types a query, the existingFileManagerrender path (including its own client-side filtering) is used unchanged.This directly prevents the freeze-on-load scenario from the issue without touching
FileManagerinternals, the REST/GraphQL contract, or any of the move/copy/search logic that assumes the full resource list is available in memory.frontend/src/features/resources/resources-constants.ts: newLARGE_LIBRARY_PROMPT_THRESHOLDconstant.frontend/src/features/resources/resources-utils.ts: new pureshouldPromptToSearchLargeLibraryhelper.frontend/src/pages/resources/resources.tsx: use the helper to swap in a prompt state instead of mountingFileManagerwhen the library is too large and unfiltered.Full virtualization of the tree would still be worth doing as a follow-up for a smoother browsing experience on huge libraries, but this is a self-contained fix for the reported crash.
Test plan
resources-utils.test.tscovering the new helper's threshold/query logicpnpm exec tsc --noEmit— cleanpnpm exec eslinton all changed files — cleanpnpm exec prettier --checkon all changed files — cleanpnpm exec vitest run— new tests pass; ran the full suite and confirmed the pre-existing failures (review-sandbox.unit.test.ts,markdown-editor-field.test.tsx) are present on an unmodified checkout too, unrelated to this change