Skip to content
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

Able to go negative page numbering #503

Closed
agilob opened this issue Jan 7, 2019 · 8 comments
Closed

Able to go negative page numbering #503

agilob opened this issue Jan 7, 2019 · 8 comments
Labels
bug Something isn't working

Comments

@agilob
Copy link

agilob commented Jan 7, 2019

This is probably inherited from Emby and linked to a race condition on request-> response level.

  1. Click on next page (takes a few seconds - network lag)
  2. Click twice on previous page, wait a few seconds
  3. Repeat

screenshot_20190107_215438

Seems like the "previous page" button is only disabled when lower boundary is 0:

screenshot_20190107_215727

@anthonylavado anthonylavado added bug Something isn't working UI labels Jan 7, 2019
@cvium
Copy link
Member

cvium commented Jan 8, 2019

I would like to add that it's a general problem. I accidentally added the same library twice because of a slow response.

@hawken93
Copy link
Contributor

Looking at the pagination code I want to note that splitting the paginator code from the individual libraries so it can share common logic is a possible improvement

@hawken93
Copy link
Contributor

hawken93 commented Jan 10, 2019

I think what you are getting at here is that the pagination buttons should not trigger more events until the next page is loaded, and for the library I didn't really look at it, but I guess it's about waiting until the server is done as well?

For this issue it's possible to just limit the page number to 0, either by not decrementing the number past 0, or bringing it up to 0 again before processing the request. The variable that holds this information seems to stay within each of the different places in the javascript that pagination is implemented. Each one is slightly different :P But maybe deactivating the event handler while the request is processing is the better fix.

@hawken93
Copy link
Contributor

hawken93 commented Jan 10, 2019

performance optimalization possibility
The javascript calls ApiClient.GetItems() before filtering them to the current page. This means that each pagination actually downloads information about all the items in the library before filtering them on the client side. This wastes lots of resources and should be done on the server side.

query is passed to the getItems request, so I'm wrong here

@JustAMan
Copy link
Contributor

Looking at the pagination code I want to note that splitting the paginator code from the individual libraries so it can share common logic is a possible improvement

This seems to be the most fruitful approach, usually the less almost copy-paste is there the easier it is to maintain stuff.

@hawken93
Copy link
Contributor

to quote myself: I don't think I'll be trying to unify the pagination code in this PR, but if someone wants do that that then please merge them before this

@hawken93
Copy link
Contributor

I'm ready for review on the PR above now :)

@hawken93
Copy link
Contributor

@cvium I've also fixed the library double adding thing, so now it shows the loading indicator and ignores multiple presses until the action has returned a result :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants