Fixed ListUserItemsRequest performance (#1035) #1037
Merged
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.
The idea here was a bit more complicated... there are multiple instances of the
ListUserItemsRequest
class. Here they are:UserItemsTreeGrid:
PrincipalBrowseFilterPanel:
So for instances where the necessary data does not depend on the count parameter, I simply set the count to 1:
For the remaining instances, I couldn't just set the counter to one, because the data used is actually the users, so by setting counter to
N
, we'd be showing onlyN
users after some search for example.Therefore my approach was to set them to
100
, and only if the users scroll down the filtered data, then we'll request100 + N
,100 + 2N
, ... number of users.Why request
100 + N
, instead of requestingN
and append the response the current data? Because this data comes from a search, so theN
new ones might not have anything related to the old ones.If approved, than I'd like to know how to add the "loading" effect, just like when loading through all users under an idProvider (
loadChildren
method), that's why this PR is currently a draft.