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.
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
chore(print): improve performance for data loading #2571
chore(print): improve performance for data loading #2571
Changes from all commits
7df6555
233357f
de3af5a
4141319
3a0e911
d3e32d2
cb8b3cd
13c74d7
055741a
21b87db
e89ed25
fb23a8f
33a72c3
9b0f105
b5b68bb
e657423
8894d0c
7940e6b
9543a93
365bfb1
e0820c2
a581277
f53dc78
fa18f1a
61343a1
684b709
788e1be
cbe97ee
69e9674
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was added to make the react-print load time bearable during development. So we should soon add similar replacements for this to react-print as you did for nuxt-print.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, absolutely. I suggest we merge this first, and then we can use the same data loading concept for react-print (by me or you - both ok for me).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why remove the
parent
filter? Are you sure that it wasn't used anywhere? I can't remember, but there were a lot of tests for this which you had to remove.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the
parent
filter results in children property to not be a single link but an array of links (basically disabling RelatedCollectionLinkNormalizer). This avoids a lot of above API Calls, because once I have the complete list of ContentNodes I can freely traverse down the child nodes without additional API calls.hal-json-vuex
is now "immune" to this, because it will just create a virtual key for the children array.It shouldn't break anything. Just notice that in the frontend, we're actually no using the children property at the moment, because we do the filtering manually:
https://github.com/ecamp/ecamp3/blob/devel/frontend/src/components/activity/DraggableContentNodes.vue#L67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, now I get it. In this specific case (recursive data structure) we actually prefer the array of hrefs
children: [{ href: '/content-nodes/1a2b3c4d' }, { href: '/content-nodes/1234abcd' }, ... ]
over the shortened, filtered single linkchildren: { href: '/content-nodes?parent=/content-nodes/00000000' }
, because we don't want to embed all children, and because the array contains all the information we need for filtering in the frontend, without sending a separate request for /content-nodes?parent=/content-nodes/00000000When I wrote the RelatedCollectionLinkNormalizer, I did not foresee that the link array could ever be more useful than the single filtered link. Maybe we don't need the parent filter right now. But I think we should introduce a way to explicitly disable the filtered link even when the filter exists. Otherwise, someone might in the future e.g. add filters for all relations, and make the performance worse without noticing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Explicitly comment in tests why children needs to be an array (to avoid someone adding the parent filter again in the future)