https://typesense.org logo
Join Slack
Powered by
Hey, regarding the Typesense Instantsearch adapter...
# community-help
c
Hey, regarding the Typesense Instantsearch adapter. Should the 
filters
property for 
<Configure>
also work (docs) for Typesense? I have tried setting it but nothing seems to make it to the network call to Typesense. I have used 
facetFilters
previously which works great, though we can't set that and use a RefinementList at the same time. I was hoping using the 
filters
property would somehow combine the values for us properly as described in this issue.
j
Oh wait, you're talking about combining filters in the configure widget along with filters used in RefinementLists
To do this in Typesense, I'd recommend embedding the filter in a scoped API key and using that API key with the adapter
Then Typesense will combine the filter from the widget with the filter embedded in the API key on the server-side
c
Hmm, that could work. Though we already do use a scoped API key as a way of controlling permissions on certain items, so not sure if it'll play nicely with that. I can have a try though, it's the best I have right now 👍
j
You can embed any number of fields in filter_by in scoped API keys, they'll all just be ANDed to the filter_by in the search query
c
Can we extend a key though? We generate a scoped API key on login, and save that in the user's JWT. This filtering would need to happen further along the process. I was about to try base64 decode the key and try modify the filter that way, to see if it worked
j
try base64 decode the key and try modify the filter that way
That wouldn't work unfortunately. It's meant to not be decodable for ACL purposes.
👍 1
Could you elaborate on your use case so I have context? May be there are other ways to do this
❤️ 1
c
Sure 🙂 What we have, is a search box, that when the user enters some text, we try to see if it contains numbers with length of 6. In this case, we assume the user wants to search on a bunch of product numbers, so we switch from doing a normal search query to just do a "*" and then filter on "product_number:<query_number>". However, it could be that the user then wants to filter this result further, by using the refinements on the left. Which is where we hit the problem of the 
<Configure>
not combining with the refinements. Hope that makes sense
Oh and, the search box is managed in a context, as we did not wish to depend on Instantsearch too much where possible.
@Jason Bosco Have any further thoughts on this? 🤔
j
then filter on "product_number:<query_number>".
Does this not filter down to a single record? Sounds like there are multiple records with the same product number?
If so, I think Dynamic Filtering might work for your use case: https://typesense.org/docs/0.22.2/api/curation.html#dynamic-filtering Something like:
Copy code
{
  "rule": {
    "query": "{product_number}",
    "match": "contains"
  },
  "filter_by": "product_number:={product_number}",
  "remove_matched_tokens": true
}
🤔 1
c
Yeh, there are multiple records with the same identifier. Think of it as a single product, but with different colours, so each colour is an entry in itself. e.g. you sell a car, but that car has different variants. You sell the variants, but not the general shape/spec of the car 😄 I had come across the dynamic filtering rules, but didn't experiment with it. Would it work if there's 10 different product numbers? How about if there's a mix of different numbers? Such as: "<product_number> <product_number> <ean> <product_number> <sub_product_number>" If I were to make 3 rules, each targeting the different number types, they would all apply to a 
filter_by
and be removed from the query? Assumiing 
remove_matched_tokens
is 
true
of course.
j
Would it work if there's 10 different product numbers? How about if there's a mix of different numbers?
Yup, you also want to create different rules for each field, like you mentioned
c
Okay, sounds like that would do the job then. I'll give it a try! Thanks for the help ❤️
👍 1
Open in Slack
PreviousNext
Powered by