pager refactored

[szabgab]

No description provided.

[oalders]

This looks much tighter. Only adds 61 more lines of code. I'll have some time to test this out tomorrow.

[oalders]

The selected number of results don't seem to be sticky on two of the endpoints: /favorite/recent and /author/MIYAGAWA/releases Maybe an issue with the JS?

[oalders]

One other issue is that the pager can sometimes appear on a page with no results, like /author/MIYAGAWAX/releases That page should return a 404 (not your problem to fix) but it's an example of the page just appearing regardless of results.

[szabgab]

Strange. I just checked /favorite/recent and it was sticky for me. Two things that might be the issue you see:

/favorite/recent and /recent share the same key in localStorage. They can be separated if that's preferable.

This whole thing of "pages size" only works if someone arrives from an internal link to one of the URLs. This is due to the fact that we store the information in the browser, and add the size=?? parameter to the links when the user clicks on them, and then we decide on the amount of results in the server.
This means if someone comes from an external link or types in the URL, the page size will be the default.

To this I can see three solutions:

1. When the page size sent by the server disagrees with the page size we have in the localStorage reload the page with the page size we have in localStorage. I am not really a fan of this idea.
2. Move the saved page-size information to cookies that are sent to the server on every request. (But AFAIK you wanted to move away from cookies)
3. Keep the page-size data in the account of the user on the server
   3a) either in the session object
   3b) or in the back-end.

Do you see any other solution to the problem?

[oalders]

Yeah, that sounds a bit complicated. Let's just merge this and see what kind of feedback we get. Thanks very much for all of your revisions. 👍

[szabgab]

Thanks.