chore(frontend): improve camp dashboard performance#2763
Merged
Conversation
manuelmeister
requested changes
May 29, 2022
BacLuc
approved these changes
Jun 9, 2022
pmattmann
approved these changes
Jun 13, 2022
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.
Had to base this on #2683, look for last commit only
Improves performance of dashboard view. Limits to 3 network calls instead if individual calls to each activity and each scheduleEntry.
A potential improvement could be to only load activities from API which I'm responsible for. However, impact is not large. And as an additional benefit, all data is already loaded if I switch to the picasso afterwards.
day.scheduleEntries()is now calcuated in memory, similar as in print:https://github.com/ecamp/ecamp3/blob/devel/print/components/ProgramDay.vue#L36
This relation might also benefit, if we return individual scheduleEntry links instead of 1 single collection link (similar as contentNode->children).
@carlobeltrame: What do you think on this?