Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft: Don't load all hierarchical items at once when expanding the tree #1492

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lfarrell
Copy link
Contributor

This should work to speed up loading of large sibling lists. It essentially paginates the results. It bumps up the results size from 10 to 100 and adds a button for every subsequent 100 items with a truncated document title as part of the button display for navigation context. This can result in a LOT of buttons for REALLY long lists

Screen Shot 2023-12-14 at 3 41 37 PM

I'm not sure it's a great idea to do it this way, but if folks think it's worth pursuing. I can continue down this path.

@lfarrell lfarrell marked this pull request as draft December 14, 2023 20:50
@gwiedeman
Copy link
Contributor

I showed this to a colleagues who was skeptical. They thought that if the archivist wanted to break it up, they would have divided it up into more series.

1k components definitely get slow and this is a good thought, but it might not be intuitive to a user what "Items 301 to 400" means. Is it possible to display the first 100 results and have the "expand" or "next" button append the next 100 continually instead of loading it all? Then the user could keep clicking "expand."

@lfarrell
Copy link
Contributor Author

@gwiedeman @seanaery I've updated it to only show one expand button at a time. It would have been more straightforward in arclight 0.x, but with the move to turbo-frames in 1.x it's a little trickier.
This branch would probably need to be cleaned up a bit to move the JS out of the partial.

@seanaery
Copy link
Contributor

@lfarrell I do like the updated one-button-at-a-time UI better, and I agree that we ultimately wouldn't want the JS in the partial itself. Trying this branch out a bit with real finding aids, I also notice a few cases that are not yet accounted for here:

  • If the 1,000s of sibling components are at the very top c01 level, this code doesn't truncate them. When you view the collection page and look at the sidebar, that will spin for a long time and either timeout or eventually render all the components all at once if it can complete before the timeout limit.
  • If you view a nested component page, say, one that's number 300 in a sequence of 1,000 or more siblings, the bottom Expand button in the sidebar doesn't limit the number it will load, so clicking it will try to just load the rest, which will either timeout or take a long time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants