You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, thanks for this awesome library! I really like working with your tooling.
But I'd like to have more control over when queries are performed.
My use case
Depending on user input, I want to change how results are sorted (i.e. when a user entered a number in their query, use a different type of sort). For me, this means using useSortBy and calling it's refine function. I'm having trouble preventing that this function isn't called too often.
I had a similar problem when I wanted to debounce / throttle search queries whenver user input changes. I have toyed a bit with using useDebounce and useThrottle type of custom hooks to use a throttled / debounced version of the query, but this approach keeps bringing up complications.
Another example, is that I want to reset the GeoBounds when the user updates the text field. In my current implementation, I have to do two separate refine calls, both resulting in a fetch. These should be batched.
The problem
The core issue is performance problems when doing many simultaneous search requests in a fraction of a second. That is just inherently a performance bottleneck if you have large objects.
Possible solutions
I'd love to have some options to help deal with this. Some ideas:
Prevent calls that have already been done, maybe memoize the response. Now I can sometimes see some queries being run twice wit the exact same payload.
When instantiating instantMeilisearch, give an option to debounce or throttle with a bunch of milliseconds.
Have some internal state that tracks outgoing requests, and prevent multiple fetch calls from being active at the same time (e.g. cancel the previous one if a new one is called). Possibly allow users to set a limit of maxConcurrentSearches
Give useX hooks instead of only refine calls, also refineWithoutUpdate or something. Could also be an option on the hook instantiation.
Instead of doing the search reactively, only perform it when the user calls some function, e.g. the search from useSearch. (might relate to Extract query from instant-meilisearch #952) Perhaps users could set noReactiveSearch in the instantMeiliSearch opts.
The text was updated successfully, but these errors were encountered:
First off, thanks for this awesome library! I really like working with your tooling.
But I'd like to have more control over when queries are performed.
My use case
Depending on user input, I want to change how results are sorted (i.e. when a user entered a number in their query, use a different type of sort). For me, this means using
useSortBy
and calling it'srefine
function. I'm having trouble preventing that this function isn't called too often.I had a similar problem when I wanted to debounce / throttle search queries whenver user input changes. I have toyed a bit with using
useDebounce
anduseThrottle
type of custom hooks to use a throttled / debounced version of the query, but this approach keeps bringing up complications.Another example, is that I want to reset the GeoBounds when the user updates the text field. In my current implementation, I have to do two separate
refine
calls, both resulting in a fetch. These should be batched.The problem
The core issue is performance problems when doing many simultaneous search requests in a fraction of a second. That is just inherently a performance bottleneck if you have large objects.
Possible solutions
I'd love to have some options to help deal with this. Some ideas:
instantMeilisearch
, give an option todebounce
orthrottle
with a bunch of milliseconds.fetch
calls from being active at the same time (e.g. cancel the previous one if a new one is called). Possibly allow users to set a limit ofmaxConcurrentSearches
useX
hooks instead of only refine calls, also refineWithoutUpdate or something. Could also be an option on the hook instantiation.search
fromuseSearch
. (might relate to Extract query from instant-meilisearch #952) Perhaps users could setnoReactiveSearch
in theinstantMeiliSearch
opts.The text was updated successfully, but these errors were encountered: