Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(caching): sort filters and queries #5764

Merged
merged 5 commits into from
Jul 24, 2023
Merged

feat(caching): sort filters and queries #5764

merged 5 commits into from
Jul 24, 2023

Conversation

Haroenv
Copy link
Contributor

@Haroenv Haroenv commented Jul 19, 2023

This allows a better cache hit rate, because when widgets mount and unmount, it's possible that while the filters are the same, they are requested in a different order.

This PR fixes that on two approaches:

  • sorting the filters (alphabetically by value per type), which has no impact on the SearchResponse
  • sorting the queries (alphabetically by facet name per type), which also needs to be taken in account for the SearchResponse (so it is implemented in SearchParameters)

fixes CR-3813

Haroenv added 2 commits July 19, 2023 10:40
- facetFilters
- disjunctive queries

sorted alphabetically through facet name

This basically will allow a better cache hit rate.

To figure out:
- does this have a perf impact (likely not)
- should it be an option
- how do we ensure everything is sorted
- are the right facet values read (no actually, it should be done in getRefinedDisjunctiveFacets etc.
@codesandbox-ci
Copy link

codesandbox-ci bot commented Jul 19, 2023

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 f7d7c3b:

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

Haroenv added 3 commits July 19, 2023 10:56
much slower, the default sort works just fine (the values are search parameter keys, so english)

follow up on algolia/algoliasearch-helper-js#911
@Haroenv Haroenv changed the title WIP: sort request parameters feat(caching): sort filters and queries Jul 19, 2023
@Haroenv Haroenv marked this pull request as ready for review July 19, 2023 15:03
@Haroenv Haroenv requested review from a team, dhayab and sarahdayan and removed request for a team July 19, 2023 15:03
@Haroenv Haroenv requested a review from dhayab July 20, 2023 14:59
Copy link
Member

@dhayab dhayab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏

@Haroenv Haroenv merged commit f3d2019 into master Jul 24, 2023
@Haroenv Haroenv deleted the wip/sort-requests branch July 24, 2023 08:14
Haroenv added a commit that referenced this pull request Jan 17, 2024
introduced in #5764, but wasn't an issue until merge/setQueryParameters doesn't make a new copy constantly of the parameters.

Essentially what's going on:
- when you build the requests, it's sorting the facet values
- this then gets updated in the parameters as well as it's the same object
- with this fix, the sorting is done non-mutating (similar to .toSorted) to avoid the sorting of the parameters for cache to have a potential impact on the UI
dhayab pushed a commit that referenced this pull request Jan 18, 2024
…6007)

introduced in #5764, but wasn't an issue until merge/setQueryParameters doesn't make a new copy constantly of the parameters.

Essentially what's going on:
- when you build the requests, it's sorting the facet values
- this then gets updated in the parameters as well as it's the same object
- with this fix, the sorting is done non-mutating (similar to .toSorted) to avoid the sorting of the parameters for cache to have a potential impact on the UI
dhayab pushed a commit that referenced this pull request Jan 18, 2024
* fix(perf): improve speed of setQueryParameters

inside setQueryParameters (used in many cases), we have _parseNumbers, which is always used with the arguments of setQueryParameters or new SearchParameters

TODO: find out why CurrentRefinements > RefinementList changes its order with this change. Not sure yet

* fix(requestBuilder): sort facet refinements in a non-mutating manner (#6007)

introduced in #5764, but wasn't an issue until merge/setQueryParameters doesn't make a new copy constantly of the parameters.

Essentially what's going on:
- when you build the requests, it's sorting the facet values
- this then gets updated in the parameters as well as it's the same object
- with this fix, the sorting is done non-mutating (similar to .toSorted) to avoid the sorting of the parameters for cache to have a potential impact on the UI
dhayab added a commit that referenced this pull request Jan 22, 2024
…6012)

introduced in #5764, but wasn't an issue until merge/setQueryParameters doesn't make a new copy constantly of the parameters.

Essentially what's going on:
- when you build the requests, it's sorting the facet values
- this then gets updated in the parameters as well as it's the same object
- with this fix, the sorting is done non-mutating (similar to .toSorted) to avoid the sorting of the parameters for cache to have a potential impact on the UI

Co-authored-by: Haroen Viaene <hello@haroen.me>
dhayab added a commit that referenced this pull request Jan 22, 2024
…6012)

introduced in #5764, but wasn't an issue until merge/setQueryParameters doesn't make a new copy constantly of the parameters.

Essentially what's going on:
- when you build the requests, it's sorting the facet values
- this then gets updated in the parameters as well as it's the same object
- with this fix, the sorting is done non-mutating (similar to .toSorted) to avoid the sorting of the parameters for cache to have a potential impact on the UI

Co-authored-by: Haroen Viaene <hello@haroen.me>
dhayab added a commit that referenced this pull request Jan 22, 2024
…6012)

introduced in #5764, but wasn't an issue until merge/setQueryParameters doesn't make a new copy constantly of the parameters.

Essentially what's going on:
- when you build the requests, it's sorting the facet values
- this then gets updated in the parameters as well as it's the same object
- with this fix, the sorting is done non-mutating (similar to .toSorted) to avoid the sorting of the parameters for cache to have a potential impact on the UI

Co-authored-by: Haroen Viaene <hello@haroen.me>
dhayab added a commit that referenced this pull request Jan 22, 2024
…6012)

introduced in #5764, but wasn't an issue until merge/setQueryParameters doesn't make a new copy constantly of the parameters.

Essentially what's going on:
- when you build the requests, it's sorting the facet values
- this then gets updated in the parameters as well as it's the same object
- with this fix, the sorting is done non-mutating (similar to .toSorted) to avoid the sorting of the parameters for cache to have a potential impact on the UI

Co-authored-by: Haroen Viaene <hello@haroen.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants