Description
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 todebounce
orthrottle
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 ofmaxConcurrentSearches
- 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
fromuseSearch
. (might relate to Extract query from instant-meilisearch #952) Perhaps users could setnoReactiveSearch
in theinstantMeiliSearch
opts.