fix(hydration): generate cache with search parameters from server-side request

[dhayab]

Summary

In an SSR context, the search request performed server-side is cached in the client-side search client to prevent sending an unnecessary duplicate request when the user interacts with refinements.

This is done by manually recomposing the cached results during hydration and adding it to the search client's cache mechanism. The key of a cached request uses the search parameters from the response, normally returned by Algolia, but customers can limit what fields are returned by setting the responseFIelds option. If params is omitted, than the app throws an error during hydration.

This PR changes slightly how the request key is crafted, by instead extracting the request search parameters from the server-side search request, and using it instead of the response search parameters.

Result

Hydration now works correctly and the server-side request is effectively cached whether fields are filtered using responseFields or not.

Note

The issue of cache miss in implementations containing multiple indices is still unsolved and can be handled by FX-2720.
Furthermore, if in those multiple indices there are multiples of the same indexName + indexId, the current implementation of getInitialResults() uses only the last instance for params and results, which might not be desirable.

Fixes #5964
FX-2702

[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 81c5b6e:

Sandbox	Source
InstantSearch.js	Configuration
react-instantsearch-app	Configuration
example-react-instantsearch-default-theme	Configuration
example-react-instantsearch-next-app-dir-example	Configuration
example-vue-instantsearch-default-theme	Configuration

[Haroenv]

Thanks for tackling this! I think it can do with a couple more tests of more advanced features though

[Haroenv]

I guess I don't really understand this code right now, but how come this can't be read from waitForResults? does it need to be set before the results are known or something?

[dhayab]

It's similar to what's in server.ts for the pages router, just that because we have access to the search instance outside of both waitForResults() and injectInitialResults(), it allows me to put the code that extracts the queries params before and directly reference them instead of passing them as a return value of promises.

[Haroenv]

my question was more about the potential desynchronising of the search client wrapper in the future if we do any changes to that. Not sure if it matters

[Haroenv]

same question, how can this be undefined?

[Haroenv]

I think this is good to go, however, in the future we need a good look at FX-2720 in detail (and probably also in the scope of FX-2713, maybe even warn or error for that use case as it may be broken)

Not fully sure if the code duplication around param extraction between React InstantSearch and InstantSearch.js is good long-term but ok I think