-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Stop pagination and adding a library from being able to trigger multiple times #27
Conversation
1765328
to
ceb7123
Compare
At this point I think all the necessary changes have been made. TODO for testing: WAT: musicplaylists doesn't have pagination WAT: each pagination page has its own hardcoded page limit of 100 WAT: each pagination page has its own implementation of the pagination code..
|
2b4fec9
to
4249c80
Compare
Ready for review! |
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.
Most are format nitpicking. If you would accept my suggestions please squash them in one commit, though, we don't want a bunch of "added one space" commits :)
The main blocker IMHO is one case of isLoading
being uninitialized.
It also feels like it should really be tied to this loader.show()
/loader.hide()
things, like being a property of this loader
object rather than a side-added variable.
@JustAMan I looked at it but it's in bower_components/emby-webcomponents/loading and I don't know if it's alright to modify there, don't feel like making conflicts and stuff but if I could, I would add a getter to the loader such as loader.visible(), or loader.active() I'll reformat my code for now and await your opinion on this. To be honest, I wish this pagination code was just library-ified alltogether. btw, I squashed the changes into the original commits because I have a heavy OCD relating to my commits. I also found another one of those missing spaces in userpasswordpage that got there in an earlier bugfix. Made a separate commit for that since it's not related. But I hope it will be okay to have it here since it's pointless to have a PR just for a space |
var query = getQuery(page); | ||
ApiClient.getItems(Dashboard.getCurrentUserId(), query).then(function(result) { | ||
function onNextPageClick() { | ||
query.StartIndex += query.Limit, reloadItems(tabContent) | ||
if (isLoading) return; |
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.
From a UX perspective I would honestly expect repeated clicks to cancel the previous request and move forward.
Example: You are on Page 4 and click Next 3 times. Once it's done loading you are now on page 7.
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.
I disagree. When you're on page 4, "next" means "go to page 5", so if you repeatedly click "go to page 5" you should end on page 5 IMHO.
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.
That's how I wanted to fix it initially, but there's no good way of stopping you from going past the last page. Instead I opted to basically make a locking mechanism. This will also stop impatiently clicking from going too far...
I think a relevant improvement would be to make it possible to go directly to page N
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.
A future improvement might be pre-loading prev and next pages. That also solves the problem somewhat.
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.
I actually like both having an ability to choose N and to keep prev and next pages preloaded.
I'm all for making this a separate lib, but let's finish this PR first. |
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.
Aside from the flag that should be in loader, only very small stuff is left.
Let's do this "flag in loader" in a separate PR for clarity, though.
I'll implement it in the loading class :) |
wait, never mind. I'll follow @JustAMan s advice and I'm leaving this here to hopefully be merged unless there's something more to fix :) |
@joshuaboniface if it's possible I would love to see this in the bug fix release as it stops libraries from being created multiple times, which is always annoying :) |
@hawken93 Sorry, trying to back port it wasn't going to be feasible due to the split. It was hard enough getting one line in one file to play nice ;-) However barring any further feedback I can merge this for the next release! |
@cvium do you have any objections on merging this PR? Contacting you as you left feedback here. |
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.
@JustAMan LGTM
This PR breaks the medialibrarycreator. I'm investigating how. |
I'll also try to fix the other mentioned case there, where it is possible to add a library twice by getting impatient.
I don't think I'll be trying to unify the pagination code, and if someone else does that then please merge them before this.
Fixes jellyfin/jellyfin#503