feat(infinite-hits): support cache

[eunjae-lee]

Summary

This PR adds a cache layer to InfiniteHits.
With the addition, you can add custom cache which is more persistent and it will give more persistent UX especially when user leaves for product detail page, and comes back to infinite hits.

How to test

• Example: https://infinite-hits-cache-react.now.sh/
• Code: https://codesandbox.io/s/xenodochial-mcnulty-o7qdv?file=/src/App.js

Load more pages a couple of times, click "Details", come back and see if the hits are instantly loaded and the scroll is restored.

This examples uses routing because the scroll restoration works when the routing is enabled. But, of course, without the routing the cache itself works fine.

[algobot]

Deploy preview for react-instantsearch ready!

Built with commit e468e05

https://deploy-preview-2921--react-instantsearch.netlify.app

[algobot]

Deploy preview for react-instantsearch ready!

Built with commit fc0a8fc

https://deploy-preview-2921--react-instantsearch.netlify.app

[eunjae-lee]

I didn't know well about browser's scroll restoration.

If you take a look at this example,

• code
• try it!

It's a very simple example and the scroll restoration doesn't work there.

  useEffect(() => {
    setResult(true);
  }, []);

  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      {result && (
           ....

I need to research more, but from my understanding, the scroll is restored right after the first dom rendering, which breaks this current example which renders the big chunk of dom elements at the second render.

For the same reason, when going back to a page with InstantSearch, it renders after /queries API. So the scroll is not restored.

This might initiate a new RFC which saves the current search result at beforeunload or something like that, and later restore it without triggering API call. Without this, when going back to InstantSearch, the page will flash and the scroll restoration needs to be done manually.

At the moment, we ship this as is and document how to manually restore scroll position, which is still better than before.

What do you think?

[eunjae-lee]

I talked to Haroen, and he said there's a render before the search api call. So I'll try to render the InfiniteHits with the cache at the first render. Then the scroll might be restored correctly.

[francoischalifour]

Is the new example supposed to be accessible at this address?

[eunjae-lee]

fixing tests

[eunjae-lee]

Is "argos" expected to run, or not?
Should I do something to force-run the task?

[Haroenv]

We don't rely on Argos anymore, it was too flaky :)

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit fc0a8fc:

Sandbox	Source
quirky-volhard-5sgvi	Configuration
white-moon-gcubj	Configuration
nervous-currying-3cx3h	PR

[Haroenv]

code seems to be working well

[Haroenv]

If we are storing elements with a number index in an object, what about using an array to store that instead? I guess it's no big difference either way

[eunjae-lee]

I initially started with an object because user could've reached the page with params like page=3. Still in that case, an array can be used, though.