-
Notifications
You must be signed in to change notification settings - Fork 6
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
Entities with many subclasses load super slowly #912
Comments
It's a rendering issue. I'll check it out. |
The biggest issue is (obviously) rendering all of the subclasses. |
The bottleneck is happening in monarch-app/frontend/src/components/AppLink.vue Lines 23 to 30 in 84dab5f
|
The issue is that for every single AppLink, the |
A further issue here is that the entire node is stored in the browser's history state. That can end up being quite a bit of data for nodes like this one. The easiest solution here would be to only store a minimal amount of a node's information in the breadcrumb state. That is, the smallest representation of an entity that could be rendered by
|
Note that this is already done in the monarch-app/frontend/src/pages/node/AssociationsSummary.vue Lines 70 to 86 in 84dab5f
|
@ptgolden I am moving this to the January 2025 milestone. Please update it to a later date if you need more time. |
Previously, if an AppLink was rendered from a node, the entire node was serialized. Since a node is a non-trivially large JSON structure, this resulted in a lot of wasted serialization, as only a few pieces of information are necessary to generate a link. As a result, pages that rendered a non-trival amount of links (in this case, SectionHierarchy) would be very laggy as the browser struggled to do all that serialization. This commit filters only those properties necessary to render a link: `id`, `category`, `name`, and `in_taxon_label`. (Note that this stretegy is already used in AssociationSummary.vue). Fixes #912
example: http://dev.monarchinitiative.org/PATO:0000001
I'm not sure if this is a backend problem (something about the hierarchy code is silly, like making one request per subclass entity), or if it's a rendering problem (something in the AppNodeBadge is expensive?).
If there's lots of associations, but few subclasses, everything seems fine, so it does seem to be specific to the hierarchy API request or UI components.
The text was updated successfully, but these errors were encountered: