React-instantsearch: infinite hits: should we load the previous pages

[bobylito]

When loading a page that use the infinite hits widget on a page that is not the first one (eg. page 3), neither the connector or the widget loads the previous pages for the initial rendering.

The question is: should we load the previous pages?

[JStonevalley]

I would argue that the option to load previous pages is essential.
We want to provide a seamless browsing experience and when browsing through items it is not uncommon that people want to check out the item in more detail. In our app that results in them being routed to an ItemDetailView. When the user navigates back we would like to restore the scroll position to the place where they were located prior to navigating to the detail view.

Currently we cannot achieve this.

[vvo]

Should we even allow for url synchronisation or "page" concept when using a "load more" button?

From the user POV there's no concept of page X when using load more/infinite hits. If we do not sync the page to the url when using loadMore (aside from implementation challenges), if you copy paste the url you will just get back to page one.

For a UI that is using "infinite browsing", where page numbers are not being displayed, I would say it should be enough. Back button should still work though but that should be handled by the browser itselfs (they keep a full live page instead of reloading it completely in most cases).

[Haroenv]

In my experience Safari keeps the page in memory, and back button works, but in Chrome it goes to page 1

[JStonevalley]

@vvo In our experience the backbutton does not work when syncing the state with the url. However; we might be using it wrong. I would happily be told that is the case and learn how I should do it properly.

[Kikobeats]

why not determinate if load previous page using a prop?

loadPrevious=false|true

[Haroenv]

IMO we should never load "all up to page X", but allow a user to click or scroll for "show previous", just like "show next"

[mthuret]

Do we know websites allowing that experience? Does they handle url sync in that case?

[rayrutjes]

Very interesting discussion.
Here is my opinion if that can help.
When you actually share the URL of an infinite scroll page, I don't think the page matters like @vvo said.
What matters is probably the filters and things like that.
For me the solution would be that users remove the page from URL sync when they do infinite scrolling.

The only "nice" behaviour, is the one described by Haroen, the back and forth between pages. I think we can leave that to browsers for now.

[Kikobeats]

I want to share my user case, just for be possible design the best solution for all 😄.

In my application, the user can click in a hit to get more details. The probability that the user click in a hit that live in page=1 is low compare with click in the rest of pages, so, major part of the time users clicks in page>1 and this is what happens:

1) The user is navigating from the hits. It doesn't know nothing about pagination.
2) The user decide click and element to get more information.
3) Okay, Okay. Time to go back.
4) Oh no. Because the item is living in page=3, then server throw 500 error becuase I can't retrieve the item correctly.

Actually, keeps all hits in memory is non viable, but also innecessary.

If I'm in page=3 I don't need previous pages, just page=3. In the same way as I'm fetching the next page based on the user scroll from the bottom, I could fetch the previous page doing exactly the same but from the top.

For handle bottom scroll detection, I'm using react-infinite-scroll-component and </connectInfiniteHits>, the API match perfectly (I promise write a tutorial!).

Then, when the user go back, fetch just the previos page (in this case page=3 and expose a wait for render previous page (we have hasMore to get next page, why not support hasLess ?)

I suppose that internally could be nice get a cache for avoid unnecessary API calls or support get pages in chunks, but the sophistication can come after the solution.

[mthuret]

@Kikobeats can I see that using the V3 branch of your app?

[Kikobeats]

@mthuret yes

[mthuret]

@Kikobeats awesome, I'll have a look :)