Session cache not tracking pagination state

[ldmichae]

Hey there, I'm using the latest version of react-instantsearch (7.13.7 at time of posting) in my project, and recently was tasked with implementing result caching, so that when navigating back to a listing/search page from a detail page, you would maintain your search results and scroll position.

It was easy enough to plug and play with the cache provided out of the box, however I noticed that when using the showMore function from useInfiniteHits (paired with a cache instance), it was running requests as if it had no cached information at all, despite loading all cached results appropriately.

For example, my PLP (search page) is configured to load results in batches of 12 items. Workflow as follows:

• load up a search, returning 12 items
• use the showMore functionality to request 12 more items.
• navigate to a detail page by clicking on one of the results.
• use the browser back arrow to return to the listing page.

24 cached results are visible as expected. However, when I now call showMore, it requests page zero.
The next call requests page 1.
This means that I have to invoke showMore twice before getting new results (page two).
This would mean that if I had requested ten pages before navigation, I would need to invoke showMore ten times before getting fresh results.

From this description, is it possible to provide any hints as to why showMore and the invocation of useInfiniteHits paired with a session cache is not properly paginating so that the first call to showMore uses the proper page from the cache?

[mmorris8]

Having this issue too. I'm forced to conclude showMore no longer works. And the pagination page is ... useless. It gives this as the way to query a specific page:

index.search('query', {
  page: 2,
  hitsPerPage: 5
}).then(({ hits }) => {
  console.log(hits);
});

Ok, fine, where's index? How do I figure out what 'query' is supposed to be - the parameter string off the useInstantSearch API??? The documentation of this product is frustrating at best.

[mmorris8]

@ldmichae Are you using Multi Index by any chance? That's part of my setup and I'm beginning to suspect it's part of the problem as there are a couple of corner cases using it creates.

[ldmichae]

@mmorris8 I'd prefer to wait for someone maintaining the library to chime in before going further in seeing how our bugs do or don't overlap.

[mmorris8]

Fair enough.

[mmorris8]

I just realize something - You're using a session cache and I'm not. I've got nothing to lose here so I'll try implementing that and if it starts working we can compare notes and see if it starts working. However, if I fail that's an indication that the problem isn't in session cache itself.

[mmorris8]

I dropped this into my infiniteHits component

useEffect(() => () => console.log('unmount'), [])

showMore() is causing the component to be unmounted. That's why it's returning to page 0. So perhaps a reference can be used to recover the state after the immediate remount.

[Haroenv]

If it behaves like you describe, that would be a bug. Can you reproduce it with the examples in this repository? Or only with a specific combination of option? If so it would be useful to create a reproduction that clearly shows the issue and we can have a look

[mmorris8]

I built the test case and the unmount is not occurring nor is the bug happening. So I now need to figure out what is causing the unmount - but that's on me, not the algolia library. Thank you for your time.

[mmorris8]

Ok, my problem was a LoadBoundary causing the mount/unmount. Note to self - don't use those with an InfiniteHits module.

[Haroenv]

yes, in general you should avoid conditionally mounting any InstantSearch widgets

[ldmichae]

@Haroenv I'd like to pick up on this:

yes, in general you should avoid conditionally mounting any InstantSearch widgets

For our purposes, we do conditionally mount our entire InstantSearch component tree.
Our page conditionally selects which frontend components to render based on the response from our CMS, so our site design cannot guarantee that at a given route, that we will always have an instant search widget, and the dynamic route being used overlaps with so many other kinds of pages for us that keeping an instantsearch widget wrapped around the whole thing wouldn't make much sense, and would likely cause errors.

Is the only way to "avoid conditionally mounting any InstantSearch widget" to have a /search route (or similar) where there's always an instantsearch instance?

My team is approaching a site redesign as we're going from Next.js 12 to 15, and I want to ensure that I'm recommending best practice as we get into planning.

[Haroenv]

Yes, you're definitely going to run into less confusing states if InstantSearch is (mostly) static. If you've got a reproduction about what is going wrong in the current setup, we can have a look at it, and continue making these edge cases more robust, but avoiding them is a way to have a more stable application