fix(perf): remove usage of SearchParameters.clearRefinements #6004
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This functions is much slower than individually clearing the specified refinements. In a test with DynamicWidgets + 118 RefinementLists the initial mount goes from 600ms to 350ms in my tests. I've looked around to see if there's good tools for these improvements, to ensure we don't regress, but i couldn't find much (perf is mainly focused on apps). Unfortunately I can't really deprecate the method as we still use it in a non-hot path inside the helper itself to create the right queries in queryBuilder. We'll just have to rely on "seeing other examples" to avoid using parameters.clearRefinements. As widgets can't be mixed across the same attribute, there's no actual risk in this change AFAICT.
Haroenv
requested review from
a team,
sarahdayan and
aymeric-giraudet
and removed request for
a team
|
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 3877bee:
|
* 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This functions is much slower than individually clearing the specified refinements. In a test with DynamicWidgets + 118 RefinementLists the initial mount goes from 550ms to 350ms in my tests.
I've looked around to see if there's good tools for these improvements, to ensure we don't regress, but i couldn't find much (perf is mainly focused on apps).
Unfortunately I can't really deprecate the method as we still use it in a non-hot path inside the helper itself to create the right queries in queryBuilder. We'll just have to rely on "seeing other examples" to avoid using parameters.clearRefinements.
As widgets can't be mixed across the same attribute, there's no actual risk in this change as far as I can tell.