Large CVV performance improvement - #12617
Open
qqmyers wants to merge 8 commits into
Open
Conversation
…g in advanced search
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
1 participant
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.
What this PR does / why we need it: As reported in #11223 and brought up recently in the community group, the updates in #10762 to support ~8K language entries caused significant slow downs in page loading (advanced search, edit dataset and template metadata).
This PR changes the widget used to display a large controlled vocabulary field (one with > 500 entries) to shift to supporting type ahead lookup rather than preparing a checkbox list with 8K entries as the page loads.
In my tests, loading of the edit metadata pane went from 15-20 seconds down to 2-3 (with the language field now adding negligible time), and the advanced search page has slightly less flicker, while also improving how well you can see what has been selected (selections show in a header).
,
Which issue(s) this PR closes:
Special notes for your reviewer: The problem reported in #11223 appears to have improved since 6.4 - not sure why, but the fix in this PR is faster yet and aligns the way the field works in the dataset, template and search pages.
As of now, this update is in use at https://data.stage.qdr.org/ - feel free to see/compare it there.
Suggestions on how to test this: Use the language field in the dataset, template, and advanced search pages, assure selecting still works. Assure no changes to other controlled vocab fields such as Subject, RelatedPublication RelationType, etc. (all less than the 500 item limit that triggers use of the new widget, so no changes).
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
In addition to the widget itself, the new UI includes an option to use the original widget an see all entries.
The new widget shows choices that match the user's entry:
The change is an improvement over the old advanced search page which did not show a header, making it hard to understand what had been selected. In this image, English has been selected:
Is there a release notes update needed for this change?:
Additional documentation: