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

Windowing instead of pagination #26

Open
neverfox opened this issue Jan 30, 2016 · 4 comments
Open

Windowing instead of pagination #26

neverfox opened this issue Jan 30, 2016 · 4 comments

Comments

@neverfox
Copy link
Contributor

I was hoping to be able to implement lazy-loading scrolling instead of pagination using Snapshot.js, but it appears to be limited to that paradigm, possibly for good reasons. But is it currently possible to do that or would that be an enhancement that would have to be developed? I would think that if it could accept something like startingIndex instead of pageNumber, it could work.

@Wildhoney
Copy link
Owner

Aren't the two paradigms very similar — at least from the perspective of the server-side implementation? Instead of having next and previous, you could scroll, and simply keep loading the additional pages. Use the perPage to limit how many each scroll would yield.

@neverfox
Copy link
Contributor Author

Hmm, you might be right. I was thinking mainly in terms of the client-side differences. For some reason, I got the impression that each new request to the server altered the whole collection landscape server-side, but I could choose the necessary merging strategy to keep my window populated appropriately (if the scrolling stops mid-way between pages for example, or if I'm pre-fetching the next few). Is that what you're getting at?

@Wildhoney
Copy link
Owner

Yep — you're right in that it alters the collection landscape, but that's more of a client-side problem.

I suppose taking the user to the top of the page to begin their infinite scroll journey from scratch would be the most logical. That's how most infinite scrolls that I've seen operate, because otherwise where you are on the page post filter/reorder would bear no resemblance to where you were pre filter/reorder — and thus simply confuse the user. There would also be DOM issues (unless you're being clever by not rendering unseen pages), such as if the user had scrolled to page 5001, then repainting all of those pages when reordering would be terribly slow.

As long as you don't reorder and/or apply filters, then each request is predictable.

@neverfox
Copy link
Contributor Author

I suppose taking the user to the top of the page to begin their infinite scroll journey from scratch would be the most logical.

Right. Filtering when only viewing some of the data screws with one's mental model, but I'm not sure if it's any worse for infinite scrolling than the pagination story, since most of what keeps you from getting disoriented is some kind of feedback about where you are whether it's (page 3 of 10,000) or (records 100-110 of 100,000).

unless you're being clever by not rendering unseen pages

Yes, I am indeed, using react-list.

In any case, I'm going to give it a shot and I can report back about how it went.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants