Hey, so I have a weird issue, as you can see on th...
# community-help
p
Hey, so I have a weird issue, as you can see on the attached screen recording. When I use autocomplete on mobile, and I close the result area, it reappears if the loading on the top left has not finished. If it's finished, as you can see ath the end, it will remain closed, as it should.

https://youtu.be/wusWxkbT8fU

@Kishore Nallan Could you help me too?
k
It's not clear if this is a client issue or a server issue. It would be helpful if you can produce the code and the response returned as I'm not familiar with mobile dev.
p
Here is the code, you just need to run npm i, and npm run start to see the issue yourself. If I watch the demo of an autocompleteJS when I press cancel the menu dissapears, but here it reappears
@Kishore Nallan Also, it is website development, just mobile view
j
I would recommend posting this on Stackoverflow, because it looks like the results are returned from Typesense successfully (since it's displayed in the UI), but the autcomplete.js library is not updating it's state. So it's unrelated to Typesense...
One suggestion is to use this sample project and work backwards to see where the difference is coming from
p
@Jason Bosco I contacted the people at algolia, and they told me to fck off because I use typesense lol
😂 1
The thing is that this issue is not happening if I use algolia api. So I think is a problem in the adapter or something
Also, the sample project is fully html+js, and I use react for mine. Provided the src above.
j
Could you upload that to Github and send me a link?
p
ABove is the whole project zipped
@Jason Bosco
I made a gh for you
j
@Prime The It looks like every time you click on the autocomplete bar, it triggers this request to Typesense:
Copy code
curl '<https://search.hernadi-antikvarium.hu/collections/books/documents/search?q=&query_by=categories&sort_by=_text_match:desc&prioritize_exact_match=true&per_page=5&group_by=DID&facet_query=categories:&facet_by=categories>' -H 'X-TYPESENSE-API-KEY: <API_KEY>'
Essentially empty values for q, and facet_query... Along with a group_by. This group_by is what's slowing down this query to almost 3.5s, and the loading icon shows up during this time. A couple of solutions to try: 1. Do you intend to show all results when the search bar is clicked? If so, you want to consider adding
use_cache=true
as a query parameter. 2. If you don't intend to show all results with no terms entered in the autocomplete, you could check for an empty query in the code and not trigger the request to Typesense if that's the case.
p
@Jason Bosco I removed group by. Same thing
Use cache helps a bit, but there is still the problem that the window reappears if I press cancel before the buffer finishes
j
Hmm it seemed to help reduce response times when I tried the query without group by when I posted the message above. May I know how many CPU cores you have on the server that's running Typesense?
you could check for an empty query in the code and not trigger the request to Typesense if that's the case.
This might be the solution
p
I think it's a 2 core VPS, but I check
j
And also which version of Typesense this is?
p
4 vCore vps
How can I check the version?
j
GET /debug
will return the version
p
0.25.0
j
Any reason you're using facet_query instead of regular
q
and
query_by: categories
?
p
Because I want to display a list of not only the results, but also the categories and other facets.
(categoriesPlugin and authorsPlugin)
j
Right, you can still just do a simple facet and send the search query in q and query_by
facet_query is useful only for searching within facets to power for eg the "search ingredients" mini search bar in this example: https://recipe-search.typesense.org/?r%5Bquery%5D=Kale
Meaning, you have a set of results returned, and you want to do a search for just the facet values in that resultset, that's when you'd use facet_query
p
Oh, I see.