SSR fails to get first page of infinite hits after filter change

[Ayu]

🐛 Current behavior

Using Remix SSR, useInfiniteHits and useConfigure loses the first page of results after setting a filter. This includes the filtered result which is missing the first page of results, as well as after removing the filter changing the original results.

Things get a little more broken if you load more hits and then use the filter. You end up losing more pages of hits as you start from the last loaded page.

To workaround, removing the InstantSearchSSRProvider and getServerState does work, but removes SSR capabilities which isn't ideal.

🔍 Steps to reproduce

1. Go to reproduction.
2. Click Set Filter (note that there should be 10 results on the first page)
3. Click Set Filter again to revert to the original unfiltered results. You can now see the first result starts off with _position: 11.

If you scroll down to trigger showing more results and repeat the set filter process, the starting position numbers get increasingly larger.

You can also check out https://fontsource.org/ which is an ongoing project I'm working on for a more visual representation. Toggling show only variable fonts shows the same behaviour. (Edit: have disabled SSR for the time being)

Live reproduction

https://codesandbox.io/p/sandbox/adoring-bohr-8lhjnx

💭 Expected behavior

The first page of hits should be visible.

Package version

"algoliasearch": "^4.17.0", "instantsearch.js": "^4.55.0", "react": "^18.2.0", "react-dom": "^18.2.0", "react-instantsearch-hooks-server": "^6.43.0", "react-instantsearch-hooks-web": "^6.43.0"

Operating system

No response

Browser

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Salmen Bejaoui]

Having a similar issue with Next.js. Using a custom routing, the refinement list get ignored with getServerState

[Ayu]

I'm still able to reproduce this with the latest stack with react-instantsearch@7.

[Ayu]

I resolved this issue by updating the useConfigure function to include page: 0 on every filter change. This ensures that the infinite scroll starts from the correct position when filters are modified.

 useConfigure({
    filters: <filterParams>
    hitsPerPage: 10,
 });

to

useConfigure({
    filters: <filterParams>
    hitsPerPage: 10,
    page: 0,
 });

The reason for that is because if you load more "pages", the InstantSearch cursor is pointed to a later page. When you apply a filter change, the cursor remains at the same location which refreshes your infinite scroll with the wrong starting position.

I do think this should still be considered a bug since infinite scroll should still update all previous pages that is has loaded.

[Haroen Viaene]

All other widgets set the page to 0, only configure doesn't as many parameters you could change don't need to reset the page. I recommend you also have a look at useMenu, useRefinementList instead of useConfigure, as it will play nice with eg. routing too.

As you've found the solution and this is by design I'll close the issue now.