feat: fuzzy search implementation #351
Conversation
| if (filters.category === NFTCategory.EMOTE) { | ||
| return SQL`word % ${filters.search}` | ||
| } else if (filters.category === NFTCategory.WEARABLE) { | ||
| return SQL`word % ${filters.search}` |
There was a problem hiding this comment.
Don't these 2 return the same thing? Maybe add them in the same if
There was a problem hiding this comment.
Or is it that you have to change word to word_wearable and word_emote?
There was a problem hiding this comment.
Ohh they used to have different logic but now I can unified them, thanks! updated
| @@ -89,6 +98,27 @@ export function createNFTComponent<T extends { id: string }>(options: { | |||
| ) | |||
| } | |||
|
|
|||
| if (options.category === NFTCategory.ENS && options.search && db) { | |||
There was a problem hiding this comment.
Why do ENS require special treatment?
There was a problem hiding this comment.
I added a comment but I forgot to push it 🤦 .
The new search bar needs support for trigram matching but the graph doesn't support it. In order to accomplish it, I added the logic to first look for the IDs of the ENS that have have more similarity than the threshold and then pass those IDs down to the GraphQL query (for satsuma / thegraph).
I think this way it was easier than having another endpoint o having to refactor the whole thing to fetch all from the db instead of from a subgraph.
There was a problem hiding this comment.
I think there is a limit to how many ids can be provided in the query.
I don't know the specific amount, but we should consider that if a result returns many ids, we might need to only use x amount or fail with some expected error.
Still, it might not be necessary if the limit is higher than needed.
Closes #350